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.
Please read carefully the How to upgrade section, especially if you have custom code or custom modules relying on the following modules:
- Content Translation Support module
- Diff module
- Form module
- Forum module
- Groovy module
- Imaging module
- Public User Registration module
- Tools module
- Workflow module
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.6||Since Magnolia 5.6||Meaning|
|Old module||New module||Contains module functions without using the old Content API.|
|Maven relocate||Contains a warning message that the module has been relocated. The message is displayed in the shell during a Maven build.|
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.6||After Magnolia 5.6 (since Form 2.4)|
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.