geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
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 18:04:27 GMT

On Sep 15, 2008, at 10:45 AM, Joe Bohn wrote:

> 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 activity)?
> 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 discussion.

To me it seems more like you are suggesting plugin groups as a  
workaround to another problem in the current plugin system, and I  
don't think your suggestion will really help.

If you are using maven to build plugins, currently you have to specify  
explicitly in the car-maven-plugin which deployment plugins you want  
to use, and include them as (provided) dependencies in the pom. This  
means you need to know what you want quite explicitly, and I don't see  
how plugin groups can help with this yet.... certainly an area for  

Now, the deployers all add the required dependencies to the plan, such  
as in your example axis2 and jetty, so the app certainly won't start  
without those present.  However at the moment we have no way for the c- 
m-p to find out about those added dependencies and add them to the  
geronimo-plugin.xml so you have to list them yourself.

It seems to me that if we can somehow use plugin groups in the c-m-p  
configuration to specify more concisely what deployers we want, and  
get the dependencies added by the deployers into the geronimo- 
plugin.xml, then we will have the convenience you want without the  
extra classloader or funny "this isn't really a plugin, include my  
dependencies" behavior that I'm nervous about.

david jencks

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

View raw message