<createDependency> Step

This step creates a persistent dependency of the current component on another component. When executed, this step first checks for an installed component that matches the given criteria. The step fails if no such component exists (just as with the <checkDependency> step). If a match is found, a persistent dependency is created between the matching component, the “dependee,” and the calling component, the “dependent.”

If more than one installed component matches the criteria, which is possible if no install path is specified, the latest match is used as the dependee. The persistent component is created with the name that is specified in the step. The name must be unique among all dependencies created in the install block.

After the persistent dependency is created, it remains until the dependent component is uninstalled. If the installation of the dependent component fails in a subsequent step after having created a persistent dependency, the dependency is removed immediately at the time of failure.

A given component might depend on any number of other components by executing a <createDependency> step for each. The <createDependency> steps should appear as the first steps within an install block so that the installation will fail prior to performing any real work if the dependencies are not satisfied.

The <createDependency> step has one required child element, which identifies the dependee component. The child element is an installed component targeter. See Installed Component Targeters.

Attributes for the <createDependency> Step

The <createDependency> step has one required attribute of type identifier, name, which is the name of the dependency to create. The name must be unique among all dependencies created by the current component.

Uninstallation Implications for the <createDependency> Step

A component cannot be uninstalled if installed components depend on it. When an uninstall block of a component is encountered, if one or more persistent dependencies exist for which the component is the dependee, the uninstallation fails immediately.

However, if component B is being uninstalled by another component A, dependencies created by A on B will not prevent B from being uninstalled, and will be implicitly removed when B is successfully uninstalled.

The dependee component can specify actions to uninstall its dependents by using a <dependantCleanup> block.

Reinstallation Implications for the <createDependency> Step

A component installation is considered to be a reinstallation if a preexisting component in the same version tree is installed on the same host and install path. A component can be reinstalled only if the new component also satisfies all the dependents of the original component. A component can always be reinstalled with the same version component. However, a component can only be reinstalled with a different version if the new version also matches the constraints specified in the <createDependency> step that created the persistent dependency.

When a simple install block of a component is encountered, the provisioning software determines if the installation will overwrite an existing installation. If so, the provisioning software finds all persistent dependencies for which the existing component is the dependee, and reverifies that the constraints of the dependency are still satisfied with the new component being installed. If any constraints are not satisfied, the installation of the new component fails, and the original component remains installed.

Otherwise, if and when the new component successfully completes its installation, the component becomes the new dependee on all persistent dependencies. The original component is considered to be uninstalled and all of the persistent dependencies for which it was the dependent are removed. This implies that the new component is responsible for recreating dependencies, as needed.

Naming Conventions for the <createDependency> Step

Dependency names follow this format: xxx2yyy. The xxx indicates the name of the dependent component, and yyy indicates the name of the dependee component.

For example, a WebLogic managed server might have a dependency called server2domain on its admin server and a server2cluster dependency on its containing cluster. This convention facilitates self-documentation of the nature of the dependency relationship and makes it readable for both the dependee and dependent relationships of a particular component.