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