geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin Sun" <>
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-mav
Date Fri, 19 Sep 2008 17:11:11 GMT
Sorry for the resending... I thought my other message didn't get
sent...  this is something I don't quite like my gmail which didn't
update the message sent by me promptly.


On Fri, Sep 19, 2008 at 1:07 PM, Lin Sun <> wrote:
> I think if we want to make users easier to build a project, the best
> is that we can construct the dependency list automatically for the
> user, perhaps at deployment time.   This would even save the user from
> listing plugin groups as dependencies in various geronimo deployment
> plans.  Maybe it is worthy while to investigate if it is possible to
> do this?
> Lin
> On Wed, Sep 17, 2008 at 6:35 PM, Joe Bohn <> wrote:
>> 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
>>>>>>>> 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
>>>>>>>> > classLoader
>>>>>>>> > attribute.   I think for plugin groups, we should not
add the
>>>>>>>> > plugin
>>>>>>>> > group itself to the classloader, but we should add the
>>>>>>>> > to
>>>>>>>> > the classloader.   For instance, if we support Joe's
scenario, when
>>>>>>>> > a
>>>>>>>> > user specifies a plugin group as a dependency in his
>>>>>>>> > 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
>>>>>>>> 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
>>>>>> server images as the need arises and so they don't want to include
>>>>>> applications themselves in a custom server assembly.
>>>>>> 2) To address the core server need, the user chooses to assemble
>>>>>> 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.
>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>> detailed plugins for building applications but only the plugingroups
>>>>>> building server images ... and the whole point of the plugingroups
was to
>>>>>> simplify things for the user so they could deal with higher level
>>>>>>  If that simplification makes sense for assembling a server (a relatively
>>>>>> infrequent activity) why would it not also make sense for assembling
>>>>>> application (a somewhat more frequent activity)?
>>>>>> And yes, I understand (as will the user) that the plugingroups may
>>>>>> 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
>>>>> 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
>>>>> those present.  However at the moment we have no way for the c-m-p to
>>>>> 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
>>>>> dependencies added by the deployers into the geronimo-plugin.xml, then
>>>>> 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

View raw message