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...

[Joe Bohn <jo...@earthlink.net>]

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.

Thanks,
Joe

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...

[Donald Woods <dw...@apache.org>]

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...


-Donald


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 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 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
>>
> 
> 

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...

[Joe Bohn <jo...@earthlink.net>]

David Jencks wrote:
> 
> On Sep 15, 2008, at 11:41 AM, Joe Bohn wrote:
> 
>> 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 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 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.
>>
>> Yes, you are correct that the deployers are an issue when configuring 
>> the c-m-p.  That is a important issue, but not the one I was trying to 
>> discuss here.
> 
> I think they are related.... see below :-)

No doubt they are related.  I was only trying to tackle one thing at a 
time.  If plugingroups were interchangeable with plugins we could 
leverage deployer plugingroups in c-m-p configuration as well.

>>
>>
>> If you look at the jaxws-calculator sample it demonstrates something 
>> similar to my contrived scenario.   The jaxws-calculator-jetty plugin 
>> has dependencies on 3 other plugins - jetty6, jasper, and cxf (to 
>> match my scenario above let's just pretend this is axis2 rather than 
>> cxf).  If the user is already familiar with a set of plugin groups 
>> they would probably find it more intuitive to declare dependencies on 
>> the groups rather than individual plugins.  In this example they could 
>> declare dependencies on web-jetty and webservices-axis2 to match what 
>> they had specified when assembling the server.
>>
> 
> What I'd like to see is that the user configures the c-m-p so it works 
> and deploys against the jetty web container, jasper jsp stuff, and axis2 
> web services.  I'd like everything else to flow from that without any 
> more user input.  What's missing right now is
> - easier way to set the required deployers (although it isn't too hard now)
> - getting the default environment dependencies from the builders into 
> the geronimo-plugin.xml
> 
> If you are deploying something into a running server I want the 
> generated geronimo-plugin.xml to include all these default env 
> dependencies as well: the result should be that the user only has to 
> specify what server bits they want once, either in the c-m-p "which 
> deployers to use" configuration or what is running in the server they 
> deploy against.
> 
> To reiterate over and over again once more :-/ I think getting the 
> default env deps into the geronimo-plugin.xml removes any usefulness for 
> the plugin groups as explicit dependencies for user applications.  I 
> think we might look for a way to simplify or automate choosing the 
> deployers to use. I don't know if something like plugin groups might be 
> useful here, or not.  We might look into byte code dependency analysis 
> like dependency:analyze uses to detect use of servlet, ejb, connector, 
> jms, .... classes and pick them from some kind of list, but I'm not sure 
> this relates well to the plugin groups you are thinking of.  I'm 
> thinking of a list that says "jetty-deployer, cxf-deployer, 
> openejb-deployer, jasper-deployer..."

Ok, I see what you are saying.  Rather than call out the dependencies 
directly and in addition to that call out the deployers in the c-m-p 
configuration - the user could skip the dependencies and rely on the 
deployer's default environment to fill them in.

Perhaps that will work most of the time for plugingroups that we create 
that also have some related deployer (and maybe all of our plugingroups 
will have deployer equivalents).   But will all dependencies included in 
a plugingroup also be pulled in by some deployer's default environment?

However, what happens with user or 3rd party created plugingroups?  Will 
they always have comparable deployers and hence default environments so 
they don't need to be specified as a dependency?

Perhaps the user wants the base server to include some core Geronimo 
bits (Jetty, Axis2, etc...) and some of their own functions ... perhaps 
a plugingroup of utilities provided by some 3rd party.  For example, 
let's say there is a plugingroup that includes several common debug 
utilities like configurable logging, first-failure data capture, policy 
validation, etc... let's call it "debug utilities".  Next the user 
assembles a server using a combination of the geronimo plugingroups and 
"debug utilities" for a base server image.  They plan on using this 
image multiple times to manage multiple configurations rather than 
creating unique assemblies.  If they want to build plugins for their 
applications that will be deployed to this image, they can configure the 
c-m-p deployers and thereby pull in the default environment dependencies 
for the geronimo plugingroups.  But they still have to include the 
individual plugins from "debug utilities" as dependencies if we don't 
support using the plugingroup in as dependencies.

Again, my goal is only to get some consistency for the end user.  I 
still think it's a good idea that our users will appreciate.

Some more rambling thoughts ....
While I understand and appreciate the idea of configuring the deployers 
for c-m-p and having them pull in the necessary default environments, it 
seems a bit backward from a user perspective.  If we want users to 
embrace plugins and using maven to construct them, I think it would make 
more sense to a user if we approach the problem from the other angle.  A 
user creating a plugin probably already has some idea of the 
dependencies they will need (either plugins or plugingroups if 
appropriate).   If we let them specify the dependencies we should be 
able to determine which of those dependencies requires a particular 
deployer (at least dependencies of ours).  We could make it more general 
  purpose by always naming the deployers consistently based upon the 
module that they support (ex. -deployer in the artifactId).   I'm not 
sure how we would accomplish that (perhaps another maven plugin that 
front-ends c-m-p) or how we would know if a deployer exists for a given 
plugin.  But it seems a bit more intuitive to me than telling the user 
figure out the c-m-p deployers based upon their dependencies and then 
omit the dependencies so that the deployers can pull them in via the 
default environment.

I hope I'm not driving you crazy ... it just seems obvious to me that 
users will want to leverage plugingroups the same way that they leverage 
plugins.

Joe


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

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...

[David Jencks <da...@yahoo.com>]

On Sep 15, 2008, at 11:41 AM, Joe Bohn wrote:

> 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 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 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.
>
> Yes, you are correct that the deployers are an issue when  
> configuring the c-m-p.  That is a important issue, but not the one I  
> was trying to discuss here.

I think they are related.... see below :-)
>
>
> If you look at the jaxws-calculator sample it demonstrates something  
> similar to my contrived scenario.   The jaxws-calculator-jetty  
> plugin has dependencies on 3 other plugins - jetty6, jasper, and cxf  
> (to match my scenario above let's just pretend this is axis2 rather  
> than cxf).  If the user is already familiar with a set of plugin  
> groups they would probably find it more intuitive to declare  
> dependencies on the groups rather than individual plugins.  In this  
> example they could declare dependencies on web-jetty and webservices- 
> axis2 to match what they had specified when assembling the server.
>

