Wednesday, January 5, 2011

Publishing your signed OSS project to the Sonatype OSS repository

One thing I wanted to do was to publish the yui-runner releases to ibiblio. It's now pretty easy thanks to the Sonatype OSS repository, which will help you stage and release your repositories.

See the official Sonatype OSS Maven Repository guide.

Because of a few choices (git, scala), I ran into a few troubles or quirks that are worth noting though. Here's the outline of the procedure I picked up:

  • clean up your POM as per the documentation
  • no need yet to add sections for javadoc, pgp, release etc. They are by default included once the parent is inherited from. If you wish to test javadoc or pgp, you should then enable the sonatype-oss-release profile to your maven execution when needed.
  • if you do add the javadoc attach-sources goal, you might ran into problems that causes the reactor to not find the project's own internal dependencies. This is because I think that particular goal forks maven. See https://github.com/lacostej/yui-runner/commit/7f15baa5a73c0da773a283800521a12d8c20a905
  • you might want to configure the git push off by default (http://jira.codehaus.org/browse/SCM-444). This I think fits well with the staging principle of the Sonatype OSS repo. Use something like:

    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.1</version>
    <configuration>
    <pushChanges>false</pushChanges>
    </configuration>
    </plugin>

  • during release, you might want to add the use of the gpg agent if you don't like to enter your GPG passphrase for every module

    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-gpg-plugin</artifactId>
    <version>1.1</version>
    <configuration>
    <useAgent>true</useAgent>
    </configuration>
    </plugin>

  • the Sonatype OSS repository expects releases to have a javadoc artifact. As the maven-scala-plugin doesn't yet behave like the maven-javadoc-plugin, and doesn't produce nor attach a javadoc artifact to your build, I cheated a bit. This is of course temporary.

  • Deploying will require the use of GPG signatures. This is what i did on Ubuntu 10.10 to get it working as I wanted (with a gpg-agent):

    1. create a signing key:

      jerome@lenovo-w510:~ $ gpg --gen-key
      jerome@lenovo-w510:~ $ gpg --list-keys
      jerome@lenovo-w510:~ $ gpg --keyserver pgp.mit.edu --send-key 576831db3ae26aaf

    2. install the agent:

      root@lenovo-w510:~ # apt-get install gnupg-agent

    3. configure the gpg-agent. Under ~/.gnupg/gpg-agent.conf, write

      pinentry-program /usr/bin/pinentry-gtk-2
      default-cache-ttl 86400
      max-cache-ttl 86400


    4. start the agent and copy the output in the terminal (this can be moved to your DE session startup instead later on)

      jerome@lenovo-w510:~ $ gpg-agent --daemon
      GPG_AGENT_INFO=/tmp/gpg-t61OEn/S.gpg-agent:28820:1; export GPG_AGENT_INFO;
      jerome@lenovo-w510:~ $ GPG_AGENT_INFO=/tmp/gpg-t61OEn/S.gpg-agent:28820:1; export GPG_AGENT_INFO;


  • Now the release takes the form of:

    1. clean your directory (git status, git ignore, etc)
    2. mvn release:clean (optional)
    3. mvn release:prepare
    4. git push --tags && git push (if you disabled push)
    5. mvn release:perform
    6. follow the Sonatype doc for testing your staging repo and releasing it. If you run into problems, don't forget to drop your repo before releasing again.

No comments:

Post a Comment