The next release and kenai moving

I’m finally going to do a release of retepTools and retepMicroKernel this weekend, mainly due to it being a 3 day weekend here in the UK.

However, this weekend kenai.com are moving datacentres, as part of Oracle’s slow consumption of Sun.

So the plan is going to be:

  1. Friday – No updates on the kenai.com site (see below)
  2. Saturday – prepare retepTools then release
  3. Sunday – prepare retepMicroKernel then release
  4. Monday – any remaining cleanup

This will leave me with the Monday to tidy up. With kenai moving, the release will be done against the bitbucket mercurial repositories as the kenai ones will be unavailable (see below). When kenai have completed their move then I’ll sync the kenai repositories so they are back in sync.

Then I’ll be able to concentrate on the next release which will be primarily to get the artifacts deployed within maven central.

Finally, here’s the notification of this weekends migration over at kenai.com.

We’re Moving!

Kenai is moving from our old home into new digs. As part of the transition, we need to move quite a bit of data, which presents us with some interesting challenges.

On Friday (April 30th) @07:00 UTC, http://kenai.com will be placed into a VIRTUAL READ-ONLY transitional mode. What does this mean?

1. SCM systems will be down, and not accessible.
2. Bug-tracking systems will be down, and not accessible.
3. Instant Messaging (IM) will continue to function.
4. Mailing lists will continue to function, but no email will be archived during this time.
5. The main website will be up, but with the following caveats:
* Project creation will be disabled.
* Account creation will be disabled.
* Any modifications to data, made during this transitional period, will be lost when we finally cut over to the new site.

It’s worth repeating : The websites will be up, but any changes made during the transitional period WILL NOT CARRY THROUGH AFTER CUTTING OVER TO THE NEW SITE.

We realize that this has the potential to cause some confusion, so for the duration of the transitional period, the website will sport a clear warning banner on every page.

Thank you for your participation in and loyalty with Kenai.com.

Our very best,
The Kenai.com Team

Kenai to Java.net migration update

Just a quick one but finally I’ve received an update about whats happening with the migration of kenai.com over to java.net. I was wondering what was happening as there’s been nothing apparent for a while now, well at least this helps.

Hi Everyone,

We told you we would have an update in about a month and that time has come.
The plan of record has not changed. Work is on-going for migrating the Java.net domain over to the Kenai infrastructure and we will move the existing Kenai.com projects over to the Java.net domain as soon as we have everything in place.

The work will take a bit of time to complete, so please feel comfortable using Project Kenai while we work towards the final move to Java.net.

If you have any questions please continue to send them to the kenai-admin<at>sun.com alias as always. We’ll do our best to answers them.

Best Regards,

The Project Kenai Team

Kenai – is it closing or is it staying?

Well this is a bit of a shock – first they were going to close Kenai.com so a lot of projects (including myself) started migrating away as we had a deadline of 20th April but a couple of hours ago I got an email saying everything’s changed. Now it appears that they are going to migrate java.net to the kenai architecture so all projects are going to be migrated there rather than just deleted.

Now they could have told us this in the first place and have saved a lot of us the now wasted time of migrating everything away from kenai – effectively 1 1/2 weeks wasted in ensuring nothing is lost.

It’s not all wasted effort however.

As I use a distributed scm (Mercurial) I’ve now got a working online backup of the sources over at bitbucket.org – thats working fine, so if this is true then that will stay. I have an offline backup of the repos which I automatically push to anyhow, so getting that job to push back out to bitbucket is easy. As a bonus you can even see commits on twitter.

Also the maven repositories are at sonatype – so there maven is now working better than it did at kenai (one of the only two things I had problems with on kenai).

The one big problem I had in migrating was the project. I had created two projects on javaforge.com as that appeared to have something closer to kenai (other than jira). However I soon found two major downsides to it.

  1. You must have a javaforge account to clone from mercurial – you can’t even browse source unless logged in
  2. Anyone who submits a changeset must also have a javaforge account

Now these problems are terrible. It effectively locks you in to them and removes the benefits of having a distributed scm – receive a changeset from someone and push it to there – they automatically refuse the changeset. Also why prevent someone access to the source if they are anonymous? I’ve since found references to that problem where people have given up on javaforge because you can’t to it. Not good.

