Dependency Resolution refers to substitution of a suggested setting
of an attribute in a policy and modifying that attribute into
an actual setting. Dependency resolution is done in the
classpath and
codebase of your component. The suggested setting can be
found in the
resolvableClasspath string array and
resolvableCodebase string array attributes of the
InstallableComponentDescriptorPolicy object. The actual mapping
generated by the dependency resolver can be found in the classpath
and codebase URL array attributes of the Installable Component
Descriptor Policy.
The following is an example of component dependency and its implications.
Consider three components A, B, and C, and their dependencies.
Here, component A depends on B, and B depends on C.
When component C gets installed, the state of component C will
change to
RESOLVED since it is a leaf in the graph, having no dependencies.
If component B is installed before component C, its state will
be INSTALLED.
It cannot be
RESOLVED, since there is no component C on the system. If
B is installed after C, its state will be RESOLVED since C is
known to exist and is in a RESOLVED state.
It is possible to inadvertently create a
circular dependency.
Consider the following:
Now A, B, nor C will ever change to a RESOLVED state.
Be wary of this when developing your components.
Multiple Component Versions
It's possible for a user to install several versions of
the same component where each version has some subtle difference.
The user may opt to list a dependency on a particular version
in a component's resolvableClasspath or resolvableCodebase array.
This is done by appending a hyphen and the version to the componentName
in the dependency.
${componentName-[version].classpath}
The version must be the same as the
version attribute found in the Installable Component Descriptor
Policy.
Important Point: Install Service tries to resolve dependencies if it can
Consider, for example, CompA has a dependency on
CompY. Furthermore, let us consider there are several versions
of CompY installed. This could happen if some sort of prototyping
were being tested. All the versions of CompY are listed in the
image below. The most recently installed version of CompY is at the
top of the list.
Important Point: If there exists several versions of
a component and a particular version of a component in a dependency
is not specified, Install Service will look for the most recently
installed version of a component that is in a
RESOLVED state.
For example, let's say compA has a classpath dependency on compY-1.
Then the
Resolvable Classpath attribute in the
InstallableComponentDescriptor will have an entry
${CompY-1.classpath}
If the entry in the Resolvable Classpath array is instead
${CompY.classpath}
Install Service will resolve the entry by choosing
CompY-8, not CompY-1 . Install Service tries
to resolve components if it can. Since a version was not
specified and CompY-8 was installed before CompY-1 and its
state is RESOLVED, Install Service will chose CompY-8 to
resolve CompA's classpath dependencies. Notice, the other
components were not considered. That's because their states
are INSTALLED.
There is more to this dependency business and that has to do with
how dependency substitutions are specified.
Next: Dependency
Substitution
