These notes supercede the old notes

      1. Uploading to source forge
      2. Creating a release in two steps
      3. Creating Releases
        1. Project POM
        2. Core modules
        3. Plugins
        4. Release specification
        5. Application archetype
        6. Distribution
        7. Reverting back to development mode
        8. Releasing a module
      4. Adding release to SourceForge site

Uploading to source forge

rsync -avP -e ssh nakedobjects-* SFNAME@frs.sourceforge.net:uploads/

Creating a release in two steps

$ svn up
$ svn st
$ mvn --batch-mode release:prepare -P release-all

$ mvn --batch-mode release:prepare -P release-all
$
$ mvn release:stage -DstagingRepository=staging3::default::file:/home/rcm/staging3/ -P release-all

Creating Releases

Releasing Naked Objects now takes place in phases, rather than a monolithic blob. Naked Objects consists of the following parts, which are release separately:-

  • Project POM (/pom) - changed irregularly.
  • Core (/core) - all the core modules used by all the plugins and applications - changes as one group.
  • Plugins (/plugins) - pluggable components that can be swapped in and out - each can be developed and release separately.
  • Release POM (/release) - defines the set of modules for a given release, logically bundling them together. This POM is then used by the distribution build process, and by external Maven projects as a way of specifying all the relevant files in one go.
  • Distribution (/distribution) - the manuals, example and downloadable tarball - collects everything together so it can be downloaded as one file.
  • [Archetypes - uses Mavens archetype mechanism to create applications and add support - bases on core and plugins]

Although the entire system can be built from the root it is important that it is never released this way otherwise all the modules will be bumped up and version will not be correct. Always deal with each part separately.

1. Before starting ensure that you have the latest changes and that all code is checked in. It is important that there are no uncommitted files, including backup files. All need to be removed so the status command returns nothing. 

$ svn up
$ svn st

2. Ensure that everything builds successfully, ideally when no naked object artifacts exist in the repository (as this will help catch any subtle version mismatches),

First move all old nakedobjects artifacts to one side: 

$ mv ~/.m2/repository/org/nakedobjects ~/.m2/repository/org/nakedobjects-`date+%Y%m%d`

Then do a build to test it all: 

$ mvn clean
$ mvn install

Project POM

The project POM contains information about the project generally and does not change from release to release. Hence the version is never in development and should never use the SNAPSHOP suffix. Simply update and deploy. 

$ cd pom
$ mvn deploy

To deploy to the staging repository instead use 

$ mvn deploy -DaltDeploymentRepository=staging::default::file:///home/rcm/staging

Core modules

Core modules form the basis of all other releases and should all be released first and as one version. This is achieved by releasing the core module so all the submodules are released. 

$ cd core

and follow the directions below for releasing a module.

Plugins

Plugins are typically released one by one as they are developed separately. Each plugin relies on a specific version of the core modules and this is specified via the parent element within the plugin's POM file. This version must be a non-SNAPSHOT version for the release process to work.

Therefore a plugin should be selected before working through the release process, eg 

$ cd plugins/dnd-viewer

and its POM edited so that the parent version is the same as the released core version. 

$ vi pom.xml

After testing the build this new version should be checked in 

$ mvn test

Finally follow the instruction for releasing a module below.

This process is needed if you are only releasing some of the modules. If all of the plugins are to be released the this process can be carried out within the plugins directory so that all the plugins listed in it POM will be released together.

Release specification

Once the core and all the plugins have been released then the release specification should be updated to specify the complete valid set of artifacts. Again this follows the standard process, eg 

$ cd release

and edit its POM so that the dependency versions all reference the released core and plugin versions. 

$ vi pom.xml

followed by the instruction for releasing a module below.

Application archetype

The archetype simply depends on the release module. 

$ cd archetypes/application

but this time it is the POM within the archetype source that needs to be edited. This simply needs refer to the latest version of the release module as its parent. 

$ vi src/main/resources/archetype-resources/pom.xml

Finish off by following by the instruction for releasing a module below.

Distribution

The distribution bundles all the parts together into a download. This is not deployed as the other artifacts are, so process is slightly different. 

$ cd distribution

Edit the distribution's POM file to set the parent version to the release version 

$ vi pom.xml

and do the same for the examples (examples/pom.xml).

Now run the release preparation goal 

$ mvn --batch-mode release:prepare

When this has complete a number of distributables are placed in tarball/target. These should be copied out so that they do not disappear when the next build occurs 

$ cp tarball/target/* /releases

Complete the process by removing the temporary files 

$ mvn release:clean

To rebuild a released version you will need to check out the tagged source, as the versions have now been updated.

Reverting back to development mode

Once everything has been released some of the POMs will be referring to the new release. These need to be updated to refer to current development release. This includes:

  • All the plugins (which are based on org.nakedojjects:core)
  • release/pom.xml (which all applications refer to whole of Naked Objects via)
  • distribution/pom.xml and distribution/exmple/pom.xml which all tie the distributions to a specific set of artifacts.

After each is updated that module should be installed so the new versioned artifact becomes available.

With these updated, it is now time to make any applications refer to the latest version of Naked Objects.

Releasing a module

1. Prepare the release - this prepares the POMs by changing the version numbers and checks in the files as a tagged revision. Running in batch mode saves us from having to enter version numbers, it simply increments the current number. 

$ mvn --batch-mode release:prepare

or do a dry run to prevent changes to the repository 

$ mvn --batch-mode release:prepare -DdryRun=true

When we do need to change the version (ie when a different increment is needed run the command without the batch-mode flag: 

$ mvn release:prepare

If this process fails then it important to rollback the changes made to the repository so that your work space and the repository are not left in hard to recover state: 

$ mvn --batch-mode release:rollback

2. Create the actual the release - this checks out the release into the target/checkout and runs the deploy goal. Alternatively the tag can be checked out manually and deployed manually. (See notes below for version 3.0.) 

$ mvn release:perform

or o release to a staging repository instead use 

$ mvn release:stage -DstagingRepository=staging::default::file:/home/rcm/staging/

3. Complete the process by removing the temporary files 

$ mvn release:clean

Adding release to SourceForge site

1. Upload files from `release/target/nakedobjects*' to SourceForge upload. Using scp the command is 

 $ scp nakedobjects-4.0-* usename@frs.sourceforge.net:uploads

where username is your SourceForge user name. You will prompted for your password.

2. Go to Admin menu on SourceForge? project page and select File Releases to add a new release

3. Create a new release of the form "Version 3.0.3"

4. Upload release notes, checking the box " Preserve my pre-formatted text."

5. Select all the uploaded files

6. Add them to the release

7. For each file specify the processor (as "Platform Independent") and file type

8. On the project download page check release notes and downloads

9. Back on the release page use the last option to "Email Release Notice"