Lin Sun wrote:
Hi Joe,
I am having trouble to understand the difference between what you
propose & what has already been done.
Basically, IIUC, you propose to use a plugin for plugin group, with
the attribute of pluginGroup=true to indicate that is a plugin group.
This is exactly what has been done today, as we don't differenriate
plugin group any other way other than the attribute of pluginGroup.
If I misunderstand you, could you please give a concrete example?
Sorry ... it had been a while since I last looked at this. I was
erroneously thinking that there were still fundamental differences
between plugins and plugingroups (such as when plugingroups were jars
rather than cars and as a result weren't included in the plugin catalog)
... but these differences have been eliminated. The only significant
difference now is the lack of a classloader (which is really controlled
by the lack of the plan rather than the presence of the plugingroup
attribute) and potential dependency issue when a classloader isn't present.
P.S. I think you were shot down by David because of the complexity of
having plugin groups listed as dependencies on the geronimo specific
plans.
Lin
On Wed, Oct 8, 2008 at 4:10 PM, Joe Bohn <[EMAIL PROTECTED]> wrote:
I agree that groups of plugins are useful and perhaps necessary from a user
perspective to help eliminate the clutter. However, there are several ways
to provide for those groups.
The way that has thus far been pursued has been creating a new module type
(is that what you would call it?) of plugingroup.
I had proposed earlier that we just use plugins for this purpose. We can
create plugins that do nothing more than aggregate other more granular
plugins. We could still keep the attribute of plugin-group around as a
qualifier to filter out these special "aggregate plugins" from among all of
the other plugins when necessary (such as when assembling a server or to
present the user with a non-expert view of plugin management). When I
proposed this earlier I was shot down because of the classloader creation.
However, since David included a change to omit the classloader if there is
no plan ... then perhaps there is no real inhibitor to this approach now
since a plan is not needed for an aggregate plugin.
I originally favored this approach because I felt it was the most intuitive
approach, ensured that the groupings of plugins could participate in any
scenario that a plugin can participate in today, and had the least
code/maintenance impacts. I think those benefits still hold with the
possible exception of the classloader change and what that may mean when an
aggregate plugin is used as a dependency which might require a little more
effort to resolve.
Joe
