Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 102 rates

Draft for ?

Proposal for better/simpler bundling. See MAGNOLIA-2686 - Getting issue details... STATUS for status.

Rationale

The current bundling of Magnolia has several drawbacks:

  • it is big (Magnolia itself isn't exactly lightweight, and bundling 2 webapps with Tomcat make it a whooping 65mb!)
  • it doesn't provide an easy entry-point for non-tech users:
    • on Windows, if using the installer, there are shortcut icons to start/stop, etc; this is however only available on windows and with the EE. (although we could of course also provide the installer with the CE)
    • on all other platforms or with the CE, users have to know how to open a shell, what it is, etc; and probably generally have to fiddle around with JAVA_HOME and so on (again, the installer provides a way around this)
  • the installer doesn't provide much added value, other than setting the JAVA_HOME variable in the startup scripts (which is not uninteresting)
  • even once installed and started, the entry barrier is still quite high - "firewall" issues on OSX, and concepts are not clear: both instances of Magnolia are probably perceived as a single application (started with a single shortcut/command). Consequently, it might not be clear why two instances are actually a feature of Magnolia, nor that they could (should) be deployed on separate servers/machines for production use.

Implementation

We should reduce the number of artifacts: standalone (for evaluation and simple use) and webapp (for deployment in own server, production)

Standalone

  • one single file to download; double-clickable. (java -jar magnolia-standalone.(j|w)ar)
  • minimal gui on startup (or shell console or options if no screen is available, obviously), asking for (for example):
    • magnolia_home ? (defaults to current folder)
    • http port (defaults to 8080)
    • instance name/contextPath ? (defaults to magnoliaAuthor?)
    • is author/public
    • subscriber address (defaults to demopublic.magnolia-cms.com?)
  • starts an embedded appserver (Winstone, Jetty, ...) with ONE instance of Magnolia.

We could get inspiration from Hudson for embedding. Custom classloading / packaging might be necessary.

This probably depends on the ability to deploy read-only war files: MAGNOLIA-2170@jira. (i.e the having all config and extract files outside the webapp)

Although not inter-dependent, Concept Module downloader updater would also help reducing the size of the bundle !

The concept of the 2 instances (authoring vs publication) would possibly become more visible and understood by new users, compared to the single tomcat running the 2 webapps.

Webapp

  • well, we have that already, but we might want to think about a solution for avoiding the ones specific to weblogic, websphere, ...

Additional ideas (2009-06-23)