Show TOC

Development Resources ShareLocate this document in the navigation structure


When developing on the basis of the component model, but without SAP NetWeaver Development Infrastructure (NWDI) support, no assumption is made about how you handle or organize the sharing and distribution of development results. This depends on the concrete version control system and build environment you are using (if you are using any at all). This also means that no explicit support can be provided by SAP for sharing sources or artifacts. This development is completely based on the local file system. The tools included in the SAP NetWeaver Developer Studio can create and find DCs only in the local file system.

When you work on a development project, you have to share your source files (no matter what type they are - development components (DCs), Eclipse project and so on) among the team members. In most cases, you use some source code management and versioning system. Small teams may not even need a version control system, but just use a file system share or a special server for the same purpose. In addition to the developers themselves, there may also be others that need to share these sources, for example a central automated build process. The central build produces another kind of development results that have to be shared properly among the team members, that is, the compiled sources, packed to archives or deployable archives. We refer to them as buildartifacts , or simply artifacts .

Development teams are free to use any suitable central source code management and versioning system as long as it is based on files and directories. In that case, you on your own have to retrieve all necessary source files of a DC from the appropriate version control system, and the required libraries from the central build environment.

For some common source code management systems, there are already suitable Eclipse plug-ins available that you can use together with the Developer Studio. These plug-ins are not aware of concepts like the SAP component model and therefore integration is only possible at file system level. A consequence of this is that even some of the genuine SAP plug-ins that handle components have certain limitations.


The Component Browser view in the Developer Studio can no longer be used for browsing, downloading, creating or managing components stored remotely either as sources in a Design Time Repository or as artifacts on a Component Build Server. This makes sharing of DCs somewhat inconvenient, but it is still possible. Anyway the Component Browser can still be used to browse and manage componentslocally , as long as they reside somewhere in the local file system.

Another feature that is not supported is the automatic search and retrieval of DC dependencies. The using DC declares a dependency in the descriptor (the .DCDEF file) only by the name of the used DC.

It is possible even in small development teams in which team members develop against wrong or old releases of libraries, leading to inconsistencies and integration problems in later stages of the development life-cycle. You have to establish a manual process that ensures the consistency of the used libraries throughout the development life cycle. You have to take special care in the materialization of components in binary form, that is, as build artifacts from a central make environment.

Local Development Configurations


When developing based on the SAP component model without NWDI support, you do not have an infrastructure for sharing the configurations. However, since a configuration is just a file, you can easily share it by putting it on a Web server or sending it around by e-mail.

When you create a new software component (SC), it automatically generates a single file as well which we call the development configuration file. It describes the specifics of the development and you can use it to coordinate the people in different locations that should work on the same SC. The development configuration allows you to develop your local components offline. In this way a configuration simplifies the development process, but only if all developers working on a certain development project share the same configuration.


You can create the development configuration using the Developer Studio, which also supports the export of development configurations to the file system. Your organization can establish a naming convention that ensures the configuration is uniquely named. The team lead can distribute the development configuration using the Web server or e-mail. Then the team members just import the development configuration file into the Developer Studio. The Developer Studio automatically updates the existing development configuration with the new version.

Small development projects may start with only one simple development configuration with a single SC. In time, the need for more complex development configurations arises. For example, additional SCs may be added, or several configurations may be used in parallel for different releases of the software. These more complex situations require a careful planning and maintenance of the file system layout especially when a version control system is used to share sources among developers.


  • Archive pool.

    Within the Eclipse based plug-in archive pool, you can find a set of binary DCs. The local development configuration automatically provides the content of the archive pool as a set of corresponding compartments. More information: Extending the Archive Pool .

  • Source compartment.

    A compartment represents a particular state of an SC. Every compartment within a development configuration is specified by a unique name. For example, a development configuration contains compartments for the software components SC1, SC2 and SC3. The compartment for SC1 represents the state SC1_5.0_DEV (that is, a development state of release 5.0). The other compartments contain the states SC2_6.2 (release state 6.2) and SC3_2.0 (release state of component SC3).

    Compartments can represent the following types of software components:

    • Software components that are developed and built in this development configuration.

    • Software components that are built in this development configuration, but not changed.

    • Software components that are imported from outside into the development component and exist only in the form of libraries or archives.

    Compartments can declare relations to other compartments, thus allowing or restricting the use of components from these compartments. Since compartments always represent a particular state of a software component, the relations between compartments indirectly also determine the relations of these states.

    SCs do not maintain an explicit inventory of their DCs, but leave this to the compartment they are assigned to in a certain development configuration. Here a single directory represents a compartment in a file system, and therefore a development component (DC) is assumed to belong to a certain compartment if it is stored underneath the compartment's root directory.


    We recommend that you represent compartments by corresponding directories in the versioning system, and to store DCs underneath their respective compartments. Otherwise, the association between DCs and compartments has to be recorded and tracked manually.

    More information: File System Layout

  • Define a configuration and store it in a file using the Developer Studio. You can use multiple local configurations in a Developer Studio.

    More information: Managing Development Configurations .

  • Use multiple source compartments.

    A single directory represents a source compartment in the file system. This directory contains all DCs belonging to that compartment. Such compartment directories can reside at arbitrary locations in the local file system. The DCs directory is no longer necessary and may be omitted. Upon refresh, the Developer Studio searches for DCs underneath the compartment's root directory. The locations of the compartment directories are maintained in an index file (.CONFDEF-IDX) attached to the configuration.


    We recommend you follow the standard file system layout of the component model, no matter that components may be arranged freely underneath the configuration's root directory.

  • Use multiple archive compartments.

  • Freely define dependencies between DCs.

    More information: Managing Development Components