Automatically Resolving Version Conflicts in Maven POMs When Merging

I’ve recently had a regular task of releasing projects from multiple branches, and then merging branches together. Handling this and any conflicts hasn’t been a big hassle when it is regularly updated, with one notable exception – Maven POM files. When they are merged the version changes on both branches always conflict.

There are ways I’ve got around it to date:

• Subversion’s --accept mine-conflict and similar options can help resolve them quickly if you know ahead of time they are the only conflicts, without additional changes
• If ending up with versions from the wrong branch, follow up with mvn versions:set -DnewVersion=... versions:commit
• Sometimes the right merge tool or IDE will select the right one, or at least make it less repetitive to select the right one for each file

However, I was finding that in projects with a large number of POMs and occasional other conflicts, these were all a little too tedious. I’ve whipped up a basic script that can be used to eliminate the POM-based conflicts first, so that the remaining conflicts are only those you really need to deal with: Automatically resolve conflicts in Maven POMs after a merge — Gist. It doesn’t handle a lot of edge cases, but should work well enough for most uses.

This works pretty well with Git, and can be used with Subversion (if you automatically postpone all the resolve steps with --accept, or use a non-CLI tool to merge).

This is not something I’d want in a standard release/branch workflow – the problem could be avoided by different branching practices so that release commits are not merged. However if someone finds it useful, I’m sure they can improve on the Gist above, or perhaps patch the Maven SCM or Versions plugins to provide the capability more directly.

Apache Maven Training in Vancouver – 1 week left to register

ApacheCon is in Vancouver this year, and now just 1 month away (Nov 7-11). There is still one week left to register for the training sessions, and to qualify for the early bird rate on the conference.

As in previous years, I’ll be offering an up-to-date version of the training course, Apache Maven: Effective Implementation:

This training course is designed to go beyond your current assumptions about Apache Maven and learn how to use it most effectively to manage the build and development process. Whether you are a novice aiming to start on the right foot, or a regular user looking to get more out of Maven and avoid common frustrations, this course will give you the skills you need to apply to your own projects. By working through a series of short exercises applied to a complete sample application, you will learn how to apply common patterns in Maven builds to achieve the desired outcome, while learning best practices and common pitfalls along the way. Topics include installation, Maven fundamentals, working efficiently with multi-module projects, simplifying the POM, the best general purpose plugins that you should know about, integration and functional testing, when (and when not) to use Maven sites and reporting, the role of profiles, snapshots and dependency management, repository management, and performing releases. The content is updated for the latest improvements in Maven 2.2 and Maven 3, and will cater to your preference of development environment. Time is reserved for sharing specific situations that attendees have encountered in existing projects.

The course runs for a full day on Tuesday, 8 November. If you’re planning to attend the training or the conference, you can connect to me on the conference website.

Apache Archiva 1.3.3 released: performance improvements!

If you’re using Archiva for your repository management needs, you should definitely upgrade to the latest release. Download it now!

The 1.3.x series has focused on the biggest offenders in memory usage and performance problems, and Archiva 1.3.3 brings the biggest improvements yet:

• Full scans should take about 1/3rd of the time and consume far less memory
• Removed one-off memory hits at the end of a scan
• File descriptor use during concurrent deployments are better managed

In addition, a new system status page is available for assessing the cause of potential performance issues at runtime, giving better insight into how to tune memory or scanning settings appropriately.

This work is in advance of the upcoming Archiva 1.4 release which has revived the internals more significantly, with further performance improvements and a series of new features.

It’s also worth noting that we dropped support for Archiva 1.1.x and Archiva 1.2.x in November, so there’s no reason left to remain on older versions.

I’d like to thank YourKit, who provided a free license for their profiler, which was of great assistance in tracking down these issues. I’ve used it on occasion for a number of years, and it is one of the easiest tools to use that I’ve ever encountered.

The full set of issues resolved follow:

• [MRM-1097] – Error 500 "too many open files"
• [MRM-1369] – Editing user roles in archiva clobbers continuum redback roles
• [MRM-1396] – Purge task problem : Not enough parts to the path
• [MRM-1421] – Archiva repository purge incorrectly purges based on file timestamps even when the snapshot timestamp is known
• [MRM-1443] – repository statistics collection can cause server to hang
• [MRM-1416] – upgrade to Redback 1.2.5
• [MRM-1439] – improve indexing performance
• [MRM-1440] – system status page
• [MRM-1441] – monitor repository scanning progress
• [MRM-1442] – track time spent in each consumer during a scan, to help diagnose poor scanning performance
• [MRM-1445] – disable referrer check by default

BarCamp Apache Sydney is this Saturday!

Great news – we seem to be getting quite a few last minute registrations for the BarCamp. There’s still time to sign up, or invite a colleague, if you’re coming along!

Here’s the details in a nutshell…

BarCamp

Date: Saturday, 11th December
Time: Registration is at 9:30am, for a 10am start.
Venue: The Darlington Centre, University of Sydney, at 174 City Road, Darlington
Cost: free
Food: coffee, snacks and lunch provided by the sponsors
Other: free wifi available
Sign up and details: http://barcamp.org/BarCampApacheSydney

Pre-BarCamp Dinner and Drinks

Date: Friday, 10th December
Time: Meeting at 7:30pm, reservation is for 8:30pm
Venue: Sumalee Thai, in The Bank Hotel, Newtown
Cost: $30pp for a variety of dishes, includes a vegetarian option
Sign up: indicate it on the wiki or the barcamp-sydney Google group

See you there!

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),