On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote:
On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:
we should consider the more drastic changes, like moving the base
Admin Console support (via Pluto 1.2) out to /plugins
I really like that idea for a couple of reasons -
- it allows us to keep the admin console that's currently at
server/trunk/applications/console in place until the new extensible
admin console is ready and can scale up from minimal to full JEE5
functionality plus debug views, etc.
- I like the idea of streamlining server/trunk for JEE5 stuff and
moving the optional stuff elsewhere
My only reservation (and its no biggie) is that using the location /
plugins for optional stuff is misleading since there will be stuff
in server/trunk that's required for JEE5 (i.e. not optional) but
implemented as plugins like tomcat, jetty, amq, openejb, etc.
Calling something a plugin is a statement about its packaging and
deployment mechanism, and not whether it is required or optional.
So maybe "/opt" or some such would be a better place to put the
extensible admin console, tuscany (eventually), directory server,
samples, roller, etc...
and start moving the Portlets into the actual modules/configs that
they administer....
I like this idea from a conceptual point of view since it keeps
things neat and well organized. But I am not sure how to implement
it since the main geronimo components are typically packaged in
JARs, and the admin portlets for a component have to be packaged in
a WAR (that's just the way that pluto works). i.e. a JAR can't
contain a WAR.
Some options I can think of:
- use EAR as the packaging format for all geronimo components and
package the admin WARs inside them
- maintain geronimo components and their admin WARs separately.
bind them at deployment time via the plugin installer's dependency
resolution or by some enhancement to the maven car plugin
- package the geronimo components as WARs so the admin portlets
can be merged with them. (seems like the tail wagging the dog)
- follow some organizational structure like in your previous email
where each geronimo component has a module, config, and (now) WAR
subdirectory
Just brainstorming here...
I think we want to use "plugin groups" which IIRC is already
implemented in some way. So I see a typical feature (say jetty
support) as having 3 plugins:
- runtime jetty (geronimo-jetty6 module + jetty car)
- deploy time jetty (geronimo-jetty6-builder + jetty-deployer car)
- admin jetty (war with jetty admin portlets)
To keep it simple I'm purposefully forgetting about wadi clustering
support.
I think you should be able to install (1), (1 and 3) (1 and 2) or (1
2 and 3).
thanks
david jencks
Best wishes,
Paul