openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <>
Subject OpenJPA release process
Date Fri, 30 May 2008 18:54:44 GMT
Hi all,

We've run into a lot of issues with the current release process. Many of
these are new things that we haven't elected to do in previous releases (ie
sign the maven repository artifacts, or add javadoc jars). While we've been
working through them it's looking more and more like the release process
needs updating.

I took some time recently to try out the maven-release-plugin. As you may
remember I tried using this with the 0.9.7 release and I ran into some
issues - mainly that it stripped the license header out of every copy of
pom.xml. I think I've worked out most of those issues with a few caveats
mentioned below and I think we should update our poms to take advantage of
the plugin.

What the plugin will do :
* create a new branch for the release (if needed)
* update pom.xml with the new versions
* create a tag for the new release
* deploy the results to a staging location.

To give a better frame of reference if we use the plugin the release process
will look something like this :

// update text files (CHANGES.txt, BUILDING.txt, etc.) and pom files (new
developers) if needed.
$ mvn -Prelease release:branch  -DbranchName=1.2.x  # this won't be needed
if we're working on the 1.0.3 stream.
$ svn checkout
$ cd 1.2.x
$ mvn -Prelease release:prepare
$ svn diff // make sure that the release plugin hasn't removed the license
header from pom.xml.
// if possible run the TCK tests
// run RAT
// verify signatures
// run examples
$ mvn -Prelease release:perform
// call for vote etc.

Previously you would have had to do this :

// update text files (CHANGES.txt, BUILDING.txt, etc.) and pom files (new
developers) if needed.
$ svn copy -m "OpenJPA Release 1.2.1 branch" \ \
$ svn checkout
$ cd 1.2.1
$ perl -pi -e
"s;<version>1.0.1-SNAPSHOT</version>;<version>1.0.1</version>;g" \
    pom.xml */pom.xml */*/pom.xml
$ mvn clean install -Dtest=false
// if possible run TCK
// run RAT
$ export MAVEN_OPTS=-Xmx1000m
$ mvn --batch-mode deploy site \

    -Djava14.jar=${JAVA_HOME}/../../1.4/Classes/classes.jar \${HOME}/.m2/privaterepos/
// run examples
// verify signatures
$ mvn site:deploy
// call for vote

Ultimately it just automates the process and should save a bit of time with
future releases and lower the learning curve for future release managers.

Caveats :
* Currently the release plugin is very sensitive to the formatting in
pom.xml. For example if the project tag occurs on multiple lines it will
reformat it so that it's on a single line - removing the license header in
the process. Other formatting issues can also cause the plugin to remove the
license header. The solution is to check whether they've been removed after
running mvn release:prepare. If anything other than the version has been
updated you'll have to rollback and manually merge those changes.
* release:rollback will undo the changes to pom.xml, but it will not remove
the tag location in svn. If you need to rollback you'll have to do that
* The release plugin is touchy about having unversioned files in a SCM
directory - it's probably best to work from a fresh checkout.

If there are no objections to making the change I'd like to go ahead and
update the poms in 1.2.x.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message