The current implementation of the component model in the SAP NetWeaver Developer Studio and related tools is based on a strict file system layout. This layout defines how you have to organize a collection of development components (DCs) in a common file system hierarchy. The following figure shows the organization of two components sap.com/A/B and sap.com/X/B :
File system layout
All DCs associated with a certain configuration belong underneath a common root directory, the DCs directory in the figure. However, no distinction is made between DCs in source or in binary format. For example, component sap.com/A/B may be stored with sources, while sap.com/X/B may hold a build artifact only. The assignment of DCs to their corresponding software components (SCs) is based on reference pointers (that is the .DCREF files), which are stored alongside the configuration directory.
While it is efficient, for example in resolving dependencies between DCs, the above given file system layout has some disadvantages, especially when an integration with another version control system is attempted. Since there is usually no need to upload artifact components to the version control system, sorting out the source components may become hard. Furthermore, some popular build environments tend to strictly separate source code projects from artifacts.
The following list gives the most important changes and enhancements to the file system layout:
The file system layout places more emphasis on compartments. Each compartment can optionally be associated with a separate directory in the file system that physically contains the source files or artifacts of all DCs that belong to that compartment.
The configuration descriptor (.CONFDEF) is associated with an index file (confdef-idx) that lists the compartments of the configuration together with the paths of their corresponding root directories. Only relative path declarations are supported in index files.
No matter how sharing of sources is organized, it is important that all users share the same assignment of DCs to compartments and resolve component dependencies in the same way. For the flexible file system layout, this means that users not only have to share configurations, sources and libraries, but also the information about where to find the compartments of a configuration, that is, the configuration index files.
The information about the storage location of compartments is stored in a distributed way in index files . For each compartment, the configuration index file contains a path entry that denotes either:
Directory - contains all the components of this compartment and no components from other compartment.
File - a compartment index file that describes where to find the various components of that compartment.
The compartment index file defines for each DC the path of the root directory that contains the component. The component root directory is the directory that contains the component descriptor (.DCDEF).
Path relative to the location of the index file. Use it if a whole subtree of the directory structure is checked into some central source code management system. In this case, other users may synchronize this subtree to a different location on their local disk, but the relative paths would still work inside the subtree.
Recommended File System Layout
Although you can choose the file system layout, we recommend you establish a file system layout similar to the one used in the SAP NetWeaver Development Infrastructure (NWDI). This layout is based on practical experience and best practice, and is well suited for development projects of all sizes. The following figure shows an example configuration APL70P04 , which consists of several software components ( sap.com_BI-REPPLAN , sap.com_BI-WDALV and so on). All DCs are stored underneath their respective SCs, for example, sap.com/bi/alv is stored in sap.com_BI-WDALV .
Example file system structure for storing configuration APL70P04 consisting of several SCs
Proposed file system structure for an SC. All DCs that belongs to the SC are stored in the same folder
Note the inactive folder. This is the DTRworkspace and represents a certain state or release of the SC (a development state in this case). Other version control systems may use branches or something similar to organize different paths of development.
You can upload the configuration files (.CONFDEF files) and the corresponding compartment index files to the version control system too. Note that the Developer Studio cannot import such configurations directly from a repository.
More Information :