Show TOC

Defining Development Component DependenciesLocate this document in the navigation structure

Use

You have to define dependencies to concrete development components (DCs) in one development configuration in order to use a source or artifact located in this DC. This situation is defined by the component model and allows you to establish better control over how the different parts of a development project are used.

Prerequisites

The DCs must reside in one and the same development configuration. You cannot declare dependency to DCs located in different development configurations.

To define a dependency between DCs that reside in different software components (SCs), the SC must have already established SC dependencies. For more information, see Defining Software Component Dependencies .

Procedure
  1. Open the Development Infrastructure perspective.

  2. Expand the development configuration's software SC in which the DC is located.

  3. Open the DC in the Component Properties view. Choose the Dependencies tab page.

Adding dependencies

  1. Choose Add... .

  2. In the development configuration, navigate to the DC you want to declare dependency from.

  3. Choose the checkbox of the desired DC or DCs you want to declare dependency from. Choose Next .

  4. Define the type of declared dependency to each selected DC or DC's public part (if any). As per SAP's component model, you can choose between the following types of dependencies:

    • Design Time

      Dependencies between DCs can be used by special tools.

    • Build Time

      Needed for the compilation. This dependency specifies that a DC is used during compilation or when wrapping another DC.

      Note that for build time dependencies, you can also specify a test type of dependency from the context menu. For more information about using the test dependency type, see Adding JUnit Tests to a Development Component .

    • Deploy Time

      Refuses deployment if dependants are missing. This dependency specifies that a used component must already exist in the runtime system to allow the using DC to be deployed.

    • Run Time

      This dependency specifies that a DC requires another DC at runtime. This means that it can be used meaningfully only if both DCs have deployable results.

      Note

      You may not be able to see all dependency types; the displayed dependency types depend on the public part's purpose - ASSEMBLY or COMPILATION . For more information, see Managing Public Parts .

  5. Choose Finish .

Removing dependencies

Select the dependency from the list and choose Remove button.

Common build time - runtime dependency mismatch

Example of possible dependency mismatch

In the following example we try to explain common behavior that might lead to a dependency mismatch, causing your application to fail at runtime. In the example development component (DC) A with public parts ppA (with purpose compilation) and ppAA (with purpose assembly) is a simple Java DC with no runtime representation on Application Server Java (AS Java). On the AS Java, you can deploy such a Java library as long as it is wrapped into a special server library DC. For that purpose, a DC B is created that assembles public part ppAA from the DC A (assuming that ppAA contains everything from DC A that is relevant at runtime). After that a Java EE Web module C is created. The DC C uses some functionality from DC A and therefore refers to the compilation public part ppA. DC C itself is assembled into an enterprise application D. However, when the runtime artifacts of the DCs B and D are deployed, the runtime does not know that D depends on B and likely fails.

To solve this situation, you have to create an additional dependency, that is, an at-runtime dependency between D and B. Then the build can generate appropriate runtime descriptors for both DCs including the necessary runtime references.