So what now?

Well I’m going to plod on – I’ve got a few major issues to sort out with JAXB and XMPP to deal with, so I’m going to see what is said over the weekend after the surprise announcement. If this is true then I’m going to stay with kenai/java.net – lets hope this means keeping jira! As others have said in the forums, kenai is the best forge out there and the only one with true IDE support with NetBeans’s kenai module.

I’ll finish off (it’s 3:30 in the morning right now) with the email about this change of heart from Oracle:

Gentlepeople,

In an effort to get information out to the Kenai community quickly, while trying to manage the integration of our two companies, I think we did a poor job at communicating our plans for Kenai.com to you. I would like to remedy that now. Our strategy is simple. We don’t believe it makes sense to continue investing in multiple hosted development sites that are basically doing the same thing. Our plan is to shut down kenai.com and focus our efforts on java.net as the hosted development community. We are in the process of migrating java.net to the kenai technology. This means that any project currently hosted on kenai.com will be able to continue as you are on java.net. We are still working out the technical details, but the goal is to make this migration as seamless as possible for the current kenai.com projects. So in the meantime I suggest that you stay put on kenai.com and let us work through the details and get back to you later this month.

Thanks for your feedback and patience.

Ted Farrell
Oracle Corporation

Moving away from Kenai

As is commonly known, Oracle have finally taken over Sun and yesterday they announced what they are intending to do with the various services provided by Sun.

Unfortunately one of those announcements was that they were withdrawing the Kenai project from public use at some point in the near future. This is a pity because the Kenai project was becoming one of the more useful forges out there.

During today there’s been a lot of forum activity on the kenai site from a lot of project owners about what to do in migrating away, including myself.

So, after a good year of being hosted on kenai I’m now faced with moving to yet another forge – but where to go and what’s going to be involved?

Well the steps needed are (in order of importance):

  1. Move the source repositories
  2. Move the maven repository
  3. Move the jira issues
  4. Change all links to the new location(s).

As an initial measure I’ve mirrored the mercurial repositories on bitbucket so at least they are mirrored elsewhere. One of mercurial’s features is being distributed so that was relatively painless.

The next two are tricky so I’m still researching them, but they all depend on what forge to use. I’ve used sourceforge in the distant past so I don’t want to go back to them, and although bitbucket does have wiki and a tracker – it’s not jira.

Anyhow here’s the new repo information for the bitbucket mirrors:

  • https://username@bitbucket.org/petermount/reteptools/
  • https://username@bitbucket.org/petermount/retepmicrokernel/
  • https://username@bitbucket.org/petermount/retepxmpp/
  • https://username@bitbucket.org/petermount/retepjavadoc/

