geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject [DISCUSS] plugingroups - another idea
Date Thu, 11 Sep 2008 21:26:17 GMT

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


BTW, why are the current plugingroups jars rather than cars ... and why 
don't they appear in the geronimo-plugins.xml?


View raw message