Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Naming !

I was never exactly satisfied with the "update mechanism" name (since it also provides for install, module lifecycle and so on), and this extra feature only makes it worse.
Splitting some components might shed some light on a better naming, and "module mechanism" might be the generic/overall name.

Magnolia.home

The Magnolia webapp should be markable as read-only; module jars should be loadable from outside the webapp folder (we don't want to(can not) write inside /WEB-INF/). Other files (repository, indexes, cache, ...) should also be written outside the webapp. See MAGNOLIA-2170@jira and the linked user-list thread for some background discussion.

...

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. This will also facilitate a potential future migration to OSGi.
Other than obvious candidates components such as i18n, links, audit, Jackrabbit support, etc, we could also envision that core or one of its extracted modules would register the "main" workspaces (website, users and so on) instead of having them hardcoded in repositories.xml. See MAGNOLIA-1666@jira.

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.

...

It it sometimes necessary to provide updates for such version; ideally, we should discourage it, and promote releases instead. This was needed for instance with the insm project; but it might also be fulfilled by providing a scripting interface (shell module) that has access to the module update tasks api.
See MAGNOLIA-1631@jira.

Security

The current update UI is totally open: provide a better/configurable page for public instances while updates are being performed. See MAGNOLIA-1629@jira.

...