Using a GPG agent for signing Maven releases on Mac OS X

Using the Maven GPG Plugin makes it easy to sign a large number of artifacts when performing a release with Maven.

However, one of the annoying parts is that interactive password entry is not particularly easy, and you often have to put it on the command line or into your settings file in plaintext, which is not very comfortable. The better alternative is to use gpg-agent, and if you’re not using GPG 2.0 this needs to be configured in the POM:

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

GPG will fallback to the same password entry if it is not running or if it is provided via the property, so there’s no particular downside to enabling the option.

The problem on Mac is that the situation with GPG is a little confusing. There seem to be several different projects floating around to provide it.

I’m a big fan of Homebrew, and previously I’d been using that to install GnuPG and gpg-agent. It worked quite well, but the password entry required curses, and also didn’t work in an interactive session – so you’d need to make sure to have entered it manually before starting a release. If it failed mid-release, you’d need to restart the agent. None of this was Homebrew’s fault – I just hadn’t been able to find a native pinentry app for the Mac that stood alone and didn’t crash on use.

After fiddling with it for a while, I decided to try one of the native Mac GPG installers again. This is where it got confusing, since there are several efforts floating around. Others may work, but the one I had success with is the revived GPGMail project. After uninstalling all the packages using Homebrew, I installed GPGTools from the download page. Since this includes a native pinentry application, and pre-configures gpg and the agent to run once on login, it worked much better.

The only catch if you’re trying this is that you need to logout, or in your shell run this until you have:

open /usr/local/libexec/start-gpg-agent.app/
. ~/.gpg-agent-info
export GPG_AGENT_INFO

You can test that it is working outside of Maven by running: gpg -ab (ending with Ctrl-D),

Maven Release Plugin awaits your testing

Somewhat dwarfed by Benjamin sneaking in the Maven 3.0 release vote 15 minutes later, the Maven Release Plugin 2.1 is currently being voted on.

It includes a handful of changes, most notably MRELEASE-530 to work better with Git.

The release plugin has a history of being a bit fickle across releases, so if you’re using the latest version, please try it out!

The biggest task ahead for the plugin is a thorough cleansing of the JIRA project. Even a cursory glance shows a significant number of duplicate, outdated, or out of scope issues. Hopefully that is something to revisit beyond ApacheCon next month.

Updated Multi-module Support for Maven Release Plugin

Last week Dennis started things moving to have another release of the Maven Release Plugin. The release process should start very soon, so please join us on dev@maven.apache.org to help test it!

This is certainly a nice one to have out the door, not only because of the length of time since the last release but because it fixes some important bugs (Subversion 1.6 support for starters), and improves multi-module support.

Having been bitten by the latter category myself very recently I took the opportunity to get a couple of changes in.

Support for flat directory multi-module projects

This highly requested support was actually added by Deng way back in May last year, but it was only recently that I started using the new version of the plugin and discovered a small corner case I jumped in and made a couple of improvements and fixes.

While I would always recommend using a typical hierarchical Maven multi-module project, there are a number of existing projects using the flat structure, particularly in non-Java environments. It’s good that the release plugin can now support anything with a common trunk.

This means that projects like the following will now release correctly (run from the parent directory):

.
|-- release-parent
|   `-- pom.xml
|-- release-module2
|   `-- pom.xml
`-- release-module1
    `-- pom.xml

Not requiring artifacts to be in the local repository before releasing

This controversial issue has popped up a number of times and proven to be a real nuisance in releases, where a multi-module project needed to be built locally before it can be released (including the preparation test, that makes 3 full builds!), or at best spouted a large number of warnings about missing dependencies on the artifacts it was yet to build.

In the end here we decided to revert to the original behaviour and accept the limitations that came with, while making the typical release faster and easier. The release:prepare-with-pom goal has been added to cater to the use case for which the dependency resolution was put in place originally. With this intended to be the 2.0 release of the plugin, we can stick to this behaviour going forward.

In the future, Maven 3.0 has added additional capabilities for plugins to operate with their modules without building them first, which will allow a unified and enhanced release:prepare goal once more, but in the mean time we’ve opted to put in place the best solution for the majority of Maven users today.