Apache Struts 2 Documentation > Home > Guides > Contributors Guide > Creating and Signing a Distribution > Creating and Signing a Struts 2.1.x Distribution
#editReport()

Content

To keep this list current, it is strongly recommended that release managers refer to and follow this list each time a distribution is created. If any of the steps need to be amended, then please update the list.

Building Steps (Struts Annotations)

Obtain a fresh check out of struts annotations

svn co https://svn.apache.org/repos/asf/struts/maven/trunk/struts-annotations struts-annotations

Prepare release

mvn -Prelease release:prepare -Dusername=yourSvnUsername -Dpassword=yourSvnPassword

Accept the suggested tag name

For some reason, when using svn client 1.5, the release plugin might fail to tag the release, if it fails, run:
svn up -r head
mvn -Prelease release:prepare -Dresume

Perform release

mvn -Prelease release:perform -Dusername=yourSvnUsername

Send a VOTE email

A sample template is at the bottom of the page (and DO wait for the 72 hours period)

Copy files (If vote passed)

ssh people.apache.org
cp -R  /www/people.apache.org/builds/struts/struts-annotations-$VERSION/m2-staging-repository/org/apache/struts/struts-annotations/ /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/struts/struts-annotations/

Building Steps (Struts)

Getting ready

  1. Create an "Struts 2.x.y omnibus ticket" ticket in JIRA to refer to in upcoming release related commit comments and for general documentation purposes. Mark it with priority "Blocker".
  2. Ensure that the master POM and Struts Annotations have current releases
  3. Review JIRA for any issues without a fix version set, and for any issues that should be resolved for the pending release.
  4. Ensure that there are no repositories or pluginRepositories listed in the poms.
  5. If you have committed all changes regarding the release process, close the omnibus ticket as it is the last open ticket for the upcoming release
  6. Release the upcoming version in JIRA (under Administration/Manage Releases) and tag the release date
  7. Add next milestone version to the JIRA roadmap
  8. Create DONE and TODO filters for the new version, share with all, and remove obsolete TODO filter
  9. Create new release page in Confluence, link from Migration Guide, and link to prior release page and JIRA DONE filters of the version to release

Obtain a fresh checkout.

svn co https://svn.apache.org/repos/asf/struts/struts2/trunk STRUTS_#_#_#

Prepare release

Tag the release by using the "release:prepare" goal of Maven:

mvn -Prelease release:prepare -Dusername=yourSvnUsername -Dpassword=yourSvnPassword -DautoVersionSubmodules=true

For a dry run, add '-DdryRun=true'. If you do a dry run, use 'mvn release:clean' to clean up after you have looked at the output.

When prompted for the SCM tag name, follow this pattern: STRUTS_2_1_[PATCH_VERSION]

For some reason, when using svn client 1.5, the release plugin might fail to tag the release, if it fails, run:
svn up -r head
mvn -Prelease release:prepare -Dresume

This step will (more information):

  • Check that there are no uncommitted changes in the sources
  • Check that there are no SNAPSHOT dependencies
  • Change the version in the poms from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
  • Transform the SCM information in the POM to include the final destination of the tag
  • Run the project tests against the modified POMs to confirm everything is in working order
  • Commit the modified POMs
  • Tag the code in the SCM with a version name (this will be prompted for)
  • Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
  • Commit the modified POMs

Perform the release

mvn -Prelease release:perform -Dusername=yourSvnUsername

This step will (more information):

  • Checkout from an SCM URL with optional tag
  • Run the predefined Maven goals to release the project (by default, deploy site-deploy)

After this step the artifacts will be under people.apache.org:/www/people.apache.org/builds/struts/$VERSION/m2-staging-repository/

If you need to run perform again, (or in a different box), do:

svn co http://svn.apache.org/repos/asf/struts/struts2/tags/$VERSION
cd $VERSION
mvn deploy site-deploy -Prelease --no-plugin-updates -DperformRelease=true 

Move the artifacts to the /www/people.apache.org/builds/struts/$VERSION dir

