GREYSimplify the updates of Magnolia instancesGREY
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 order, here's a quick breakdown of independent features:
- Magnolia should be markable as read-only; module jars should be loadable from outside the webapp folder. See MAGNOLIA-2170@jira and the linked user-list thread for some background discussion !
- Figure out the server side: where/how do we deploy and publish modules. OSGi or Maven might provide help here.
- 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.
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)
- Secure the update UI (it's currently totally open) - provide a better/configurable page for public instances while updates are being performed.
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://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/