As soon as I’ll have more information I’ll make another post here, on twitter and on identi.ca

    Binding custom objects to attributes in JAXB

    When generating Java sources from an XML Schema with JAXB, the type of field used to represent an attribute is determined by it’s type in the schema.

    For example, a snippet from jabber-client.xsd:

    <xs:element name="message">
      <xs:complextype>
        <xs:attribute name="from" type="xs:string" use="optional">
          <xs:attribute name="to" type="xs:string" use="optional">
        </xs:complextype>
      </xs:sequence>
    </xs:element>
    

    By default, JAXB would create the object (Message in this case) with two String properties. To change this to another object (say JID) we would add a simple binding changing these to use JID and define two static methods who’s job it is to convert between a String and a JID.

    So the bindings would be something like:

    <bindings schemalocation="jabber-client.xsd">
      <bindings node="/xsd:schema/xsd:element[@name='message']/xsd:complexType">
        <bindings node="xsd:attribute[@name='from']">
          <property>
            <baseType>
              <javaType name="uk.org.retep.xmpp.JID"
                parseMethod="uk.org.retep.xmpp.jaxb.adaptor.XMPPDatatypeConverter.parseJID"
                printMethod="uk.org.retep.xmpp.jaxb.adaptor.XMPPDatatypeConverter.printJID"
              />
            </baseType>
          </property>
        </bindings>
      </bindings>
    </bindings>
    

    Now for mose usecases this is fine and works pretty well. The problem is when you have a large number of custom bindings.

    What JAXB does for each binding is that it generates an anonymous Adapter class. In that adaper class are two methods which call the two methods declared in the binding – in the case of binding to a Double you would get the following:

    public class Adapter1
        extends XmlAdapter<String, Double>
    {
    
        public Double unmarshal(String value) {
            return (javax.xml.bind.DatatypeConverter.parseDouble(value));
        }
    
        public String marshal(Double value) {
            if (value == null) {
                return null;
            }
            return (javax.xml.bind.DatatypeConverter.printDouble(value));
        }
    
    }
    

    The problem here is that JAXB generates one of these for every instance, so you can end up having multiple Adapter classes present, all doing the same thing. In one instance I had a single schema contain 16 duplicates of the above code. In retepXMPP I had almost 60 spread over multiple schemas just for handling JID. This is a lot of wasted, duplicated code and if you use a large number of schemas then this is going to cause both your jar sizes and permgen use to increase for no real reason.

    So it would be nice to reduce this down to a single adapter.

    Fortunately there is a way when using the JAXB RI. There is an alternate javaType binding which takes the full class name of an adapter class instead – using this causes JAXB to use that single class instead of generating these duplicate classes. The main difference is replacing the parseMethod and printMethod attributes with a single adapter attribute, and qualifying the javaType with the http://java.sun.com/xml/ns/jaxb/xjc namespace.

    So the bindings would be something like:

    <bindings
      xmlns="http://java.sun.com/xml/ns/jaxb"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
      xmlns:retep="http://retep.org/xml/ns/retepTools"
      version="2.0">
      <bindings schemalocation="jabber-client.xsd">
        <bindings node="/xsd:schema/xsd:element[@name='message']/xsd:complexType">
          <bindings node="xsd:attribute[@name='from']">
            <property>
              <baseType>
                <xjc:javaType adapter="uk.org.retep.xmpp.jaxb.adaptor.JIDAdapter"
                              name="uk.org.retep.xmpp.JID" />
              </baseType>
            </property>
          </bindings>
        </bindings>
      </bindings>
    </bindings>
    

    Then just create a single adapter implementation. in retepXMPP thats some 60 classes reduced to one, if you generate any javadocs based on the generated sources there’s no more “Adapter” spam – large numbers of apparently duplicated classes in the javadocs etc.

    Tip: Just make sure you keep an eye on that namespace – miss it out and XJC will spurt out some unusual error messages.

    Update: I’ve disabled comments on this article simply because spammers are the only ones posting comments to it. Peter 27 Feb 2010

    Releasing to Kenai via Maven

    Ever since the website feature appeared on Kenai I’ve been trying to get releases to work using it to host the maven repository. Although it works, it’s always had the odd issue where whilst uploading artifacts to the repository, the connection would timeout causing the release build to fail.

    For small projects this isn’t really a problem, but for some of mine this is an issue to either the number of artifacts present (retepXMPP currently has over a hundred) we can’t have the release build to fail part way through leaving both the mercurial and maven repositories in an inconsistent state.

    The retepMicroKernel project is further complicated by the fact that it has native code – so a release has to be performed in parts with the native code built on the respective platforms.

    Fortunately there is a solution to this – perform the release build into a staging repository then once it’s complete merge that repository with the public one. This also means we can perform a release and if something horrible goes wrong we just redo the release without the public seeing the failed release.

    Fabrizio Giudici also found this solution with an additional benefit. The maven release process makes several commits into the repository, but as mercurial is a distributed scm we can use that to our advantage – if the release build fails it doesn’t cause issues remotely with having to remove tags etc (which I’ve done before).

    So here’s what I did when releasing version 9.11 of retepTools this week, first I followed Fabrizio’s suggestions for configuring the root pom.xml file.

    Then I created a temporary directory and inside that clone the public mercurial repo then make a clone of the clone:

    # The maven staging repository
    mkdir -p ~/tmp/stagingrepo
    
    # The staging mercurial repository - this is a clone of the public repository
    cd ~/tmp
    hg clone https://hg.kenai.com/hg/reteptools~hg reteptools-stage
    
    # The release mercurial repository - this is the one we will run maven against
    # it is a clone of the staging repository
    hg clone reteptools-stage reteptools

    Now we run the release process:

    cd ~/tmp/reteptools
    mvn --batch-mode \
           -Dstaging.hg.repo.url=~/tmp/reteptools \
           -Dstaging.mvn.repo.url=file:///Users/peter/tmp/stagingrepo \
           -DreleaseVersion=9.11 \
           -DdevelopmentVersion=9.12-SNAPSHOT \
           -Dtag=retepTools-9.11 \
           release:prepare release:perform
    

    Maven will now perform the release, making commits into the ~/tmp/reteptools repository and pushing them to ~/tmp/reteptools-stage.

    Once we are happy that the release is clean we make it public. First mercurial – we need to push the changes back to kenai:

    cd ~/tmp/reteptools-stage
    hg push
    

    Next the artifacts:

    # A temporary directory for maven - it will not run without this directory
    mkdir -p tmpdir
    mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-2:merge-maven-repos \
      -Dwagon.source=file:///Users/peter/tmp/stagingrepo/ \
      -Dwagon.target=dav:https://kenai.com/website/reteptools/maven/releases/ \
      -Dwagon.targetId=retep.releases \
      -Djava.io.tmpdir=target
    

    [Edited to fix a couple of errors in the maven commands]

    Performing Maven Releases on Kenai with Hudson

    This article follows on from my previous article where I covered how to get a maven repository working on Kenai.com as they currently do not provide a maven repository and describes how to get Hudson to perform maven releases into that repository automatically.

    Configuring Hudson for releasing your project

    Maven configuration

    The first part is to prepare your project’s pom.xml defining both the scm and distributionManagement elements:

    For scm we define the url to point to the remote source repository. Unfortunately you have to put a username in here and you cannot define a connection entry:

    <scm>
            <developerConnection>scm:hg:ssh://petermount@hg.kenai.com/reteptools~hg</developerConnection>
            <url>https://kenai.com/hg/reteptools~hg</url>
        </scm>

    Next the distributionManagement element. Here we define it to point to the local copy of our repository that we created in the earlier article:

    <distributionManagement>
            <repository>
                <uniqueVersion>false</uniqueVersion>
                <id>retep.releases</id>
                <name>Retep.org repository</name>
                <url>file:/Users/peter/repository/reteptools~maven/releases</url>
            </repository>
        </distributionManagement>

    Hudson configuration

    Next for Hudson. I’m running Hudson 1.306 but this should work for earlier versions. You’ll need to install following plugins via Hudson’s plugin manager:

    Once the plugins are installed and hudson restarted you need to create the job that will perform the release:

    Under Source Code Management select Mercurial and enter the repository url on kenai.

    Next under Build enter the following for Goals and options:

    Here I define maven.repo.local to a unique one so that my local development and release repositories are separate to prevent accidentally mixing the two.

    Next we need to configure the job to manage the subversion repository. Under Build Environment check M2 Extra Build Steps and add the following two build steps:

    In Steps to run before mvn build add the following script which will update the local repository:

    cd /Users/peter/repository/reteptools~maven/releases
      svn update

    Then in Steps to run after mvn build add the following which will add the final artifacts and commit them:

    cd /Users/peter/repository/reteptools~maven/releases
      svn add * --force
      svn commit -m "Release $BUILD_TAG $BUILD_ID"

    Finally check Maven release build. The default goals and options should suffice.

    Performing an actual release

    Unless this is the first time you’ve run the job, enter your job and select Workspace followed by Wipe Out Workspace then confirm. The purpose of this step is to ensure everything is clean and hudson will perform a fresh clone from the repository.

    Next select Perform Maven Release. Check Specify release version(s) to confirm that the version numbers match what you want:

    When you are happy then select Schedule Maven Release Build.

    If all goes well then you should find that Hudson performs the release – although depending on how fast your network connection is you may want to go and make a cup of Coffee…

    Example output

    If you watch the Console Output, you should see something like the following:

    First release:prepare makes a clone and runs a build and all tests:

    Started by user peter
    $ hg clone ssh://petermount@hg.kenai.com/reteptools~hg /Users/peter/.hudson/jobs/release_retepTools/workspace
    requesting all changes
    adding changesets
    adding manifests
    adding file changes
    added 244 changesets with 1491 changes to 1013 files (+1 heads)
    updating working directory
    426 files updated, 0 files merged, 0 files removed, 0 files unresolved
    Parsing POMs
    [workspace] $ /bin/sh -xe /tmp/hudson44025.sh
    + cd /Users/peter/repository/reteptools~maven/releases
    + svn update
    At revision 7.
    [workspace] $ java -cp /Users/peter/.hudson/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.306.jar:/usr/local/apache/apache-maven-2.0.9/boot/classworlds-1.1.jar hudson.maven.agent.Main /usr/local/apache/apache-maven-2.0.9/ /Users/peter/.hudson/war/WEB-INF/lib/remoting-1.306.jar /Users/peter/.hudson/plugins/maven-plugin/WEB-INF/lib/maven-interceptor-1.306.jar 65499
    channel started
    Executing Maven:  -B -f /Users/peter/.hudson/jobs/release_retepTools/workspace/pom.xml -Dproject.dev.uk.org.retep:retepTools-generator=9.6-SNAPSHOT -Dproject.rel.uk.org.retep:retepTools-generator=9.5 -Dproject.dev.uk.org.retep.tools:retepTools=9.6-SNAPSHOT -Dproject.rel.uk.org.retep:retepTools=9.5 -Dproject.dev.uk.org.retep:retepTools=9.6-SNAPSHOT -Dproject.rel.uk.org.retep.tools:retepTools=9.5 -Dresume=false release:prepare release:perform
    [INFO] Scanning for projects...
    [INFO] Reactor build order: 
    [INFO]   retepTools
    [INFO]   retepTools Source Generator
    [INFO]   retepTools Core
    [INFO] Searching repository for plugin with prefix: ‘release’.
    [INFO] ------------------------------------------------------------------------
    [INFO] Building retepTools
    [INFO]    task-segment: [release:prepare, release:perform] (aggregator-style)
    [INFO] ------------------------------------------------------------------------
    [INFO] [release:prepare]
    [INFO] Verifying that there are no local modifications...
    [INFO] EXECUTING: hg status
    [INFO] [release.properties:unknown]
    [INFO] Checking dependencies and plugins for snapshots ...
    [INFO] Transforming ‘retepTools’...
    [INFO] Transforming ‘retepTools Source Generator’...
    [INFO] Transforming ‘retepTools Core’...
    [INFO] Updating retepTools-generator to 9.5
    [INFO] Not generating release POMs
    [INFO] Executing goals ‘clean verify’...
    [INFO] Executing: mvn clean verify --no-plugin-updates --batch-mode
    [INFO] Scanning for projects...
            [INFO] Reactor build order: 
            [INFO]   retepTools
            [INFO]   retepTools Source Generator
            [INFO]   retepTools Core
    

    next it updates the pom’s to the new release and commits them in tagging as it does so:

    [INFO] 
            [INFO] 
            [INFO] ------------------------------------------------------------------------
            [INFO] Reactor Summary:
            [INFO] ------------------------------------------------------------------------
            [INFO] retepTools ............................................ SUCCESS [2.486s]
            [INFO] retepTools Source Generator ........................... SUCCESS [4.260s]
            [INFO] retepTools Core ....................................... SUCCESS [2:47.495s]
            [INFO] ------------------------------------------------------------------------
            [INFO] ------------------------------------------------------------------------
            [INFO] BUILD SUCCESSFUL
            [INFO] ------------------------------------------------------------------------
            [INFO] Total time: 2 minutes 54 seconds
            [INFO] Finished at: Tue May 19 19:53:00 BST 2009
            [INFO] Final Memory: 37M/80M
            [INFO] ------------------------------------------------------------------------
            [INFO] Checking in modified POMs...
    [INFO] EXECUTING: hg commit --message “[maven-release-plugin] prepare release retepTools-9.5” /Users/peter/.hudson/jobs/release_retepTools/workspace/pom.xml /Users/peter/.hudson/jobs/release_retepTools/workspace/generator/pom.xml /Users/peter/.hudson/jobs/release_retepTools/workspace/core/pom.xml
    [INFO] EXECUTING: hg push ssh://petermount@hg.kenai.com/reteptools~hg
    [INFO] Tagging release with the label retepTools-9.5...
    [INFO] EXECUTING: hg tag --message “[maven-release-plugin]  copy for tag retepTools-9.5” retepTools-9.5
    [INFO] EXECUTING: hg push ssh://petermount@hg.kenai.com/reteptools~hg
    [INFO] EXECUTING: hg locate
    [INFO] Transforming ‘retepTools’...
    [INFO] Transforming ‘retepTools Source Generator’...
    [INFO] Transforming ‘retepTools Core’...
    [INFO] Updating retepTools-generator to 9.6-SNAPSHOT
    [INFO] Not removing release POMs
    [INFO] Checking in modified POMs...
    [INFO] EXECUTING: hg commit --message “[maven-release-plugin] prepare for next development iteration” /Users/peter/.hudson/jobs/release_retepTools/workspace/pom.xml /Users/peter/.hudson/jobs/release_retepTools/workspace/generator/pom.xml /Users/peter/.hudson/jobs/release_retepTools/workspace/core/pom.xml
    [INFO] EXECUTING: hg push ssh://petermount@hg.kenai.com/reteptools~hg
    [INFO] Release preparation complete.
    

    Then it starts release:perform. Here it makes a fresh clone but this time for the newly created tag and compiles it again:

    [INFO] [release:perform]
    [INFO] Checking out the project to perform the release ...
    [INFO] Removing /Users/peter/.hudson/jobs/release_retepTools/workspace/target/checkout
    [INFO] EXECUTING: hg clone -r retepTools-9.5 ssh://petermount@hg.kenai.com/reteptools~hg /Users/peter/.hudson/jobs/release_retepTools/workspace/target/checkout
    [INFO] EXECUTING: hg locate
    
    ...
    
            [INFO] Uploading project information for retepTools 9.5
            [INFO] Retrieving previous metadata from retep.releases
            [INFO] Uploading repository metadata for: 'artifact uk.org.retep:retepTools'
            Uploading: file:/Users/peter/repository/reteptools~maven/releases/uk/org/retep/retepTools/9.5/retepTools-9.5-sources.jar
            783K uploaded
            Uploading: file:/Users/peter/repository/reteptools~maven/releases/uk/org/retep/retepTools/9.5/retepTools-9.5-javadoc.jar
            2383K uploaded
            [INFO] 
            [INFO] 
            [INFO] ------------------------------------------------------------------------
            [INFO] Reactor Summary:
            [INFO] ------------------------------------------------------------------------
            [INFO] retepTools ............................................ SUCCESS [4.546s]
            [INFO] retepTools Source Generator ........................... SUCCESS [5.987s]
            [INFO] retepTools Core ....................................... SUCCESS [2:47.913s]
            [INFO] ------------------------------------------------------------------------
            [INFO] ------------------------------------------------------------------------
            [INFO] BUILD SUCCESSFUL
            [INFO] ------------------------------------------------------------------------
            [INFO] Total time: 2 minutes 58 seconds
            [INFO] Finished at: Tue May 19 19:58:10 BST 2009
            [INFO] Final Memory: 40M/80M
            [INFO] ------------------------------------------------------------------------
            [INFO] Cleaning up after release...
    [HUDSON] Archiving /Users/peter/.hudson/jobs/release_retepTools/workspace/pom.xml to /Users/peter/.hudson/jobs/release_retepTools/modules/uk.org.retep.tools$retepTools/builds/2009-05-19_19-50-00/archive/uk.org.retep.tools/retepTools/9.5-SNAPSHOT/pom.xml
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESSFUL
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 8 minutes 9 seconds
    [INFO] Finished at: Tue May 19 19:58:10 BST 2009
    [INFO] Final Memory: 11M/27M
    [INFO] ------------------------------------------------------------------------
    channel stopped
    

    finally it adds and commits the new artifacts into subversion. Once this step completes your release is publicly available.

    [workspace] $ /bin/sh -xe /tmp/hudson44036.sh
    + cd /Users/peter/repository/reteptools~maven/releases
    + svn add uk --force
    A         uk/org/retep/maven-metadata.xml
    A         uk/org/retep/maven-metadata.xml.md5
    A         uk/org/retep/maven-metadata.xml.sha1
    A         uk/org/retep/retepTools/9.5
    A  (bin)  uk/org/retep/retepTools/9.5/retepTools-9.5-javadoc.jar
    A         uk/org/retep/retepTools/9.5/retepTools-9.5-javadoc.jar.md5
    A         uk/org/retep/retepTools/9.5/retepTools-9.5-javadoc.jar.sha1
    A  (bin)  uk/org/retep/retepTools/9.5/retepTools-9.5-sources.jar
    A         uk/org/retep/retepTools/9.5/retepTools-9.5-sources.jar.md5
    A         uk/org/retep/retepTools/9.5/retepTools-9.5-sources.jar.sha1
    A  (bin)  uk/org/retep/retepTools/9.5/retepTools-9.5.jar
    A         uk/org/retep/retepTools/9.5/retepTools-9.5.jar.md5
    A         uk/org/retep/retepTools/9.5/retepTools-9.5.jar.sha1
    A         uk/org/retep/retepTools/9.5/retepTools-9.5.pom
    A         uk/org/retep/retepTools/9.5/retepTools-9.5.pom.md5
    A         uk/org/retep/retepTools/9.5/retepTools-9.5.pom.sha1
    ...
    + svn commit -m 'Release hudson-release_retepTools-15 2009-05-19_19-47-45'
    Adding         releases/uk/org/retep/maven-metadata.xml
    Adding         releases/uk/org/retep/maven-metadata.xml.md5
    Adding         releases/uk/org/retep/maven-metadata.xml.sha1
    Adding         releases/uk/org/retep/retepTools/9.5
    Adding  (bin)  releases/uk/org/retep/retepTools/9.5/retepTools-9.5-javadoc.jar
    Adding         releases/uk/org/retep/retepTools/9.5/retepTools-9.5-javadoc.jar.md5
    Adding         releases/uk/org/retep/retepTools/9.5/retepTools-9.5-javadoc.jar.sha1
    Adding  (bin)  releases/uk/org/retep/retepTools/9.5/retepTools-9.5-sources.jar
    Adding         releases/uk/org/retep/retepTools/9.5/retepTools-9.5-sources.jar.md5
    Adding         releases/uk/org/retep/retepTools/9.5/retepTools-9.5-sources.jar.sha1
    Adding  (bin)  releases/uk/org/retep/retepTools/9.5/retepTools-9.5.jar
    Adding         releases/uk/org/retep/retepTools/9.5/retepTools-9.5.jar.md5
    Adding         releases/uk/org/retep/retepTools/9.5/retepTools-9.5.jar.sha1
    Adding         releases/uk/org/retep/retepTools/9.5/retepTools-9.5.pom
    Adding         releases/uk/org/retep/retepTools/9.5/retepTools-9.5.pom.md5
    Adding         releases/uk/org/retep/retepTools/9.5/retepTools-9.5.pom.sha1
    Sending        releases/uk/org/retep/retepTools/maven-metadata.xml
    Sending        releases/uk/org/retep/retepTools/maven-metadata.xml.md5
    Sending        releases/uk/org/retep/retepTools/maven-metadata.xml.sha1
    ...
    Adding         releases/uk/org/retep/tools/retepTools/maven-metadata.xml
    Adding         releases/uk/org/retep/tools/retepTools/maven-metadata.xml.md5
    Adding         releases/uk/org/retep/tools/retepTools/maven-metadata.xml.sha1
    Transmitting file data .......................................
    Committed revision 8.
    Finished: SUCCESS
    

    That’s it, the release process is now fully automated and can be repeated with a couple of clicks.