Deploying modules in Rhino

There are seven module structures supported by the SLEE deployer.

SLEE component jar modules are the most common type of module, and are the recommended type of module for any new development.

The most important part of the dependencies shown is the ‘conf=’ portion.

From SLEE component jar module to SLEE component jar module

From SLEE component jar module to deployable unit jar module

From SLEE component jar module to deploy script module

From SLEE component jar module to Group module

Group modules are often created to group together logically related modules.

Group modules depend on the related modules. Group modules often have no source code, and so do not need to compile anything. Therefore the “api” conf is not used.

From group module to slee-component module

From group module to deployable unit module

From group module to deployment script module

Deployable unit modules are sometimes used, due to the restriction of 1 slee-component being allowed in a slee-component module.

The most important part of the dependencies shown is the "conf=" portion.

From deployable unit module to slee-component module

From deployable unit module to deployable unit module

From deployable unit module to deploy script module

When the deployer is invoked with the ‘deploy’ target, it attempts to deploy just that one module into the Rhino SLEE. The module is based on the current working directory.

Any properties needed by a module can be passed in using the -Dpropertyname=propertyvalue syntax of Ant.

Prior to deploying the module it:

When the deployer is invoked with the ‘deploy-with-deps’ target, it attempts to deploy all modules in the Ivy dependency tree that are not yet installed in the Rhino SLEE. The Ivy dependency tree begins from the module in the current working directory.

Any properties needed by any module in the dependency tree can be passed in using the -Dpropertyname=propertyvalue syntax of Ant.

This is achieved through the use of the Ivy dependencies between modules.

The deployer first checks the immediate dependencies of a module, and selects dependencies that have suitable Ivy configurations. For each of those immediate dependencies (let’s call each dependency a parent module), it:

In this manner the deployer is able to be invoked multiple times, only deploying modules that need deployment.

When invoked with the ‘deploy-with-deps’ target, the deployer traverses each module’s dependencies of each module in a predictable order. By default, the deployer will deploy all of a module’s dependencies first. The dependencies are ordered according to their organisations, names, branches and revisions. The deployer will then deploy the module itself.

This order can be controlled for a module by setting the ‘e:deployorder’ Ivy attribute in a module’s Ivy descriptor. The ‘e:deployorder’ Ivy attribute contains a comma separated list of module names. Each of the module names corresponds to one of the module’s dependencies, or to the module itself.

In the following example, module my-module declares that my-dependency-1 should be deployed first, followed by my-dependency-2, followed by itself.

Note that specifying the value ‘a,b’ in the ‘e:deployorder’ Ivy attribute of module m does not guarantee that a will be deployed before b. For example module b could reached when traversing the graph before module m was visited. The ‘e:deployorder’ attribute only controls the order in which the deployer iterates over `m’s dependencies.

If any of the named modules do not refer to the dependencies of the module or to the module itself, the deployer will log a warning and continue rather than failing.

The deployer creates a directory named target/deployer-work for all temporary work. This directory is used for downloading artifacts needed for analysis and deployment.

The directory is deleted after a successful deploy. If the deploy fails, then the remainder is left on disk for diagnostic purposes.

When a module is published, its dependencies are published along with it.

Assume that there are the following modules:

The group module depends on the feature module. The feature module depends on both the mapper and profile modules.

When all modules are built, the ‘publish-local-branch’ target is used.

The first time ‘publish-local-branch’ target is used, the following is published

When the deployer reads the published group module or feature module it will retrieve revision 1.0.0-DEV0, and follow the dependencies to published revision 1.0.0-DEV0 of the appropriate module.

Then, if all modules are rebuilt, again using the publish-local-branch target, the following is published (previous publications still exist too):

Next, if some logic is changed in the profile module, then only the profile module is built via publish-local in the profile module, the new revisions would be:

When the deployer reads the latest integration of the feature publication, it will see that it depends on profile revision 1.0.0-DEV1, not profile revision 1.0.0-DEV2. So it would have to deploy profile revision 1.0.0-DEV1. This would likely cause confusion, as the changes to the profile would have not taken effect!

This is almost certainly not the desired result (after publishing some changes to the profile).

To avoid this situation, by default the deployer checks that the dependent revision of a module is also the most recently published revision of that module. If those two revisions are not equal, it will not deploy anything into Rhino.

Here’s what the error message looks like:

To override this behaviour, add the -Ddeployer.latest-revision-checks.enabled=false to the ‘deploy’ or ‘deploy-with-deps’ target:

The undeploy and undeploy-all targets will not remove components if there are other components which depend on them. Therefore, if a Service or SBB depends on a feature, then an attempt to undeploy the feature will fail.

It is recommended to unbind (either through unbind or unbind-all) prior to undeploying.