geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
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 Tue, 16 Sep 2008 01:10:53 GMT
Can't we include the matching deployers in the plugin groups we have 
now?  If someone doesn't want a deployer, then they can build their own 
plugin groups that exclude them...


David Jencks wrote:
> 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
>>>> > 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 discussion.
> 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.
> thanks
> david jencks
>> Thanks,
>> Joe
>>> thanks
>>> david jencks
>>>> Thanks,
>>>> Joe

View raw message