Concept - Project restructuring

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-gui and magnolia-module-fckeditor from magnolia_main project
  
  • 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
  • templating dependency on magnolia-gui is downgraded to 4.5.x
• remove magnolia-module-exchange-simple, magnolia-module-cache and magnolia-module-store-client from main project.
• exchange-simple will be renamed to activation
• activation will need to be worked on extensively soon to allow other modes of publication, plus it has dependencies to ui

Changes - STK

• downgrade dependency on old UI to 4.5.x
• replace dependency on exchange-simple with activation
• update dependency on cache to new groupId info.magnolia.cache

Changes - CE modules

• mail, templating-samples, imaging, data, dms, templating-compatibility-taglib-cms
  
  • dependency on old UI modules is downgraded to 4.5.x
• data

  • branched. 4.5.x compatible module is in the 1.7.x branch. Master version is 1.8 and is 5.0 compatible

• dms
  
  • branched due to a dependency issue with fck-editor (changed scope from provided to compile) . 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 dam module in the next sprint

Changes - bundles

• add dependency to m-m-exchange-simple and m-m-cache into bundle since they are no longer brought in as part of the main project
• do NOT declare dependency on m-m-admininterface, m-m-fckeditor or m-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-simple with activation
• update dependency on cache to new groupId info.magnolia.cache
• bundle add-ons separately
  
  • modules in add-ons have 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) and groovy module from add-ons one has to download groovy from nexus or take the whole bundle including the tomcat.
• 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 of m-m-admininterface code that is still useful and moving it into core
• removal of dependencies on m-m-admininterface from other modules (cache, exchange-simple, data, dms, ...)

• rewrite of m-m-store-client or 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 

Once done with this task, dependencies to old adminInterface module should be removed from all our modules still depending on it.