Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of linsun.unc@gmail.com
 designates 209.85.217.21 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=Z8XysLGqncOiTlfxw5UtCWCk/7KTakpv4gNbhhFP4aFSCSsuH62BfRxpXOsfloIT9j
         DXr9jxv5A25JteJklitceBYJstUqcvBJfEApGdac7yEGtMLb2+H2LG9s6KsRgkqQ4hJx
         BRbGqDofWHW1wBq+Hgw2NWRu/raIFh5J67s68=
Message-ID: <add18bc80810081346q3bd5a302radc7e19ddfd6a1d1@mail.gmail.com>
Date: Wed, 8 Oct 2008 16:46:21 -0400
From: "Lin Sun" <linsun.unc@gmail.com>
To: dev@geronimo.apache.org
Subject: Re: svn commit: r702586 - in
 /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/
 src/main/history/ src/main/history/dependencies.xml src/main/plan/
In-Reply-To: <48ED13BE.8060602@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20081007191000.9F73A23888AF@eris.apache.org>
	 <48EC22F4.6030509@apache.org>
	 <add18bc80810080645y3398bdd3t27b56e575f7c8964@mail.gmail.com>
	 <A8623F19-2CCD-44A5-9151-C8C1246A60D3@yahoo.com>
	 <add18bc80810081117r72f6cdd4neec348c01fc3da85@mail.gmail.com>
	 <48ED13BE.8060602@earthlink.net>

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 <joe.bohn@earthlink.net> 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