Folks, I've been pounding away at Genesis 2.0, in between
hospitalization
and system failures, and I think it is about ready. I'm sending
this email
to inform folks about the state of the sub-project as to enlist any
suggestions on changes before I go about documenting it fully.
* * *
The 2.0 bits consist of the following modules:
genesis-flava
genesis-default-flava
genesis-java1.4-flava
genesis-java5-flava
genssis-maven-plugin
genesis-packaging
genesis-skin
genesis-geronimo-skin
The 'flava' modules provide the basic configuration for sub-
projects, what
used to be 'project-config' in Genesis 1.x. There are 2 modules,
one for
Java 1.4 projects and another for Java 5 projects. Both inherit
from the
'genesis-default-flava' which in-turn inherits from the top-level
pom. The
top-level pom defines the versions of plugins, and sets up the basic
profiles used to perform a release, stage and test a release. The
'flava'
poms define configurations which are intended to be inherited from by
projects to setup the muck needed for each version.
The plugin currently only provides validation goals, which try to
help
reduce user-configuration errors. This plugin is used by the
default flava
and avoids the need for staged builds.
The genesis-geronimo-skin module is our normal skin, hasn't really
been
changed... for better or worse.
The genesis-packaging module contains the muck that used to be in the
tools-maven-plugin, its not hooked up by default so it needs to be
configured as an extension where its needed.
* * *
Release configuration currently consists of the following properties:
* release.stageRequired
* release.gpgPassphrase
* release.stageDeployUrl
* release.siteStageDeployUrl
Which usually ends up in your ~/.m2/settings.xml as somthing like:
----8<----
<project>
<profiles>
<profile>
<id>release-configuration</id>
<activation>
<property>
<name>release</name>
</property>
</activation>
<properties>
<release.gpgPassphrase>***YOUR GPG
PASSPHRASE***</release.gpgPassphrase>
<release.stageDeployUrl>file://***DIRECTORY OF YOUR
LOCAL
STAGE REPOSITORY***</release.stageDeployUrl>
<release.siteStageDeployUrl>file://***DIRECTORY OF
YOUR LOCAL
SITE STATE REPOSITORY***</release.siteStageDeployUrl>
</properties>
</profile>
</profiles>
</project>
---->8----
When performing a normal (non-staged release, not the norm for ASF
muck),
one can:
mvn -Drelease release:prepare
mvn release:perform
For normal ASF staged releases:
mvn -Drelease=stage release:prepare
mvn release:perform
Stages releases, IMO, should be deployed to a local URL and once
the build
has finished the release-manager should perform an scp to deploy to
a shared
location. The reason for this is that often times, during a
project release
which consists of many (many) modules, often times the network
connection
will break and fail release builds. This is a problem because
mvn's release
deployment occurs for each modules, not at the end of the build,
though for
releases, before the build occurs some scm changes will occur. So to
minimize problems, staging to a local URL for the build, then after
the
build succeeds manually deploying to a shared location should
provide better
overall results.
It may be possible to automate this procedure at a later date...
but for now
its assumed to be manual.
* * *
I had tried to make Genesis 2.0 generic enough to be used by other
projects,
specifically the other mvn plugins I maintain for the Mojo project,
though I
haven't really found a good way to do that completely. But because
of this
Genesis 2.0 allows non-staged releases. But projects can define
'release.stageRequired' to be 'true' in their projects pom to
require the
release to be staged. This property is configured in the project's
pom.
Which means that this will fail:
mvn -Drelease *
and this will not:
mvn -Drelease=stage *
* * *
The site staging bits are still kinda in the works, need to get more
experience with how we actually use it, though right now I have
some basic
configuration enabled.
Folks that want to build javadoc and source distributions for
testing can
enable the 'distribution' profile, which is very close to what the
'full'
profile in Genesis 1.x used to be. This profile is flipped on
automatically
when -Drelease is specified. To turn on manually w/o release add '-P
distribution' to the invocation.
Before performing a release, its useful to run a build with
'-DtestDistributionUrl=file://...' set which will set the DM muck
to the URL
given, allowing a preview of the release muck w/o performing any
SCM muck.
And finally, and somewhat experimental ATM, there is a profile
which can be
flipped on optionally to ensure that no snapshots are defined and
no plugin
version are undefined via:
mvn -Denforce=strict
This enables a SNAPSHOT version of the enforcer to run some rules
to puke if
things aren't savvy as desired. As soon as the latest maven-
enforcer-plugin
gets released I will most likely enable this by default, at least
for the
plugin version stuff, and the non-snapshot stuff for release
preparation.
* * *
I've setup a test project to validate some of this muck here:
http://svn.apache.org/repos/asf/geronimo/sandbox/genesis-test
So far all tests seem to indicate that, at least my usage, works.
And now... its times to ask for feedback before I proceed further.
From
what I can tell this stuff works well, but I'm not sure if I have
missed
anything. So take a look, at ping me back please.
Cheers,
--jason
