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 15:34:02 GMT

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.

david jencks

> Thanks,
> Joe

View raw message