Page History
Wiki Markup |
---|
{rate}
{status:draft|Magnolia |
...
4.2+ |
...
}Proposal for better/simpler bundling. See [MAGNOLIA-2686@jira] for status. |
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
...
{status} h2. 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. h2. Implementation We should reduce the number of artifacts: standalone (for evaluation and simple use) and webapp (for deployment in own server, production) h3. 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|http://winstone.sourceforge.net/], 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
h3. Webapp * well, we have that already, but we might want to think about a solution for avoiding the ones specific to weblogic, websphere, ... |
...
h2. Additional ideas (2009-06-23) |
...
* auto-discovery of other instances (Bonjour?) |
...
* "this is a public instance, you need to start an author instance as well" |
...
* "this is an author instance, where is your public instance?" |
...
* while this might be worth a separate feature on its own, this popped up while discussing the standalone bundles - use Bonjour/ZeroConf for subscribers discovery/configuration ? |
...
** [http://en.wikipedia.org/wiki/Bonjour_(software]) |
...
** [http://en.wikipedia.org/wiki/Zero_configuration_networking |
...
] ** [http://www.zeroconf.org/ |
...
] ** [http://www.onjava.com/pub/a/onjava/excerpt/bonjour_ch08/index.html |
...
] ** [http://jmdns.sourceforge.net/] |
Overview
Content Tools