geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: svn commit: r694978 - in /geronimo/server/trunk: assemblies/geronimo-framework/ assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-jetty6-minimal/ assemblies/geronimo-tomcat6-javaee5/ assemblies/geronimo-tomcat6-minimal/ buildsupport/car-maven-plu...
Date Mon, 15 Sep 2008 17:45:07 GMT
David Jencks wrote:
> On Sep 15, 2008, at 6:18 AM, Joe Bohn wrote:
>> Thanks for making these changes David.  I think this mostly addresses 
>> my concern that plugingroups can be used anywhere plugins are used (it 
>> certainly helps now that they are all cars :-) ).
>> So with the subject change ... is it now true what Lin mentioned 
>> earlier in the "[DISCUSS] plugingroups - another idea" thread:
>> Lin Sun wrote:
>> > For option 1, I guess I don't understand why we need the classLoader
>> > attribute.   I think for plugin groups, we should not add the plugin
>> > group itself to the classloader, but we should add the dependencies to
>> > the classloader.   For instance, if we support Joe's scenario, when a
>> > user specifies a plugin group as a dependency in his deployment plan,
>> > it would just add the dependencies that the plugin group depends on to
>> > the project's classloader.
>> Will the dependencies of the plugingroup be added to the project's 
>> classloader?  That would certainly resolve any concerns.
> I _think_ they will be in the maven build's classloader but definitely 
> not in the geronimo classloader.   While this is inconsistent I don't 
> yet see a reasonable use case for a plugingroup that doesn't have a 
> classloader but does indicate a group of plugins that need to be added 
> to some projects classloader.  I needed the new functionality for other 
> purposes so I haven't spent a lot of time thinking about this but a real 
> concrete use case would go a long way for me.

The scenario I had in mind is very simple.

1) A user has decided (for whatever reason) that they need a core server 
built on Geronimo including Jetty & Axis2.
2) The user will build multiple web applications and combine them on 
server images as the need arises and so they don't want to include the 
applications themselves in a custom server assembly.
2) To address the core server need, the user chooses to assemble their 
own server image with the two universal pre-reqs: the web-jetty and 
webservices-axis2 plugingroups.
3) The user then goes about building their web applications and 
generating geronimo plugins for these web apps to ease deployment.  They 
want to ensure these applications are installed in the correct server 
configuration so they set the prereqs for the applications to match the 
core server image that they had earlier constructed - a prereq on the 
web-jetty and webservices-axis2 plugingroups.
4) The user will then install the server in the appropriate location(s) 
and deploy combinations of the applications on the as necessary on the 
server instances.

Of course it is more correct to have the applications prereq the 
individual plugins necessary for jetty and axis2 runtimes rather than 
the plugingroups.  However, that would mean that the user must 
understand the detailed plugins for building applications but only the 
plugingroups for building server images ... and the whole point of the 
plugingroups was to simplify things for the user so they could deal with 
higher level concepts.  If that simplification makes sense for 
assembling a server (a relatively infrequent activity) why would it not 
also make sense for assembling an application (a somewhat more frequent 

And yes, I understand (as will the user) that the plugingroups may be 
pulling in more than they really need to run the applications - esp. if 
we continue to combine core function, deployers, and console extensions 
in the plugingroups.  That may be a valid reason to alter the 
granularity of the groups we are creating.  If not, another reason to 
split things up a little finer is to facilitate the construction of 
servers without deployment capabilities - but that's really a separate 


> thanks
> david jencks
>> Thanks,
>> Joe

View raw message