You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

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.
  • Versions / dependencies: 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. Sounds like this will have to be marked on the server side ("store"), when it happens... ?
  • 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, ...

  • No labels