What I'd like to see is that the user configures the c-m-p so it works  
and deploys against the jetty web container, jasper jsp stuff, and  
axis2 web services.  I'd like everything else to flow from that  
without any more user input.  What's missing right now is
- easier way to set the required deployers (although it isn't too hard  
now)
- getting the default environment dependencies from the builders into  
the geronimo-plugin.xml

If you are deploying something into a running server I want the  
generated geronimo-plugin.xml to include all these default env  
dependencies as well: the result should be that the user only has to  
specify what server bits they want once, either in the c-m-p "which  
deployers to use" configuration or what is running in the server they  
deploy against.

To reiterate over and over again once more :-/ I think getting the  
default env deps into the geronimo-plugin.xml removes any usefulness  
for the plugin groups as explicit dependencies for user applications.   
I think we might look for a way to simplify or automate choosing the  
deployers to use. I don't know if something like plugin groups might  
be useful here, or not.  We might look into byte code dependency  
analysis like dependency:analyze uses to detect use of servlet, ejb,  
connector, jms, .... classes and pick them from some kind of list, but  
I'm not sure this relates well to the plugin groups you are thinking  
of.  I'm thinking of a list that says "jetty-deployer, cxf-deployer,  
openejb-deployer, jasper-deployer..."

thanks
david jencks




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

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...

[Joe Bohn <jo...@earthlink.net>]

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 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 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.

Yes, you are correct that the deployers are an issue when configuring 
the c-m-p.  That is a important issue, but not the one I was trying to 
discuss here.

If you look at the jaxws-calculator sample it demonstrates something 
similar to my contrived scenario.   The jaxws-calculator-jetty plugin 
has dependencies on 3 other plugins - jetty6, jasper, and cxf (to match 
my scenario above let's just pretend this is axis2 rather than cxf).  If 
the user is already familiar with a set of plugin groups they would 
probably find it more intuitive to declare dependencies on the groups 
rather than individual plugins.  In this example they could declare 
dependencies on web-jetty and webservices-axis2 to match what they had 
specified when assembling the server.


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

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...

[David Jencks <da...@yahoo.com>]

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  
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
>

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...

[Joe Bohn <jo...@earthlink.net>]

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.
Should have said dependencies rather than prereq here.  Not only is this 
to validate the server configuration but it is also to establish the 
classloader for application.
> 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.
> 
> Thanks,
> Joe
> 
> 
>>
>> thanks
>> david jencks
>>
>>>
>>>
>>> Thanks,
>>> Joe
>>
>>
> 
> 

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...

[Joe Bohn <jo...@earthlink.net>]

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.

Thanks,
Joe


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

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...

[David Jencks <da...@yahoo.com>]

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.

thanks
david jencks

>
>
> Thanks,
> Joe