Page History
...
In no particular order, here's a quick breakdown of independent features:
|
|
|
|
|
| ||
---|---|---|---|---|---|---|---|
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. |
|
|
|
| ||
Split core | 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. |
|
|
|
| ||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a800e7852a8504df-66ddf507-4de6469c-a1bfa964-135fd1edde92281b8522379b"><ac:plain-text-body><![CDATA[ | 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) |
|
|
|
| ]]></ac:plain-text-body></ac:structured-macro> |
Uninstall modules | Most of our modules are actually fairly easily uninstallable (see docu, it's mostly removing the jar and removing a few specific nodes), so this should be feasible. Provide backup of removed nodes for safety. Uninstalls could be "automatic" when a jar removal is detected (i.e when restarting the server) or done through some form of gui. Potential implementation would imply serializing the tasks-for-uninstalling at install time. (store result of ModuleVersionHandler.getUninstallTasks()) |
|
|
|
| ||
Security | The current update UI is totally open: provide a better/configurable page for public instances while updates are being performed. |
|
|
| |||
System workspace | We're currently store the module related information in the configuration workspaces, in various places: current module version under |
|
|
|
| ||
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. |
|
|
|
| ||
Server side | Where and how do we deploy and publish modules. |
|
|
|
| ||
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. 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. |
|
|
|
| |
Downloading artifacts |
|
|
|
| |||
Updating a module without restarting the app container | We can already restart a module. Missing points: * restart this module's dependencies in the appropriate order. (restarting all is probably good enough)
| out of scope |
|
|
| ||
Uninstalling a module | not implemented. Implementable. (would need some form of gui, or serializing the tasks-for-uninstalling at install time) |
|
|
|
|
...