With Magnolia 5.6 we have replaced the old Content API in some of our modules. This page explains in more detail what we have done and what you have to know if you are upgrading custom bundles with custom modules.

Some history to start with

Years ago, Magnolia introduced its own JCR content API layer. Despite being deprecated with Magnolia 4.5 (see the links at bottom of the page), the API continued to live and some Magnolia modules were still using the code of this so-called "old Content API". With Magnolia 5.6 we've begun removing the old content API from our modules.

Modules affected

Please read carefully the How to upgrade section, especially if you have custom code or custom modules relying on the following modules:

What has changed?

With the exception of the Workflow module, the modules' Maven artifacts got new Maven artifactIds and groupIds. Every Maven module with the old artifactId and groupId has turned into the Maven relocate, a module which contains only a POM file with a Maven relocation message. 

In addition to the Maven relocate and the actual artifact with the relevant code where we have removed the code usage of the old Content API, there is always a new submodule which ensures backwards compatibility.

Before Magnolia 5.6Since Magnolia 5.6Meaning
Old moduleNew moduleContains module functions without using the old Content API.

Maven relocateContains a warning message that the module has been relocated. The message is displayed in the shell during a Maven build.

Compatibility module

Provides the old functions, uses the old Content API.

This module is only required if you have custom code or custom modules relying on functions which were using the old Content API.

Example: Form module

Before Magnolia 5.6After Magnolia 5.6 (since Form 2.4)

Old module:


New module:


Maven relocate:


Compatibility module:


Please note that the old module and the Maven relocate have the same Maven groupId and artifactId.

Some of the modules listed above have more than one submodules which have been changed and relocated.

How to upgrade

No custom code based on the affected module

If you have no custom code based on the affected (sub)modules, just make sure that your webapps get the "New module". You will need neither the Maven relocate nor the compatibility module. You can manage your changes with Maven in your POM files or by manually dropping the JAR files.

Custom webapps based on Magnolia webapps

Magnolia webapps manage dependencies of the included Magnolia modules. The dependency sections of the Magnolia webapps have been updated and reflect the required changes. However, depending on the approach you have used when creating your custom webapp, you have to check and adapt your custom dependency section. All you have to do is to update the POM file of your custom webapp by replacing the Maven parameters for the old module with parameters for the new module.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels