geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: [DISCUSS] plugingroups - another idea
Date Fri, 12 Sep 2008 14:29:51 GMT
David Jencks wrote:
> Maybe I don't understand your proposal.  If I do, you are arguing that 
> the one new feature of plugin groups- that they do not define a 
> classloader for the dependencies -- should be removed (or not 
> implemented -- I'm not sure if it actually works yet) -- and we should 
> use only plugins for all purposes.

Yes, that is correct.

> I think the new alleged capability is a good idea.  I see the 
> archetypical use case for plugin groups as installing a bunch of 
> functions that you might want to use at the same time but have no 
> classloading relationships between them.  For instance, I think of a 
> "complete" jetty server as having jetty, jetty deployer, jasper 
> deployer, and the basic jetty console.  (I don't know if we have this 
> profile right now).  Jetty deployer and jetty console both pull in jetty 
> so the dependency list wouldn't need jetty in it.  Now, why exactly 
> should we supply a classloader containing these parents to everyone who 
> happens to install this profile?  

My intention was that the user could use the plugingroup in more than 
just the server assembly scenario (see my original explanation).  I'd 
really like to make things easy for the user.  It seems to be overly 
complex from a user perspective to have one set of objects from which to 
build a server and a different set of objects from which to install 
plugins or use as dependencies when building your own plugin.

I see your point regarding the jetty plugingroup as you define it.  A 
definition that includes the deployer bits along with the typical web 
dependencies is really only useful for assembling a server.  If the 
group were primary the core jetty components and things typically used 
in a web server (like jasper & jstl) then it could be used for 
assembling a new server, installation of content into the current 
server, and dependency management when a user is creating their own 
plugin.  For that last item to be useful you need the classloader.

Note that anyone who wants to bundle a
> bunch of apps together into one classloader can already do that with a 
> normal plugin.
> thanks
> david jencks
> On Sep 11, 2008, at 5:26 PM, Joe Bohn wrote:
>> I've been thinking about plugingroups and I'm wondering why we need to 
>> make them very much different than regular plugins.
>> We've been primarily focused on plugingroups as a way of simplifying 
>> the creation of a custom server assembly.  That's a good use of 
>> plugingroups.  However, perhaps it isn't the only use.   Because we've 
>> been primarily thinking of them as server assembly bits we've been 
>> looking to remove some of the regular plugin functions from them ... 
>> like the classloaders they create and their entries in config.xml.
>> So the question is; can plugingroups be used in other ways and would 
>> the classloaders, etc... be useful in those other scenarios?
>> Perhaps a user or solution provider has a need to create a core set of 
>> plugins and then "bundle" them together into higher function 
>> plugingroups (just as we want to do with the server bits).  Their 
>> customers could then create their own applications and include 
>> dependencies on these plugingroups.  These plugingroups might also be 
>> of value for a user to install on a server independently.  I think our 
>> users could also benefit from this by creating dependencies on our 
>> plugingroups rather than individual plugins.  A user could create an 
>> application that requires tomcat, web services with cxf, and jms.  It 
>> would be nice if they could reference the plugingroups as dependencies 
>> when building a plugin via maven rather than having to reference the 
>> individual plugins.
>> IIUC, our current direction is that a user would deal with one set of 
>> components (plugingroups) when building a server ... but a different 
>> set of components (plugins) when creating their own application plugin 
>> (at least I think that would be the case).  Also, I suspect we would 
>> have to include additional capabilities in Geronimo to protect against 
>> a user attempting to add a dependency on a plugingroup.  I'm concerned 
>> that making the plugingroups too specialized results in more work for 
>> us and less capability for the end user.
>> If we just let the regular processing occur for plugins that aggregate 
>> other plugins (plugingroups), then I think the user could leverage the 
>> plugin groups in many different ways and we'd have fewer issues.
>> How we actually work the internal details to construct classloaders 
>> could still be enhanced to eventually "skip" the aggregate objects and 
>> drill to the next level for plugingroups ... but I think that's really 
>> an independent issue and an optimization.
>> So, the proposal I was thinking of was simply this:
>> 1) Create plugin groups as any other plugin and let our current 
>> processing deal with them as any other plugin.  The classloader that 
>> is created might actually be useful.  The config.xml entry probably is 
>> not, but is it really causing any problems?
>> 2) Use the plugin group attribute more as a way of classification 
>> rather than function enhancement (at least for now).  We can always 
>> decide to leverage this knowledge more completely to optimize 
>> classloader construction or for other purposes such as organization.
>> 3) Leave the assembly construction GUI/commandline and plugin install 
>> GUI/commandline to work with plugins only ... no differentiation with 
>> plugingroups.
>> 4) To help clear the clutter from those GUIs/commandlines (one of the 
>> primary motivations in the recent effort) we could create different 
>> plugin catalogs.   The default catalog could primarily include the 
>> plugingroups and perhaps a few specific plugins that don't merit 
>> further aggregation.  An expert catalog would be the complete catalog 
>> with all plugins included.  These same catalogs would be used when 
>> installing plugins and constructing server assemblies so there would 
>> be some consistency for the user.
>> 5) The same set of plugins and plugingroups would be available as 
>> dependencies when a user builds their own plugin via maven.
>> I think this would broaden the usefulness of plugin groups.
>> thoughts?
>> BTW, why are the current plugingroups jars rather than cars ... and 
>> why don't they appear in the geronimo-plugins.xml?
>> Joe

View raw message