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: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=lkFjxM3GN8kU05Ju3/3NM+miDkyfGkMMOKAK4x58QDkq1QnhELt997EU6mBh4ss8;
  h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <493545A4.8080402@earthlink.net>
Date: Tue, 02 Dec 2008 09:26:44 -0500
From: Joe Bohn <joe.bohn@earthlink.net>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Move monitoring console out of server to plugins?
References: <3D198CC6-2A6E-4C86-9197-52EC8E66A7BE@yahoo.com>
In-Reply-To: <3D198CC6-2A6E-4C86-9197-52EC8E66A7BE@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Our track record on releasing independent plugins isn't very good.  It 
seems to add a lot of overhead and process for little value.

How about the following:
- Keep the monitoring console in the server svn branch
- Release the monitoring console plugin when the server is released 
(versioned to match the server).
- Remove the monitoring console from the javaee5 assemblies.

I know this doesn't provide the same degree of independence but it would 
ensure that the plugin is released regularly and we can always fork it 
to plugins/trunk if necessary to fix some critical issue if the need arises.

Joe


David Jencks wrote:
> We've discussed at various times trying to make the server build more 
> manageable by moving peripheral plugins out of the server/trunk/pluings 
> into plugins/trunk
> 
> I'd like to start this by moving monitoring before 2.2.
> 
> Any objections?
> 
> We have a few options as far as including the console in actual server 
> assemblies:
> 
> 1. don't include it.
> 2. get the monitoring plugins to depend on say g 2.1.4 and include 
> compatibility stuff so it also works on 2.2 when released
> 3. follow the following release process for 2.2:
> 
> a. release framework.  IMO this should include the maven plugins and 
> framework assembly, but people argued when I suggested this svn 
> organization before.
> b. release plugins, at an appropriate rate, including monitoring
> c. release the assemblies.
> 
> I'm happy with any of these approaches or probably any others someone 
> comes up with but slightly prefer (1) or (3).
> 
> thanks
> david jencks
> 
>