In the past, we've tackled with the idea of splitting core several times: Repository dependencies split-up, Concept - Core & jaas split, Proposal - core packages, ... Core has grown to 800+ classes and has many test classes. As such, it is becoming increasingly difficult to package, test, and design features new and old. Some fairly old code is barely used anymore; most code is stable, but would benefit from better packaging and design. The first targets will be things that have no dependencies on our own APIs, e.g., JCR Utilities (predicates, wrappers, etc.). Other example cases would be content-i18n, security, virtual URIs, etc.
Isolating features in smaller modules would help incrementally refactoring, rewriting or throwing code away.
In the future, some of those split out modules could even move out of
magnolia_main, because they'll be very stable and have different life cycles (e.g., JCR Utilities).
With this and some modules being split out of
magnolia_ui, we might even be able to "merge" main and ui into what it really is: Magnolia Platform
After some initial tests, what was a 3-step gradual implementation of the above is now a 4-step one. We added step #1 to the original proposal. We'd do this in 4 steps to give margin to users (and ourselves) to upgrade their dependencies. Ideally with Step #1 no change is needed for people who already use
magnolia-project or one of our webapps.
|Step #1 - 5.4||Step #2 - 5.5 ?||Step #3||Step #4+|
We have a lot of semi-cyclic dependencies in our code; package dependencies are a mess.
We also have a lot of unused code, or deprecated code still in use.
As a first step, we'll implement some changes to these problems, which will make step #2 easier (or possible at all).
We have scripted the split that could occur with 5.5; with CI and perhaps tools like Sonar, we gradually aim to make this possible.
We gradually add "splits" to the script in question and gradually improve the existing code base to make the split possible.
The Jenkins job is current at https://jenkins.magnolia-cms.com/job/platform_core-split/
Two use-cases to take care of and verify:
- Building a project/webapp: release notes should insist on people using scope:import to make sure they bring in the correct versions of all our artifacts.
- Building a module: release notes should indicate new coordinates; if a module depends on info.magnolia:magnolia-core:5.4, it will be redirected to core-all, with the "real" dependencies being one level lower than they were; if another dependency of the module-under-build has already been updated to use the new coordinates, the module might end up being built against the wrong version of core-x. Developers should be able to do 2 things: use scope:import as well (not recommended, since this will still bring in the relocation message, or they'll have to adapt the dependencies to bring in the "real" dependency they need from core), or simply change their dependencies. With Maven 3.2.3 and some careful testing, we can come up with a simple guide. (Use dependency:analyze to figure out which one you need).
We discarded the idea of using an uberjar (instead of the core-all which simply brings dependencies, it would have them physically in its jar. While there are options to build an uberjar of modules and generate/deploy a pom that does NOT have dependencies to these modules (which would be needed, or we'd end up with the uberjar AND the "normal" jars in the webapps), it would not solve the cases where people depend on core AND, say, dam.
Scripts currently reside at https://git.magnolia-cms.com/user/gjoseph/core-split-scripts. Check the
README.txt for usage.
- Not 100% sure on which approach is best yet (relocation>uberjar or relocation>dependencies)
- We did something very similar with DAM 2.0 : https://jira.magnolia-cms.com/browse/MGNLDAM-403 - here we redirect to
magnolia-dam-compatibility, which has "old" APIs we want to ultimately remove, but also has dependencies to all other new modules.
- If considering uberjar, see the Maven Shade Plugin, and in particular these options:
artifactSet(include only info.magnolia* artifacts, not transitives),