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
