Elements of Development Configurations

A development configuration contains information on resources and services. The details depend on the selected development scenario.

Scenarios 2, 2+ and 3

·        Compartments: A compartment represents a particular state of a software component. Every compartment within a development configuration is specified by a unique name.

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 software components that

¡        Are developed and built in this development configuration

¡        Are built in this development configuration, but not changed

¡        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.

For more information on compartments, see Compartments.

·        Design Time Repository, Workspaces. To every compartment, a workspace in the Design Time Repository is assigned. A workspace contains the sources of a particular state of a software component. In the repository, workspaces are represented and accessed by URLs.

Scenario 3

·        Component Build Service, Buildspace. Every development configuration is represented in the Component Build Servce by exactly one buildspace. A service can provide any number of buildspaces and thus build several development configurations in parallel and independent of one another. A buildspace carries the name of the development configuration it represents.

The buildspace is responsible for:

¡        Activating changes

¡        Compiling changed and dependent components

¡        Providing information on the components that belong to the development configuration

¡        Providing up-to-date libraries and archives of components built in this development configuration

¡        Providing libraries and archives for used components.

The last two functions allow the SAP NetWeaver Developer Studio to retrieve all runtime archives required for local build and testing from a single server.

In addition, a development configuration refers to the build server that provides the appropriate buildspace for the development configuration.

·        Design Time Repository, Workspaces. To every compartment built in the development configuration up to two workspaces in the Design Time Repository are assigned. A workspace contains the sources of a particular state of a software component. In the repository, workspaces are represented and accessed by URLs.

The number of workspaces assigned to a compartment is determined from the compartment type.

¡        If the software component is developed in this compartment, there is one workspace each for the “active“ and “inactive“ sources of the component. The developers always execute changes in the “inactive” workspace and pass them to the build service there (“activation”). If the changed components can be compiled without errors, the build service then integrates the changes into the “active” workspace.

The active workspace can only be read but not directly changed.

¡        If the software component is built only but not developed, then there is only one workspace for the “active” sources of the component. This workspace is read-only.

¡        If a compartment contains nothing but archives, no workspace is assigned.

·        Variants. From the sources of a compartment, the build service can create several variants that

¡        Differ because of the selection of special parameters for the used compilers or generators. An example is the generation of an “optimized” and a “debugging” variant.

¡        Are designed for different operating systems or runtime environments

¡        Consider country-specific or language-specific peculiarities.

If variants are defined for a compartment, the compartment provides specific libraries and deployable archives for every component and every variant (build variants).

The development configuration contains a list of variants for every compartment. Not all compartments must offer the same variants. For example, one component can exist only as an “optimized“ library while a user itself is compiled in the “debugging” mode. Within a development component, variants must have unique names; for every compartment, at least one variant must be defined.

·        Aliases. A development component can contain compartments that represent different states of the same software component.

This can be necessary if a using component must be compatible with different states of a used component. Unfortunately, in this case dependency declarations based on the component names, lose their uniqueness. Therefore, in a development configuration you can define a unique alias name for every software component, to which other components can refer.

·        Name service. The names of components must be globally unique.

The name of a component always consists of two parts: The first identifies the vendor or creator of a component and is usually derived from an Internet domain, such as “sap.com”. The second part can be chosen at will by the vendor, but must be unique within the domain.

To guarantee the uniqueness of names in a domain, you can enter a name service in the development configuration that reserves names and namespaces for components (and for other development objects such as Java packages, if required).

For more information on the name service, see Reserving Names.

·        Change Management Service. The Change Management Service (CMS) manages the transport of software changes within the SAP NetWeaver development landscape.

A development configuration points to the Change Management Service, which is responsible for transporting the changes from this development configuration.