GREYGREY
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.
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.
Examples of existing implementations of such features: Confluence, Hudson, ...
Overview
Content Tools