geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <jga...@gmail.com>
Subject Re: [DISCUSS] plugingroups - another idea
Date Fri, 12 Sep 2008 05:17:42 GMT
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