Defining Development Component Dependencies
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
-
Open the Development Infrastructure perspective.
-
Expand the development configuration's software SC in which the DC is located.
-
Open the DC in the Component Properties view. Choose the Dependencies tab page.
Adding dependencies
-
Choose Add... .
-
In the development configuration, navigate to the DC you want to declare dependency from.
-
Choose the checkbox of the desired DC or DCs you want to declare dependency from. Choose Next .
-
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.
-
-
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.