Looks good Jason. I too agree that it should be required to stage
locally and scp to a public location for the vote. I too have had
things accidentally pushed to rsync too soon.
Will the release:rollback and stage:copy remain unchanged? Also, has
this been validated with multiple subprojects (such as in Javamail and
server) ... there still seems to be some issues there with genesis 1.4
and getting all of the artifacts signed.
I also wonder how this will affect the server release process in the
short term. Eventually we want to move over to using the full mvn
release process but lately we've been doing a hybrid approach using mvn
-Prelease deploy to a staging site and then mvn stage:copy to move it to
the production repo.
I attempted to play with it a bit based on your genesis-test project but
got a bit hung-up on the snapshot dependencies for genesis itself. I
didn't take the time yet to build genesis w/o the snapshot version and
try again.
Joe
Jason Dillon wrote:
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
