Abstract: Mechanisms to persist object relations are provided. A project is defined as a series of interrelated objects having dependencies and relationships with one another. The dependencies and relationships are maintained via a storage organization for files that define the objects within a project storage environment for the project. Thus, the dependencies and relationships are not maintained via hardcoded instructions or references that are included within the files.

Abstract: Techniques for generic data access are provided. A middle-tier server agent uses data providers that can communicate with backend resources. A request received in a first format is used to identify a specific data provider by the middle-tier server agent; the data provider uses the first format to communicate with a specific backend resource in a second format. Results from the specific backend resource are returned from the data provider in the first format and passed to a client that initially made the request.

Abstract: Techniques for distributed cache management are provided. A server having backend resource includes a global cache and a global cache agent. Individual clients each have client cache agents and client caches. When data items associated with the backend resources are added, modified, or deleted in the client caches, the client cache agents report the changes to the global cache agent. The global cache agent records the changes and notifies the other client cache agents to update a status of the changes within their client caches. When the changes are committed to the backend resource each of the statuses in each of the caches are updated accordingly.

Abstract: Techniques managing complex dependencies in a file-based team environment are provided. A software module is represented as an object. The object is defined via a file. The file includes relationships, and some of the relationships define dependencies to other objects. In some cases, attributes for the object are also included in the file and are defined via references to still other objects. The relationships and the attributes are carried with the object via the file.

Abstract: Mechanisms to support multiple name space aware projects are provided. Multiple roots of a project declare multiple namespacing mechanisms. Resources of the project can utilize each of the multiple namespacing mechanisms. In some cases, a particular resource of the project can override and use a foreign namespace that is associated with a different project hierarchy even while that particular resource resides within a project hierarchy associated with the original project and even while the project hierarchy does not declare, at the root, the foreign namespace.

Abstract: Mechanisms to support fine-grain namespacing are provided. When an object is to be loaded within a processing environment, a specific namespace for that object is dynamically resolved during the load. That namespace can be dynamically resolved via object inheritance, via specific object-attribute declaration, and/or via consultation with a namespace object.

Abstract: Mechanisms for sharing attributes between objects are provided. An object includes a special designation for at least one component, which is identified as a shared attribute. Data associated with the shared attribute is populated and managed from a central location within a processing environment. Multiple instances of a same object or of entirely different objects can reference, declare, and use the data from the central location.

Abstract: Mechanisms to persist object relations are provided. A project is defined as a series of interrelated objects having dependencies and relationships with one another. The dependencies and relationships are maintained via a storage organization for files that define the objects within a project storage environment for the project. Thus, the dependencies and relationships are not maintained via hardcoded instructions or references that are included within the files.

Abstract: Mechanisms to support object-oriented version control operations are provided. A user manipulates and views a project from an object viewpoint and within an object module. The user performs version control operations using object handles. The object handles are resolved to specific file references and the specific file references are used to process legacy version control commands utilizing a legacy version control system in a manner that is transparent to the user.

Abstract: Mechanisms to support orphaned and partially configured objects are provided. A project includes a variety of objects. At least one object is designated as an orphaned object. The orphaned object lacks complete configuration details. Other objects of the project depend on the orphaned object and yet the other objects can load and process within the project as if the orphaned object was fully configured and available.

Abstract: Mechanisms to build dynamic locations to reduce brittleness in a team environment are provided. A project includes resources, each resource is assigned a key. Each key is mapped to a current location for its corresponding resource. The keys and locations are maintained in an index. Locations for the resources can change as desired throughout the lifecycle of the project and as changes occur the index is updated. When references are made within the project to the resources, the references are translated to the keys, if necessary. The keys are then used for accessing the index and dynamically acquiring the current locations for the resources at the time the references are made.