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
Lin Sun wrote:
There is no doubt that framework is useful, but I think most of the
other plugin groups are useful too (for example web-jetty, web-tomcat,
or the javaee5-jetty, javaee5-tomcat). It is almost impossible to
come up those quickly for a new geronimo user.
With plugin groups, I can see users pick any of the plugin group(s)
and plus their applications from their existing server to build a new
working server easily.
Some of the plugin groups may sound very simple and small and there
doesn't seem to be a need for them, for example the jms or jsf plugin
group. But for a new user (keep in mind that you guys are geronimo
experts!!), it is not that obvious to them which modules can get them
to the jms function. First, they need to understand activemq is the
JMS impl in geronimo; Second they need to find out all the modules
that are jms/activemq related and figure out which ones they need.
By grouping them together, users can get the function with one click
or command (specify the plugin group as the plugin to be installed via
admin console or command line). Thus I think they add some
convenience to the user. I think I am open to remove these type of
plugin groups if you guys strongly prefer that.
Lin
On Wed, Oct 8, 2008 at 12:42 PM, David Jencks <[EMAIL PROTECTED]> wrote:
I'm also getting worried that the plugin groups are starting to duplicate
the plugins and wondering if the concept is providing significant value
beyond the framework plugin group.
