Rationale

...

• proxy usage (i.e so the Magnolia instance can access the Internet)
• location of repositories, along with username and password. Are we satisfied with no encryption of this information (if so we only need the url.... http://username:password@repository.magnolia-cms.com/restricted^{Image Removed})

Splitting our repositories

If we're going to use our Maven repositories (which seems quite likely), we'll need to move away all the projects/3rd party stuff .and closely monitor them

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)

We can already restart a module. Missing points:

...

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.

To investigate

Hudson has (or had) a feature that would let one restart the app.server at the click of a button. Perhaps this is a Winstone-only feature. Would like to see how they did this ...

Existing implementations, libraries, ...

Examples of existing implementations of such features

• Confluence
• Hudson
• Struts 2?

OSGi

• Evaluation of OSGi : there are a whole bunch of good things that OSGi would bring us, but right now, there's also a lack of ready-made frameworks/tools/libraries for webapp. We'd have to change way too much things in Magnolia to get it working. See OSGi notes.

Mercury

Main principles or goal remain the same, but Mercury is now called Aether (complete rewrite afaict, so examples below are probably useless)

• We could re-use (part of)
: Confluence, Hudson, ...
• We could(should) also evaluate OSGi, although my feeling is that it is very complex and bulky, and will incur more cost than bring benefits. Somehow I hope I'm wrong.
• We might also want to evaluate how to re-use the Maven infrastructure. This might be particularly interesting since our builds already deploy to Maven repositories, we might not have to invent much as far as getting new modules goes ! ; The current effort is going into "Mercury", which as far as I understand, will be a foundation block for Maven 3:
  • http://svn.magnolia-cms.com/svn/internal/testing-mercury/
  • http://www.sonatype.com/people/2008/11/what-is-mercury/
  • http://maven.apache.org/mercury/index.html
  • http://docs.codehaus.org/display/MAVEN/Mercury
  • http://docs.codehaus.org/display/MAVEN/HowTo+use+Mercury+for+accessing+repositories
  • http://repo2.maven.org/maven2/org/apache/maven/mercury/ (1.0-alpha-5 is available at the time of writing)
  • http://svn.eu.apache.org/viewvc/maven/mercury/trunk/

...