geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: [DISCUSS] plugingroups - another idea
Date Fri, 12 Sep 2008 14:30:16 GMT
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.

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


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