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.

...

We're currently store the module related information in the configuration workspaces, in various places: current module version under /module/xyz/version, backup of some config nodes under /server/install/backup, information about extracted files under /server/install/mgnl-files. We could instead use a specific workspace.

Splitting of module "configuration" class and ModuleLifecycle

These are IMO two separate concerns (starting 3rd party components, preparing resources, ...) and holding configuration. Of course, the lifecycle will need the configuration, so the former will be passed or made available to the latter.

UI

Missing dependencies should be reported in the ui.

...