geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Geronimo, Genesis and OpenEJB2... oh my
Date Tue, 11 Jul 2006 19:55:38 GMT
On Jul 11, 2006, at 4:48 AM, Prasad Kashyap wrote:
> That's cool, dude.  Now can we please have some intro to Genesis. I
> saw a fleeting mention of it in another mail thread.

Sure, its about time... now that its working.

Genesis is a simple project that contains modules that help in the  
creation of other projects.  It is nothing fancy, just a collection  
of modules to provide shared/common configuration and a place to put  
G-related plugins.

Currently there are 2 trees: config and plugins

The config tree contains modules which provide the shared/common  
configuration, and plugins provide support modules (like plugin- 
support) and custom plugins (currently there are none, but I may have  
to make a sql plugin to fix the uddi-db problems on windows, etc, and  
that would go here).

NOTE: Genesis must be bootstrapped until Maven fixes the issue with  
extension plugins built in the same build cycle.

  * * *

So what do we have so far:

< config/checkstyle-config >

This module contains the Checkstyle configuration, taken from etc/ 
geronimo_checks.xml.  It is installed as a build extension, so that  
its contents are available to be loaded as resources.  This allows  
the Checkstyle plugin to be configure with just this (no need to  
use ../../ which won't work when building with Continuum, or to  
duplicate the config in each module):

     <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-checkstyle-plugin</artifactId>
         <version>2.1</version>
         <configuration>
             <!-- Pulled as resource from checkstyle-config plugin -->
             <configLocation>org/apache/geronimo/checkstyle.xml</ 
configLocation>
         </configuration>
     </plugin>

While it is possible to use a URL for this configuration, to keep the  
build in sync with the SVN repo I do not recommend using remote  
resources whenever possible.

< config/clover-config >

This provides the clover.license so that Clover can be used.  It is  
also installed as a build extension, and picked up in the same way  
that checkstyle.xml is.

The license that is here is what Cenqua gave me for development on  
Apache Geronimo.

< config/logging-config >

This provides the common log4j.properties used by all modules when  
running tests.   This is a normal dependency, included in the test  
scope.

The key thing that this provides is that all tests will create a $ 
{basedir}/target/test.log file that has the full logging detail for  
surefire tests.

IMO tests by default should produce no output so that it is easy for  
folks to see what is passing and what is failing on the build  
console.  For failure details, the log file + surefire reports can be  
used.

We can also add a few properties to control the default level that  
goes to console for easy development, but I have yet to implement that.

There is no need to add per-module log4j.properties configuration  
files anymore.

< config/project-config >

This module contains the common m2 build configuration that most  
every G-related project needs to produce builds, generate sites, run  
tests, etc.

This is the _parent_ of each projects _root_ pom.

Have a look yourself, but it basically sets up the default mailing  
lists, issue tracking, etc.

Here you will find where the other config modules are included into  
the build.

Also, this is where plugin versions are controlled, so that we don't  
run into problems in the future when plugin vendors release new  
versions that are incompatible with the build configuration that is  
checked in to SVN.  This is key to support building projects that are  
pulled from older branches.

< plugins/plugin-support >

This is a jar module, that contains common code that our plugins  
use.  Right now that is simply MojoSupport, which handles setting up  
logging and provides exception handling at the root so that  
extensions do not need to worry about that.

As we add more plugins expect more commonly used code to move here.

  * * *

The idea is to keep all of the common bits in one place, so that we  
can easily reuse that configuration across projects.

I've setup the svkmerge/m2migration branch to use this project's  
modules to simplify the required build configuration.

Right now, since its just coming together we are using genesis 1.0.0- 
SNAPSHOT versions, but once the configuration is solid, then we will  
make a release of Genesis and then update projects to just use the  
1.0.0 version.  After that, we only need to change the versions when  
the common configuration is changed.

The changes should be infrequent, but will happen from time to time.   
In general the time required to maintain projects in this fashion is  
much less than the alternative of not sharing.  This means that it  
will be much easier to keep all projects in sync with the latest  
build configuration.

  * * *

I hope that helps explain what Genesis is... and more so what the  
direction that I'm setting is for maintainable project builds.

We will eventually need to promote Genesis out of the sandbox, and  
make a release of it to support the main G build (as well as  
others).  I'm expecting to send a RTC on this later this week or next .

Anyways, so let me know what your comments are.

Cheers,

--jason

Mime
View raw message