I’m pleased to announce that we at the Apache Maven project have released Maven 2.2.0. You should definitely give it a spin! Maven 2.1.0 was probably the most stable release we’ve ever done, in terms of the number of reported regressions. Maven 2.2.0 improves on this stability by fixing the few critical bugs that did come up, along with adding some new functionality. You can grab the new version here.
This release includes some important bugfixes and other improvements, including:
Removed feature from 2.1.0 that resolved expressions in version elements within the POM on installation and deployment.
This code was causing inconsistencies between the POM that landed in the repository and artifacts that are derived from that POM. The most prominent example deals with the GPG plugin: since the POM was modified on deployment, the GPG signature generated during the build was useless. This by itself effectively made Maven 2.1.0 unusable for releases.
Switched to a HttpClient-based wagon implementation for reaching HTTP repositories.
This is crucial for people sending long passwords, since the HttpUrlConnection-driven wagon did not-nice things with BASIC authentication headers when the password was very long…it line-wrapped the Base-64 header value, rendering the HTTP request invalid. In addition, HttpClient offers a wide range of options for configuration over HttpUrlConnection.
New default execution IDs for goals bound from the default lifecycle mapping and those invoked from the command line.
Previously, the only way to configure plugins that were used from the command line was to put the configuration options into the plugin-level configuration. This meant that it was impossible to separate CLI-oriented configuration settings from those used in goals that were bound to the lifecycle. Now, you can simply use an execution block with an id of
default-cli to compartmentalize CLI-specific options.
Likewise, Maven 2.1.0 forces users to add configuration at the plugin level for any goals bound to the build via default lifecycle mapping. This could be particularly troublesome when you had multiple goals from a single plugin bound in via lifecycle mapping, and needed to respecify the same configuration option differently for the different goals. For instance, using different includes or excludes between the
compiler:testCompile goal executions was basically impossible. In Maven 2.2.0, you can use executions with the new per-goal default execution-Ids. For the compiler example, you can use
default-testCompile, respectively, to separate configurations for these two default goal executions.
Java 1.5+ is now a requirement.
Maven 2.2.0 upgrades the Java requirement to 1.5 or later. This allows us to finally start making the migration onto the Java5 generics syntax, and other nice little perks that come with a less archaic version of Java.
For the full list of updates, see the Release Notes.