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
