Maybe I don't understand your proposal. If I do, you are arguing that
the one new feature of plugin groups- that they do not define a
classloader for the dependencies -- should be removed (or not
implemented -- I'm not sure if it actually works yet) -- and we should
use only plugins for all purposes.
I think the new alleged capability is a good idea. I see the
archetypical use case for plugin groups as installing a bunch of
functions that you might want to use at the same time but have no
classloading relationships between them. For instance, I think of a
"complete" jetty server as having jetty, jetty deployer, jasper
deployer, and the basic jetty console. (I don't know if we have this
profile right now). Jetty deployer and jetty console both pull in
jetty so the dependency list wouldn't need jetty in it. Now, why
exactly should we supply a classloader containing these parents to
everyone who happens to install this profile? Note that anyone who
wants to bundle a bunch of apps together into one classloader can
already do that with a normal plugin.
thanks
david jencks
On 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
