geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Unable to build using m2
Date Tue, 27 Jun 2006 03:20:50 GMT
> I'm really, REALLY,  glad you have taken an interest in m2 migration
> :-) Your experience with other such migrations can surely help us.
> Alright so now you can guide us.

:-)  I need a buildable server too ;-)

> So we shall hardcode the parent <version> in all pom.xml and remove
> the <version>. element for that project itself. That should help us do
> a single build w/o the -N.

Yup, each module should define the project/parent/version and only  
the root pom.xml should define project/version.  Leave mgmnt of this  
number to the release process, don't try to fix it with properties  
now, since it just doesn't work like that  in m2 yet.

> What else would u advise ?

Well, I'm still assessing what the state of the m2 conversion is.   
Offhand I can think of a few things that we should do:

Create some helper modules to carry build configuration.   
Specifically, we should create a new module that contains a simple  
Log4j configuration that can be shared by all modules.  IMO, the  
default build should not spit out tons of output when running tests.   
It should capture all output into target/test.log and if needed allow  
the developer to enable system.out with a property setting.  This is  
easily done be creating a new module that contains the shared and then hook it up as a default extension to the  

But, to do this, the module needs to be built separately and  
downloaded.  Not a big deal really, but something needs to be done to  
setup/facilitate its build.  I recommend that we setup a peer tree  
that holds build support modules.  Starting out with the logging- 
config module... but there are also other reasons to have these  
support modules, especially as we add more and more projects that  
need to share the same basic configuration.

I also think that we should remove any unneeded properties in the  
root pom.  I mentioned the reasoning before... basically less is  
more.  This file is going to get more and more complicated, no reason  
to inflate that with unneeded properties.

Drop and configured modules that are not checked in to the tree (ie.  
modules/openejb).  If this is really needed then it should be checked  

  * * *

Other thoughts are more about future reorganization of the tree.  I  
think we may want to split up the tree as it exists now into a few  
smaller chunks that represent more functional areas.  For example,  
I'd like to have all of the core modules grouped up, so that I could  
just build everything needed to just get the very basics up.  Then  
another group for all of the J2EE support, and then another for  
thirdparty vendor support, etc.

We should be willing to reorganize the tree after we get the basic  
build going, to facilitate separation of concerns from a component  
level... meaning that if I am only interested in building the bare  
server, then I should not need to bother with all of the other j2EE  
and 3rdparty stuff.

But all of this will come in time.  I think that once the m2 build it  
functional that we should reorganize right away into functional  
groups of modules.

If I notice anything that I think is a bit "crazy" I will be sure to  
post it to the list.


View raw message