Components in the Repository 

Resources in the Design Time Repository (DTR) are addressed via a Uniform Resource Identifier (URI). These IDs are also used by browsers to address servers and resources in the Internet. An URI consists of a sequence of names, separated by slashes “/”.

Similar to a file system, files in the repository are organized hierarchically in folders, and all development objects must be stored as files, parts of files, sets of files, or folders containing files. To find such a resource, follow the folder hierarchy from the root to the desired file. The search path is written in the form of an URI, in which every visited folder is one name segment.

/dtr/ws/myworkspace/org/example/myclass.java is a valid URI, representing a Java class myclass.java in a DTR. To find the file of this class in the repository, follow the name segment chain: first to folder dtr, then to folder ws, and so on.

The names of components, which come in the form of vendor/name1/name2..., can easily be interpreted as part of an URI. Component names are mapped to a folder hierarchy in the repository: Every segment of the name, including the vendor ID, is represented by a folder. The top folder of the hierarchy represents the vendor, while every subsequent name segment is associated with a child folder.

The figure below shows how component names are mapped to a folder hierarchy in a repository. You see the folder hierarchy of the components sap.com/A/B, sap.com/A/C, and sap.com/X/B. Components of a different vendor (example.org) are stored in another part of the tree.

 

Such a folder tree does not necessarily reflect relationships between components. For example, component sap.com/A/B could be an inner component of sap.com/X/B. By simply studying such a component tree, you cannot find out how components are nested. Especially since the nesting can change in the course of time, whereas the tree in the example above cannot be altered once the components have been created.