Automating packages deployment: CRX HTTP API/OSGi Installer?

[OlivBur]

Hi,

I would like to automate a bit the deployment of CRX/Vault packages to AEM instances. As of now I know about these two possibilities:

- CRX HTTP Service API: Using cURL or some other tool to upload/install/uninstall/etc. packages via CRX

- Sling OSGi Installer: Simply uploading bundles or vault packages to som ".../install" or ".../config" folders. The OSGi Installer then picks these packages for installation.

What do you use or do you prefer?

Or what's the Adobe AEM recommended approach?

[Vish_dhaliwal]

Hello,

The first approach seems to be structured and reliable.

The second approach does not allow proper automation mainly because, unless a log analyzer is being used, there is really no feedback on the success/failure of package deployment.

Did you take a look at content-package-maven-plugin [1]?

[1] Managing Packages Using Maven

[OlivBur]

Hi Vish.dhaliwal​

thanks for response. Yes I'm aware of the content-package-maven-plugin.

I think actually too, that the usage of the CRX HTTP API is like the more structured way.

But I have heard once at some AEM/Sling Conference, that the installation handling via the OSGi Installer is much more stable because the Installation via the CRX PackageManager does not respect properly the OSGi bundle lifecycle specifics, etc.

To make sure the installation was successful via OSGi Installer we could check the bundle status or the existence of some nodes in /apps or also having a custom Health check endpoint for its application.

Also I haven't found anymore an official CRX HTTP API documentation. Has this been moved/removed somehow? Or will this CRX HTTP API be deprecated in near future?

[Jörg_Hoh]

It's true, the HTTP API documentation for the package manager went missing in one of the latest versions of the product documentation. Can you raise a Daycare ticket for it and ask to make it available again?

Regarding OSGI installer ("install" folder) vs package manager: From a reliability point of view they are the same; the only limitation is that you cannot deploy OSGI bundles via package manager, but you need to wrap them into packages. But internally both use the OSGI installer to start the bundles.

But I still prefer the package manager, because it's quite easy to make your AEM unusable with the install folder:

* copy a bundle into the install folder

* wait till it is installed

* shutdown the AEM instance

* remove that file from the install folder

* startup AEM again

(ok, this isn't a problem when you just use content packages.)

On the other hand side the package manager HTTP API is a bit problematic, because just uploading and installing packages in a row does not always work, and you need to handle the error detection, retries etc. Doable but the many trivial "automation scripts" you find in the internet only focus on the happy path. Might work in 90% of all cases.

[OlivBur]

Thanks Joerg for your feedback. I have created now a Daycare ticket for the missing documentation.

According to the "pure" OSGi Installer approach, I thought more of uploading the package or bundle directly to the "install" folder/node below /apps in the JCR repository, so not the install folder in the filesystem.

I think a main challenge here is the deployment of configurations. Depending on which configurations you upload, the Felix container restarts several or even all bundles, which causes then this Unavailability of the system for some seconds/minutes.

[Jörg_Hoh]

Hi,

wenn you mean uploading directly into the /apps/<yourproject>/install folder, then there's no real difference between the package approach and the one you describe. Because in both the JcrInstaller is going to pick up that bundle. The only difference is that you do the installation explicitly one-by-one, while the bundles installed via package manager are typically picked up all at once (because the interval between these changes is normally much lower).