Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <424C4968.5030408@apache.org>
References: <424C4968.5030408@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <a88f18edfa3f384f15375eedc968dac6@gluecode.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dsundstrom@gluecode.com>
Subject: Re: Splitting up geronimo-system
Date: Thu, 31 Mar 2005 12:15:28 -0800
To: dev@geronimo.apache.org

I'm a bit confused about what specifically you are proposing to move.  
For example, would it be the full logging stuff or just the logging 
initializer code?

Also, are we going to loose reuse if we start moving this code to 
configuration packaging modules?  I would assume that if we move the 
command line stuff to one the packaged configuration, and another 
needed the same command line code it would need to make a copy of the 
source code.

One last thing, do we really want to be moving code and changing the 
build right now?  I like the idea, but I'm not sure about the timing.

The static initializers really do suck :)

-dain

--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26

On Mar 31, 2005, at 11:03 AM, Jeremy Boynes wrote:

> The original intention here was that this module would contain just 
> the basics needed to get a kernel running in a VM. However, the amount 
> of stuff that is needed to do that has grown and things have started 
> to get specialized (for example, the stuff for handling endorsed dirs, 
> logging, command line parsing, the tools jar hack, and more).
>
> With the ability to package configurations from their own Maven module 
> it makes sense to move some of this code into those modules. For 
> example, the command line parsing stuff can move into the module for 
> the command line tool that is actually using it; same with logging 
> setup so that it can be configured appropriately for client, server or 
> plugin operation.
>
> By moving the main entry point into the executable module itself it 
> also gives it a chance to do what it needs to be done before 
> bootstrapping the kernel. This would allow us to eliminate some of the 
> static initialization blocks of the "make sure this runs first" type 
> which are a little fragile.
>
> --
> Jeremy