Maven Build Profiles and the Sling JCR Install Service

05287_Maven-Build-Profiles-and-the-Sling-JCR-Install-Service

tldr;
Doing both autoInstallPackage and autoInstallBundle at the same time can cause conflicts in the OSGi/Felix/System/Web Console as it installs the jars. JCR config and install folders will not work correctly when the conflict happens. Just do autoInstallPackage. If there is a conflict, there will be folders to mark progress under /system/sling/installer/jcr/pauseInstallation—delete them, and then things should work.

I have been seeing this issue on some local environments, and recently we had issues on a customer’s servers that are being built by bamboo. In our builds, we have zips and jars. The zips go into the JCR and the jars go into the OSGi. autoInstallPackage triggers the content-package-maven-plugin, which picks up the zips and throws them into ${crx.serviceUrl}/crx/packmgr/service.jsp. Similarly, autoInstallBundle triggers the maven-sling-plugin, which picks up the jars and throws them into ${crx.serviceUrl}/system/console/install.

So autoInstallPackage is to zip, JCR, and packmgr, as autoInstallBundle is to jar, OSGi, and system/console.

One of the zips in most projects, here at Axis41, is called bundle-install. It embeds the jars from the project bundles, puts them in a zip package, which then gets installed to the JCR at /apps/[project]/install. The package should also include the OSGi configs in the /apps/site/config.[runmode] folders. The Sling JCR Install Service listens to those two folders, takes the jars and configs, and installs them into the OSGi container. We use this strategy because we have found that having the entire project build to zips to feed into the packmgr gives us more consistency and agility when moving code around.

If the jars in the bundle-install zip try to install at the same time that ${crx.serviceUrl}/system/console/install is catching the jars, there will be a conflict and the installation will enter a paused state, marked by nodes under /system/sling/installer/jcr/pauseInstallation. In this paused state, the Sling JCR Install Service stops listening to the config and install folders. The runmode dependent configs you build in the project will not get applied to the OSGi services, and new jars trying to get installed through the install folder will do nothing. To return the JCR Install Service to normal operation, delete the nodes under /system/sling/installer/jcr/pauseInstallation.

To prevent this from happening in the first place, always install bundles via the bundle-install content package by using the autoInstallPackage profile. Make sure your automated builds are doing that too. While you’re working within a single bundle, autoInstallBundle is meant to provide a way to more rapid deploy/test the bundle, but it shouldn’t be used in combination with autoInstallPackage. Using both profiles at the same time to ensure the bundles install is usually a result of improperly configured bundle-install pom, which needs both a dependency and an embed block for each of your bundles. If you rely on manual code deployments through zip files and the Package Manager then the process of deployment should not have any issues.