Rationale

Module updates and Magnolia updates are currently a little cumbersome; one needs to either rebuild their webapp, and move/copy lots of jar files. Making sure superfluous modules are removed and extra modules re-added can be tedious.
Other webapps have shown it possible since a while to have plugins downloaded from the internet right into the webapp and deployed automatically. In some cases, they don't even require a restart of the application in the application server.

Goals

• ease deployment, maintenance and updates of Magnolia modules
• faster spread of updates
• if modules are easily updated, the core of Magnolia and the bundling don't need to be updated as much, and the modules can really start flying at their own pace.
• (as a positive side-effect, we might be able to slim the main download's sizes)

Features / dependencies

In no particular approximate dependency order, here's a quick breakdown of independent features:

...

Magnolia-core will probably have to remain in the webapp folder: extract more out of core, so that it can also benefit from easy updates.

Detecting dependencies

Modules need to be bundled with 3rd party libs (e.g Quartz with the Scheduler module). Current limitation of our module system is that we don't provide any "check" - e.g Scheduler module bluntly fails to start after installation; thus blocking the complete system.
We maybe need to differentiate between inter-module dependencies and dependencies towards 3rd party/external libraries.

Our current module system already provides for the former.
Our current build provides "bundles", zip files including 3rd party libraries.

We can't currently detect 3rd dependency them (our module descriptor don't mention them), but if we download module "bundles", this wouldn't be an issue at first; we would however need to take into account possible conflicts.

Modules could also do self-checks, maybe by simply checking for a given class.

Additionally, if the Maven team do the same work for other Maven components than what they've done for Mercury, there might be a simple and small API to read a module's pom, and thus derive the external dependencies from. (I was actually able to do just that using org.apache.maven:maven-mercury's MavenDependencyProcessor.

Downloading artifacts

Mercury provides for this.
OSGi's OBR as well.

Hot (re)deploy

 No need to restart the app/appserver to deploy a module update. ("updates are ready: \[apply now, silently\] or \[click here for switching to the update UI when ready\]"; alternatively, we could maybe make it so that the system still works while updates are being applied, and switches "atomically" at the end? - or at least provide a configurable temp page for public instances) 

...

We're currently store the module related information in the configuration workspaces, in various places: current module version under /module/xyz/version, backup of some config nodes under /server/install/backup, information about extracted files under /server/install/mgnl-files. We could instead use a specific workspace.

External libraries

Modules need to be bundled with 3rd party libs (e.g Quartz with the Scheduler module). Current limitation of our module system is that we don't provide any "check" - e.g Scheduler module bluntly fails to start after installation; thus blocking the complete system.

UI

Missing dependencies should be reported in the ui.

...

Our current dependency system can state a minimal required version (i.e module X depends on Y 1.3 and up and on core 4.1 and up. Somehow, we'll have to be able to also say that module X 1.2 will not work anymore with Y 1.5, which is not something that we can determine when X is released. So this is probably something that needs to happen on the server-side of things.

Detecting inter-module dependencies

Handling of module's own dependencies (i.e non-Magnolia)

We can't detect them, but since our current build generates bundles including them, we could possibly do something about that. | Additionally, if the Maven team do the same work for other Maven components than what they've done for Mercury, there might be a simple and small API to read a module's pom, and thus derive the external dependencies from. | | | | |

...

Existing implementations, libraries, ...

• Examples of existing implementations of such features: Confluence, Hudson, ...
• We could(should) also evaluate OSGi, although my feeling is that it is very complex and bulky, and will incur more cost than bring benefits. Somehow I hope I'm wrong.
• We might also want to evaluate how to re-use the Maven infrastructure. This might be particularly interesting since our builds already deploy to Maven repositories, we might not have to invent much as far as getting new modules goes ! The current effort is going into "Mercury", which as far as I understand, will be a foundation block for Maven 3:
  • http://svn.magnolia-cms.com/svn/internal/testing-mercury/
  • http://www.sonatype.com/people/2008/11/what-is-mercury/
  • http://maven.apache.org/mercury/index.html
  • http://docs.codehaus.org/display/MAVEN/Mercury
  • http://docs.codehaus.org/display/MAVEN/HowTo+use+Mercury+for+accessing+repositories
  • http://repo2.maven.org/maven2/org/apache/maven/mercury/ (1.0-alpha-5 is available at the time of writing)
  • http://svn.eu.apache.org/viewvc/maven/mercury/trunk/

...