Skip to end of metadata
Go to start of metadata


These are the release notes cataloging all deviations I encountered while releasing Maven 2.0.3. It's still in APT format, but I'll convert that in the next couple of days.

IMPORTANT: I still have one TODO below. I'll highlight it here:

  • Need to clean up the POMs on the 2.0.x branch now that the old release plugin is finished with them. They're a bit of a mess.

Release Process Notes

  Maven 2.0.3 Release Diary
  John Casey
  27 March 2006

Maven 2.0.3 Release Diary

* Deviations from Published Process

  * release plugin broken in SVN (ClassCastException in ScmHelper); using released version

    This caused a cascading problem with resolving versions of interdependencies, since we're not
    running the package phase in this build. Had to <<<svn revert --recursive .>>>, remove the
    <<<>>>, and start again.

  * commons-logging javadoc: location of <<<package-list>>> was wrong, should have been <<</apidocs>>>
    instead of <<</api>>>.

    Changed on localhost in target/checkout directory, and also on the next iteration of the main pom.xml.
    Not sure how to propagage this change into the tagged may be as simple as committing the
    one in target/checkout, I dunno...

    Committed changed pom.xml that was in target/checkout...looks like it took.

  * ditto problem in maven-reporting, maven-script, and maven-plugin-tools. Updated/committed.

    <<NOTE:>> Why doesn't the maven-reporting POM inherit that javadoc URL list from the main POM??
    Is this a side effect of the release plugin's execution??

  * Added source-assembly configuration to root POM, but it's broken.

    \<excludes\> tags don't work correctly, so I had to tweak the build with a profile for source-assembly
    creation. The usage is:

/home/jdcasey/workspace/maven-branch/components $ mvn assembly:assembly -Dsource-assembly=true

    This profile injects the maven-clean-plugin at the package phase, to get rid of **/target by
    brute force.

  * Removed all sandbox-based and/or mojo-project reports from the maven, maven-script, 
    maven-reporting, and maven-plugin-tools POMs, to keep them from blocking the Maven release.

  * Fixed modello-maven-plugin configuration in maven-profile and maven-plugin-registry to have 
    the configuration of the model location and version outside of any executions, to enable the 
    site-deploy phase to work correctly.

  * Removed \<distributionManagement/\> section from maven-core, to allow site-deploy to proceed.

  * Had to manually move the site docs for maven-embedder from <<</www/>>>
    to <<</www/>>>.

  * Had to build the latest maven-site-plugin from SVN in order to deploy the <<</site>>>.

  * Had to fix snippet reference in src/site/apt/guides/mini/guide-using-modello.apt.

    It was referencing archetype.mdo in archetype-core, but it's now in archetype-model.

  * Added source-assembly configuration, along with a profile that will attach clean:clean to 
    the package phase when <<<-Dsource-assembly=true>>>, to maven root POM.


* <<TODO>>

  * Fix POMs messed up by old version of the release plugin


* Notes

  * We probably need to release the maven-release-plugin ahead of the Maven release, so we don't
    have to run the release using some revId of the release plugin. The old version will pollute
    the POMs, which is bad, but less bad than trying to chase down a problem in SVN...and that
    plugin shouldn't have to work at any given point in time when built from SVN.

    We should be able to do a reverse-merge on **/pom.xml to get back to pre-release POMs, and
    search-and-replace 2.0.3 -> 2.0.4.

  * We should probably perform a dry-run on the codebase before performing <<<release:prepare>>>,
    so we can catch problems in javadoc generation, etc. We might not be able to actually run to
    the deploy phase, but everything up to that point should be doable.

    The way I addressed this in maven-artifact-ant and maven-embedder was to run:

mvn clean install -DperformRelease=true


  • No labels