geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Splitting up the server into a few more chunks
Date Mon, 06 Aug 2007 20:15:51 GMT

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  

I think you should be able to install (1), (1 and 3) (1 and 2) or (1  
2 and 3).

david jencks

> Best wishes,
> Paul

View raw message