You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2008/12/02 02:30:22 UTC

Move monitoring console out of server to plugins?

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


Re: Move monitoring console out of server to plugins?

Posted by Joe Bohn <jo...@earthlink.net>.
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
> 
> 


Re: Move monitoring console out of server to plugins?

Posted by Donald Woods <dw...@apache.org>.
+1 to not include Monitoring in the default server assemblies for 2.2.

+0 for moving to geronimo/plugins, as leaving it in the server branch 
would be fine for now (wondering if we'll need a new version of the 
plugin for every major release, due to newer levels of OpenEJB and/or 
OpenJPA.)


-Donald


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