geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: [DISCUSS] plugingroups - another idea
Date Fri, 12 Sep 2008 15:53:24 GMT
OK, two options come to mind.

1) Use 2 plugin attributes:
- pluginGroup to denote this plugin is only for server assembly views
- classLoader to allow us to disable classloader creation for any plugin

2) Go back to what we had and keep the pluginpgroups grouped together:
- always create a classLoader (still not sure why we wanted to aviod 
this for some cases)
- drop the pluginGroup attribute
- change the server assembly UI code to treat only plugins with 
groupId=org.apache.geronimo.profiles (or something similar) as plugins 
to display for the function/profile assembly path


Joe Bohn wrote:
> Donald Woods wrote:
>> Becoming clearer now...
>> For #1, maybe we should replace <pluginGroup> with a 
>> <createClassloader> attribute, which would be true by default.  If set 
>> to false, then we wouldn't add to config.xml or create a classloader.
> I think there are 3 different goals being tossed around here:
> A. Differentiating plugins that are intended to be large enough building 
> blocks for most users vs. those that are more granular and intended 
> really only for expert users.
> B. Using plugingroups wherever plugins are used today so the user is 
> dealing with consistent concepts (this may just be my personal goal).
> C. Elimination of classloaders if they are not needed for architectural 
> purity.
> I was proposing using the pluginGroup attribute as just a categorization 
> to achieve A.  I was proposing making everything a regular plugin (with 
> a classloader) to achieve B.  And ... I was hoping to eliminate C to 
> facilitate B.
>> After making the above change, the creation of special plugin groups 
>> which are jar files would go away and everything would be a CAR again, 
>> which would allow any plugin (whether it creates a classloader or not) 
>> to be installed through all of the existing methods (plugin installer, 
>> server assembler or at application deployment.)
> I think if we must have the no-classloader option then we will have to 
> add some special logic in place to address dependencies that a user 
> might place on these special plugins that do not contain classloaders. I 
> assume that logic would be to flag an error and prevent users from 
> deploying a plugin that has a dependency on a plugingroup with 
> noclassloader.  I think we also need to make this clear in the doc.  I 
> don't think that the no-classloader option replaces the plugingroup 
> option because I think we still need that categorization for A.
> My head is spinning a bit, but I think this may be a good compromise.  I 
> think it make the plugingroups more general purpose, gives the user just 
> one primary set of objects to deal with for all 3 cases where plugins 
> are primarily used today, and addresses the architectural purity 
> concerns in the case where a particular plugingroup has no possible 
> value as a dependency of another plugin.
> Joe
>> -Donald
>> Jarek Gawor wrote:
>>> Joe,
>>> I think I understand what you are saying. First, there are two key
>>> issues about plugin groups as of right now:
>>> 1) The geronimo-plugin.xml for plugin groups have
>>> <pluginGroup>true</pluginGroup> element set to indicate the plugin
>>> a plugin group.
>>> 2) The plugin groups are packaged as jars.
>>> About #2:
>>> Since the plugin groups are packaged as jars (and if I understand
>>> things correctly), the plugin group does not show up in the
>>> config.xml, there is no classloader associated with the plugin group,
>>> and plugin group will not show up in the
>>> ~/.m2/repository/geronimo-plugin.xml file. Since the global
>>> geronimo-plugin.xml is not updated, it basically means you won't be
>>> able to see any plugin groups under console->install plugins no matter
>>> which remote or local repo you point to. The plugin groups will only
>>> show up under the console->assemble server (which will only show you
>>> already installed plugin groups).
>>> So yes, plugin groups right now are very "assemble a server" specific.
>>> If we turn the plugin groups into cars we would get a lot more
>>> flexibility: classloaders, remote install of plugin groups, etc.
>>> About #1:
>>> I think the "pluginGroup" element in geronimo-plugin.xml is really
>>> only used for classification purposes. That is, so that the plugin
>>> appears under the right menu in the console or the CLI tool. And if
>>> so, we could probably make this a bit more generic and introduce some
>>> sort of tagging to geronimo-plugin.xml. For example, we could allow a
>>> zero or more arbitrary tags to be associated with the given plugin.
>>> The console or the CLI tools would then present a list of tag names to
>>> the user. The user could choose one or more tags which would resolve
>>> to multiple plugins.
>>> This could also be an alternative solution to plugin groups where
>>> multiple plugins tagged with the same tag would constitute a plugin
>>> group (so there would be no need for a separate maven module for each
>>> plugin group).
>>> Jarek
>>> On Thu, 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