Page History
| Devstatus | ||||||
|---|---|---|---|---|---|---|
| ||||||
Proposal for | ||||||
| Wiki Markup | ||||||
| {rate}
{status:draft|5.2}Proposal for better/simpler bundling. See [MAGNOLIA-2686@jira] for status.{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 toSee
|
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
...
- (
...
...
- ,
...
- 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:
...
...
.
...
(i.e
...
the
...
having
...
all
...
config
...
and
...
extract
...
files
...
outside
...
the
...
webapp)
...
Although
...
not
...
inter-dependent,
...
...
...
...
...
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)
...
- 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
...
- ?
...
...
- )
...
...
...
...
...
Overview
Content Tools