ssh people.apache.org
cd /www/people.apache.org/builds/struts/$VERSION

find m2-staging-repository -name "*.zip*"    -exec cp {} . \;

#remove 'struts-assembly' from the file names
for src in $('ls');do trg=$(echo $src | sed -e "s/struts2-assembly/struts/");mv -v $src $trg; done

#remove assembly dir
rm -rdf m2-staging-repository/org/apache/struts/struts2-assembly/

#remove signature checksums
rm *.asc.md5 *.asc.sha1

Jira stuff

  • Update JIRA roadmap with tag/release date
  • Add next milestone to the JIRA roadmap
  • Create DONE and TODO filters, share with all, and remove obsolete TODO filter;
  • Create new release page, link from Migration Guide, and link to prior release page and JIRA filters.

Vote on it

Post a release/quality vote to the dev list (and only the dev list).

Copy files

After the vote, if the distribution is being mirrored (there was a favorable release vote) copy the Sources and Binaries:

ssh people.apache.org
cd /www/people.apache.org/builds/struts/$VERSION
cp struts-$VERSION-src.*  /www/www.apache.org/dist/struts/source
cp struts-$VERSION-docs.*  /www/www.apache.org/dist/struts/documentation
cp struts-$VERSION-lib.* /www/www.apache.org/dist/struts/library
cp struts-$VERSION-apps.* /www/www.apache.org/dist/struts/examples
cp struts-$VERSION-all.* /www/www.apache.org/dist/struts/binaries   

Copy the Maven artifacts

ssh people.apache.org
cp -R /www/people.apache.org/builds/struts/$VERSION/m2-staging-repository/org/apache/struts/  /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/struts/ 
find /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/struts/ -user ${USER} -type f -exec chmod 664 {} \;
find /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/struts/ -user ${USER} -type d -exec chmod 775 {} \;
The default setup on people.apache.org will leave the files and directories only changeable by the user who creates them. The last two steps will allow future releases to go smoothly.

Wait for rsync

Wait 24 hours before proceeding.

Update site (Struts 2 site)

ssh people.apache.org
export VERSION=2.1.x

unzip /www/people.apache.org/builds/struts/$VERSION/struts-$VERSION-docs.zip -d ~/docs
#now the docs are under ~/docs/struts-$VERSION/docs
mkdir -p /www/struts.apache.org/$VERSION
mv ~/docs/struts-$VERSION/docs /www/struts.apache.org/$VERSION
chmod -R g+w /www/struts.apache.org/$VERSION

Update site (Struts top level site)

  • Check out site src code
    svn co https://svn.apache.org/repos/asf/struts/site/ struts-site
    
  • Update xml files
    • struts-site/src/site/xdoc/announce.xml
    • struts-site/src/site/xdoc/downloads.xml (remove previous version)
    • struts-site/src/site/xdoc/download.xml (remove previous version)
    • struts-site/src/site/xdoc/index.xml
    • struts-site/src/site/site.xml
  • Commit the changes
  • Generate the site
    mvn site:site
    
  • Open struts-site/target/site/index.html and verify the urls and versions are right
  • Deploy site
    mvn site-deploy
    

    It takes a few hours for the site changes to go live

Permissions

After updating the site, be sure that the permissions are set to group writeable ($ chmod -R g+w .)

Post announcements

We leave this as the last step, once the artifacts have had time to sync up on the mirrors.

One time

Create and install a SSH key

If you get hung up during release:perform because Maven can't verify the authenticity of a host, then there could be one of two
different problems. The first problem, which is an easy fix, is to go to the command line and use SSH to log in to that host. You
should receive a prompt to add the host to your known_hosts file. If you add the host to your known_hosts file from the command line
SSH, then you should be able to try release:perform again and have more success. There is a chance though that this won't fix maven.

Maven doesn't appear to understand hashed known_hosts files. There is some information here - known_hosts file Hashing.
If your known_hosts file is hashed, you can solve this one of a few different ways. If you perform a deploy:deploy instead of
release:perform, then maven will leave a prompt open for you to type 'yes' and have maven add the host (in a way that Jsch, the library
which provides Maven Wagon with the SSH/SCP functionality, understands) to your known_hosts file. Another option is to remove your
known_hosts file, update your SSH configuration so that it does not hash the hostname in known_hosts and try to log in from the command
line.

mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -q -f ~/.ssh/id_rsa -t rsa
#Enter a passphrase
chmod go-rwx ~/.ssh/*

#copy the public key to people.apache.org
scp ~/.ssh/id_rsa.pub people.apache.org:/home/$USERNAME

# next, setup the public key on server
ssh people.apache.org
mkdir ~/.ssh
chmod 700 ~/.ssh
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
rm ~/id_rsa.pub

Create a PGP key

svn co https://svn.apache.org/repos/asf/struts/maven/trunk/build struts-maven-build
cd struts-maven-build
(gpg --fingerprint --list-sigs <your name> && gpg --armor --export <your name>) >> KEYS
scp KEYS people.apache.org:/www/www.apache.org/dist/struts
svn commit KEYS -m "Add public key"

Update Maven settings for our servers

Create a settings.xml under ~/.m2

<settings xmlns="http://maven.apache.org/POM/4.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <servers>
       <server>
          <id>apache.snapshots</id>
          <username>$USERID</username>
          <privateKey>$PATH_TO_PRIVATE_KEY</privateKey>
          <passphrase>$PASSPHRASE</passphrase>
          <directoryPermissions>775</directoryPermissions>
          <filePermissions>644</filePermissions>
       </server>
       <server>
          <id>struts-staging</id>
          <username>$USERID</username>
          <privateKey>$PATH_TO_PRIVATE_KEY</privateKey>
          <passphrase>$PASSPHRASE</passphrase>
       </server>
       <server>
          <id>apache-site</id>
          <username>$USERID</username>
          <privateKey>$PATH_TO_PRIVATE_KEY</privateKey>
          <passphrase>$PASSPHRASE</passphrase>
          <directoryPermissions>775</directoryPermissions>
          <filePermissions>664</filePermissions>
       </server>
    </servers>
   <profiles>
       <profile>
        <id>cargo-config</id>
         <properties>
            <cargo.tomcat5x.home>$CATALINA_HOME</cargo.tomcat5x.home>
         </properties>
       </profile>
       <profile>
        <id>release</id>
        <properties>
          <gpg.passphrase>$PASSPHRASE</gpg.passphrase>
        </properties>
       </profile>
   </profiles>
   <activeProfiles>
      <activeProfile>cargo-config</activeProfile>
   </activeProfiles>
</settings>

Increase Memory Settings for Maven

To complete a full build and all the tests, it may be neccesary to increase the amount of memory available to Maven. The simplest thing is to set an environment variable.

  • MAVEN_OPTS=-Xmx512m or even MAVEN_OPTS=-Xmx1024m

Resources

Retagging

If a tagged build needs to be retagged, be sure to delete the old tag first.

svn delete https://svn.apache.org/repos/asf/struts/struts2/tags/STRUTS_#_#_# -m "WW-### Removing first try at 2.#.#."

Amending a log entry

If the commit was fine, but the log was wrong, updating the log entry is easy. For example,

> svn propset --revprop -r 504523 svn:log "WW-1715 Branch for 2.0.x at Struts 2.0.6-SNAPSHOT r504196"
> property 'svn:log' set on repository revision 504523

See svn help propset for more.

Sample Struts Annotations Release/Quality Vote

Subject: [VOTE] Struts Annotations 1.0.x Vote
The Struts Annotations 1.0.x test build is now available as a Maven
artifact. It is a dependency of Struts 2.x.y.

If you have had a chance to review the test build, please respond with
a vote on its quality:

[ ] Leave at test build
[ ] Alpha
[ ] Beta
[ ] General Availability (GA)


Everyone who has tested the build is invited to vote. Votes by PMC
members are considered binding. A vote passes if there are at least
three binding +1s and more +1s than -1s.

The vote will remain open for at least 72 hours, longer upon request.

Sample Test Build Announcement

Test builds are only announced to the dev list. Announcements to the user list can only be made pursuant to a release vote with the consent of the PMC.

The test build of Struts 2.0.3 is available.


No determination as to the quality ('alpha,' 'beta,' or 'GA') of Struts 2.0.3 has been made, and at this time it is simply a "test build".  We welcome any comments you may have, and will take all feedback into account if a quality vote is called for this build.

Release notes:
* [LINK]

Distribution:
* [http://people.apache.org/builds/struts/#.#.#/]

Maven 2 staging repository:
* [http://people.apache.org/builds/struts/#.#.#/m2-staging-repository/]


We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues.

Sample Release/Quality Vote

Subject: [VOTE] Struts #.#.# Vote
The Struts #.#.# test build is now available.

Release notes:
* [http://struts.apache.org/2.x/docs/version-notes-###.html]

Distribution:
* [http://people.apache.org/builds/struts/#.#.#/]

Maven 2 staging repository:
* [http://people.apache.org/builds/struts/#.#.#/m2-staging-repository/]

Once you have had a chance to review the test build, please respond with a vote on its quality:

[ ] Leave at test build
[ ] Alpha
[ ] Beta
[ ] General Availability (GA)

Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s.

The vote will remain open for at least 72 hours, longer upon request. A vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as "Beta", the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list.

As always, the act of voting carries certain obligations. A binding vote not only states an opinion, but means that the voter is agreeing to help do the work

Sample Release Announcement

The Apache Struts group is pleased to announce that Struts 2.0.6 is available as a "#####" release. \[\[The Beta designation indicates that we believe the distribution needs wider testing before being upgraded to a "General Availability" release. Your input is essential.\] The GA designation is our highest quality grade. \]

[http://struts.apache.org/download.cgi#struts###]

The release is also available from the central Maven repository under Group ID "org.apache.struts".

The #.#.x series of the Apache Struts framework has a minimum requirement of the following specification versions:
* Java Servlet #.# and JavaServer Pages (JSP) #.#
* Java 2 Standard Platform Edition (J2SE) #.#

The release notes are available online at:
* [http://struts.apache.org/2.x/docs/release-notes-###.html]

Should any issues arise with your use of any version of the Struts framework, please post your comments to the user list, and, if appropriate, file a ticket with JIRA.

- The Apache Struts group.

Fast-Tracking an Important Security Release

  • When a serious security issue arises, we should try to create a #.#.#.1 branch from the last GA release, and apply to that branch only
    the security patch.
  • If the patch first applies to XWork, or some other dependency, implore the other group to do the same, to avoid side-effects from other changes.
  • If the release manager would like to "fast track" a vote, so as to make a security fix available quickly, the preferred procedure is to
    • Include the term "fast-track" in the subject, as in [VOTE] Struts 2.0.9.1 quality (fast track)
    • In the vote message, specify voting terms like:
The Struts #.#.#.1 test build is now available.

Release notes:
* [http://struts.apache.org/2.x/docs/release-notes-####.html]

Distribution:
* [http://people.apache.org/builds/struts/#.#.#.1/]

Maven 2 staging repository:
* [http://people.apache.org/builds/struts/#.#.#.1/m2-staging-repository/]

Once you have had a chance to review the test build, please respond with a vote on its quality:

[ ] Leave at test build
[ ] Alpha
[ ] Beta
[ ] General Availability (GA)

Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s.

This is a "fast-track" release vote. If we have a positive vote after 24 hours (at least three binding +1s and more +1s than -1s),  the release may be submitted for mirroring and announced to the usual channels.

The website download link will include the mirroring timestamp parameter [1], which limits the selection of mirrors to those that have been refreshed since the indicated time and date. (After 24 hours, we \*must\* remove the timestamp parameter from the website link, to avoid unnecessary server load.) In the case of a fast-track release, the email announcement will not link directly to <download.cgi>, but to <downloads.html>, so that we can control use of the timestamp parameter.

[1] <[http://apache.org/dev/mirrors.html#use|http://apache.org/dev/mirrors.html#use]>