geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: [DISCUSS] plugingroups - another idea
Date Fri, 12 Sep 2008 14:36:36 GMT
David Jencks wrote:
> Maybe I'm starting to understand what you are saying...
> 
> On Sep 12, 2008, at 1:17 AM, 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 is
>> 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.
>>
> I wasn't clearly aware that our plugin install stuff didn't recognize 
> the plugin groups as plugins.  Now that I do I think its a bug :-)  I'm 
> not sure if the plugin group packaging file extension should be car or 
> jar or something else, so far I lean towards car.

Right, I was proposing car as well.

> 
>> 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).
> (random musings)
> We could also use "category" instead if we only need one tag.   Multiple 
> tags might offer the ability to assemble servers out of queries against 
> the tag space.  I think that just using tags on individual plugins would 
> make the results of a query indeterminate -- you can just add more 
> plugins with a certain tag -- so at the moment I'm still in favor of 
> having an explicit plugingroup project with a known determinate list of 
> contents.  This is an interesting idea that we should explore further.

I was proposing that we use the plugingroup as an additional qualifier 
to restrict the list of plugins for a non-expert user (see original 
post) ... and that is all. I think one of the original goals was to help 
narrow the list of things a user must deal with if they are not an 
expert user.

The idea of making it a multi-value tag that can be used to collect 
plugins for a group is interesting, but I too favor keeping it 
explicitly defined for consistency.


> 
> thanks
> david jencks
> 
>>
>>
>> Jarek
>>
>> On Thu, Sep 11, 2008 at 5:26 PM, Joe Bohn <joe.bohn@earthlink.net> 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
>>>
> 
> 


Mime
View raw message