I've started test-driving the maven release plugin toward the TP2
release, and the first step was to make this work for HK2.
I now believe I made all the necessary changes for the release plugin to
work correctly. I changed HK2 to auto-complete OSGi version from Maven
version, tweaked the site generation a bit to work around a Maven bug,
and finally did some more nasty hacking to work around the cyclic
reference issue between the hk2-maven-plugin vs hk2.
For us to run the release plugin on GFv3, one of the prerequisite is for
all its dependencies to be non-SNAPSHOT. So I propose we switch GFv3 to
depend on a released version of HK2, instead of the current SNAPSHOT
dependency.
There are several implications in doing this, but most notably, when we
make changes in HK2 that need to be picked up by GFv3, HK2 needs to be
released and the new version must be given. For us to test the local
SNAPSHOT HK2 with GFv3, we'd have to build GFv3
But I think going forward this is the right thing to do. This should
also fix the temporary build breakage problem when you make a change
that spans across HK2 and GFv3.
I can set up a Hudson task so that we can automate the release process.
WDYT?
----
Before I lose this note, this is the exact instruction to run a
successful release
# base line
mvn clean install
# this fails citing maven-hk2-plugin is not available
mvn -B -P release release:prepare
# so we build it...
mvn -P release-phase1 install
# then retry the release
mvn -B -P release release:prepare
# now I need this again, just so that POM loads
mvn -P release-phase1 install
# finally a release
mvn -B release:perform
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com