Rationale
With removal of old code and further advances in modularization of the project we need to restructure again to remove modules replaced by new ones. We should also take this opportunity to trim the bundles and give them time to settle down through enough release cycles before production release.
Changes - main project
- remove
magnolia-module-admininterface,magnolia-guiandmagnolia-module-fckeditorfrommagnolia_mainproject- those modules are replaced by
magnolia_ui - modules needing a dependency on the old UI modules will temporarily use the 4.5.x version as long as they are not fully migrated to 5.0
templatingdependency onmagnolia-guiis downgraded to 4.5.x
- those modules are replaced by
- remove
magnolia-module-exchange-simple, magnolia-module-cacheandmagnolia-module-store-clientfrom main project. exchange-simplewill be renamed toactivationactivationwill need to be worked on extensively soon to allow other modes of publication, plus it has dependencies toui
Changes - STK
- downgrade dependency on old UI to 4.5.x
- replace dependency on
exchange-simplewithactivation - update dependency on
cacheto new groupIdinfo.magnolia.cache
Changes - CE modules
mail, templating-samples, imaging, data, dms, templating-compatibility-taglib-cms- dependency on
old UI modulesis downgraded to 4.5.x
- dependency on
databranched. 4.5.x compatible module is in the 1.7.x branch. Master version is
1.8and is5.0compatible
dms- branched due to a dependency issue with
fck-editor(changedscopefrom provided tocompile) . 1.6.x is the 4.5.x dev line, 1.7.x is 5.0 only compatible. - should be completely replaced by the new
dammodule in the next sprint
- branched due to a dependency issue with
Changes - bundles
- add dependency to
m-m-exchange-simpleandm-m-cacheinto bundle since they are no longer brought in as part of the main project - do NOT declare dependency on
m-m-admininterface,m-m-fckeditororm-gui- as long as they are brought in by other modules into bundle we know we still need to work on those other modules. - replace dependency on
exchange-simplewithactivation - update dependency on
cacheto new groupIdinfo.magnolia.cache - bundle
add-onsseparately- modules in
add-onshave their own release cycle and we should make it flexible for ppl to download those modules. Also currently if one needs war file only (e.g. for Weblogic) andgroovymodule fromadd-onsone has to download groovy from nexus or take the whole bundle including the tomcat.
- modules in
- put only single copy of webapp in the bundle and have startup script to copy it on first start
- alternatively investigate possibilities for improving compression rate on bundles, currently they seem to only pack the things but not compress
Tools
- The old tools pages will be temporarily hosted in an App consisting of an iframe pointing to the old pages.
Not part of this iteration
breakdown ofm-m-admininterfacecode that is still useful and moving it into core- removal of dependencies on
m-m-admininterfacefrom other modules (cache, exchange-simple, data, dms, ...) rewrite of
m-m-store-clientor pages brought by other modules into old AdminCentral. Tools won't be migrated in this sprint.
Breakdown of m-m-admininterface
adminInterface contains valuable code used by several projects, notably what is contained in
- info.magnolia.module.admininterface.commands
- commands will end up in several modules (core, activation, etc.), according to their purpose and scope. See more at Commands
- the pages mechanism e.g. PageMVCHandler.java, PageMVCServlet.java and the like.
- those classes are needed to allow wrapping old UI pages as an M5 App (the page is displayed within an iFrame) with just minimal config and keeping the same structure as in 4.x,
i.e. the html page or client-side resides under src/main/resources in the same package as its server-side counterpart.
We are currently using this mechanism in M5 for bringing into AdminCentral the GroovyConsole and other Tools pages. See info.magnolia.ui.admincentral.app.tools.*
This means that third-party modules UI do not need to be necessarily rewritten as a proper M5 app before they're ready for M5. This should encourage early adoption of M5 and give devs more time to rewrite their UI the M5 way.
The pages mechanism will end up in a m-adminInterface-legacy jar
- those classes are needed to allow wrapping old UI pages as an M5 App (the page is displayed within an iFrame) with just minimal config and keeping the same structure as in 4.x,
Once done with this task, dependencies to old adminInterface module should be removed from all our modules still depending on it.
3 Comments
Magnolia International
Pascal Mangold
Please think about translations - it's even if we drop it for the time being - but we need to think of it as an important piece
Jan Haderka
restructuring will just move
m-m-admininterfaceout of main project, but not drop any code, including translations.New AdminCentral is not i18n aware yet, but indeed we should take care to bring translations on to new module when appropriate. I don't think that will happen before alpha-1 tho.