The Maven 3: The Future of Enterprise Java Build Infrastructure presentation is now available for viewing. This presentation was given at EclipseCon 2011 by Sonatype founder Jason van Zyl.

More on this presentation:

Maven 3 is the best version of Maven yet. Maven 3 is faster, has been optimized for IDE use, and is fully backward compatible with Maven 2. One of the big focuses of Maven 3 is to provide a more reliable, more stable and better performing build tool. Faster Maven builds lead to higher developer productivity in your organization.

Watch the video below:

Sonatype has released the latest version of our industry leading repository manager – Nexus 1.9.1

This post outlines some of the new features available in all 1.9 releases of both Nexus Professional and Nexus Open Source. This release has a lot of important, under-the-hood changes – including a number of changes to the core infrastructure of Nexus to increase Maven 3 compatibility and to incorporate open source libraries for repository interaction (Aether and Maven Indexer). In addition to a wide array of fixes and features in Nexus Open Source, you can now use Nexus Professional to analyze Maven Dependencies.

• Download Nexus Professional 1.9.1
• Download Nexus Open Source 1.9.1

Changes in Nexus Professional 1.9.1

Nexus Professional has the following key benefits.  For a complete list of all features added and bugs fixed in Nexus Professional 1.9.1, see the official release notes (note: release notes require a log-in).

• Moved the Custom Metadata Plugin to optional plugins – This Custom Metadata plugin is now shipped as an optional dependency. If you are using the Custom Metadata plugin you will need to copy this plugin from the optional dependencies directory to the plugins directory. Nexus will then start up this plugin the next time it is restarted.
• The New Maven Module Dependency Report – Nexus Professional adds a helpful report for people browsing the repository. For the first time, you can click on an artifact and see a report of Maven dependencies. From this report you can click through to search for dependencies.

Changes in Nexus Open Source

Nexus Open Source 1.9.1 contains the following new features and updated capabilities. We’ve summarized some of the major features and bug fixes for your convenience. If you are looking for more details about a particular feature or fix, read the full release notes for a comprehensive list of features added and bugs fixed.

• New Nexus Archetype Plugin - Nexus 1.9.1 will now add any Maven Archetypes you deploy to your own repositories to the archetype catalog. Once an archetype is available in the archetype catalog, you can then access archetypes using tools like m2eclipse, which reference the archetype catalog when creating a new project.
• Uses the Maven Indexer - Sonatype has successfully completed the donation of the Nexus Indexer to the Apache Software Foundation, and we are integrating this newly donated “Maven Indexer” in this release of Nexus. For more information, read this post.
• Improvements to the Roles and Permissions Interface - The Nexus team spend a considerable amount of time trying to simplify the Roles and Permissions interface based on user feedback. We’ve tried to make it easier to understand at first glance, and we’re also tried to reduce the amount of work necessary to make changes to roles and permissions.
• Integrated Aether - Aether is a new open source library designed to capture best practices for retrieving information from Maven repositories. It provides a clean interface and manages fetching both metadata and artifacts. This version of Nexus incorporates Aether and replaces Mercury. Integrating Aether has also solved a number of minor issues involving Maven metadata and compatibility with Maven 3.
• Switched to Java 6 - Nexus has upgraded to Java 6.
• Nexus Upgraded Security from JSecurity to Apache Shiro - As an end-user you shouldn’t notice many changes in the interface to support this migration, but if you are developing custom security realms for Nexus, this post describes some of the changes you need to make to support the move to Shiro. Note: After this upgrade, both first name and last name are required fields for a user. If you have an existing user that only have one name (“Administrator”), you will need to supply a first and last name for this user if you ever edit this user through Nexus UI.
• Added robots.txt to bundle to stop public repos from getting crawled
• Improved Reindexing Performance - Reindexing performance has been considerably improved, achieving a nearly 2x speed up for certain repositories.
• Switched to the Affero General Public License - Nexus Open Source is now covered under the Affero General Public License. For more information about this switch see this post.
• Added a Start-up Script for 64-bit windows Platforms – If you are running Nexus on a 64-bit Window platform, you can now start Nexus with a 64-bit Windows JSW startup wrapper.

For information on upgrading Nexus, click here.

In Maven 3.0.3, we introduced some improvements to the way plugin goals can be configured. This post summarizes these improvements and gives some examples of how Maven plugin configuration has been enhanced. We’ve focused on making improvements that will reduce the friction of plugin configuration for both plugin developers and Maven end-users.

First, a general tip for users interested in using these enhancements in POMs: use the requireMavenVersion rule from the Maven Enforcer Plugin and required Maven version 3.0.3.  This will save other team members from running into strange build failures due to plugin misconfiguration if they are still using previous Maven versions.   Likewise, plugin authors that take advantage of these enhancements should properly declare the Maven prerequisite in the plugin POM.

Generic collections

The plugin configurator can now employ the generic type argument of a collection parameter to determine the type of the elements. In practice this means plugins can use collections as input parameters more freely without having to worry about the user being forced to specify the proper element type in the POM.

For instance, the goal parameter:

/** @parameter */
java.util.List<java.io.File> files;

can be configured like this in the new Maven version:

<files>
  <!-- Maven 3.0.3 can take care of converting this to a java.io.File instance -->

  <file>pom.xml</file>

  <!-- The previously required implementation attribute is now superfluous but still works -->
  <file implementation="java.io.File">build.xml</file>
</files>

Instead of having to specify the type of each element, Maven 3.0.3 will now automatically convert the first element in the previous example to an object of type “java.io.File”.

In absence of the implementation attribute, Maven usually looks for a class named <goalPackage>.<xmlElement> to determine the element type. The recognition of generics now enables plugin authors to use bean classes for collection elements that reside in a different package than the plugin goals.   In summary, collections now provide the same ease of configuration as classical arrays.

Automatic conversion of arrays to collections, and vice versa

Continuing in the spirit of the previous improvement, the new plugin configurator will now automatically convert a collection obtained from a parameter expression to an array if that’s the type expected by the plugin parameter. Likewise, an array would be converted to a collection if needed. The bottom line is that plugin authors targeting recent Maven versions can freely decide to use an array or a collection for a plugin parameter regardless of whether its default value actually yields a collection or array:

/** @parameter default-value="${project.compileSourceRoots}" */
List<String> sourceRootsAsCollection;

/** @parameter default-value="${project.compileSourceRoots}" */
String[] sourceRootsAsArray;

Before this change was made to the configurator plugin developers and Maven users had to be very careful about passing an array to a method that expected a List or vice versa. While this might seem like a minor change, it is one of many that will make plugin development easier.

Configuration of collection/array via system property

For many plugin parameters it is occasionally convenient to specify their values from the command line via system properties. In the past, this was limited to parameters of simple types like String or Boolean. The latest Maven release finally allows plugin users to configure collections or arrays from the command line via comma-separated strings. Take for example a plugin parameter like this:

/** @parameter expression="${includes}" */
String[] includes;

This can be configured from the command line as follows:

mvn <goal> -Dincludes=*Foo,Bar*

Plugin authors that wish to enable CLI-based configuration of arrays/collections just need to add the expression tag to their parameter annotation. Note that if compatibility with older Maven versions is to be kept, the parameter type must not be an interface but a concrete collection class or an array to avoid another shortcoming in the old configurator.

Inlined collections

Many users complain that Maven POMs make heavy use of container elements for collections. Instead of just listing a series of dependency elements, you have to wrap all of your dependency elements in a dependencies element. The same is true for includes and excludes and other elements throughout the POM.  This extra redundancy often adds up to some very large POMs. In Maven 3.0.3, we’ve made a change to the plugin API that will support plugin configuration without requiring container elements for collections.  Here is an example:

<fileset>
  <directory>src/demo</directory>
  <include>Foo*</include>
  <include>Bar*</include>
  <exclude>*Bad</exclude>
</fileset>

Previously, Maven would only look for a field or setter when processing the <include> elements. Now it also looks for an adder. So to support the above configuration, a plugin author would need to implement the configured bean like this:

public class Fileset
{

    private List<String> includes = new ArrayList<String>();

    public void addInclude( String include )
    {
        includes.add( include );
    }

    ...
}

The adder needs to be named add<xmlElement>() and must be public, non-static and have a single argument; it may have a return value. In case where multiple such adders with the same name exists, it is undefined which one gets actually called so be sure to avoid overloading the adder.

Given that merging of plugin configuration during POM inheritance or profile injection is purely based on the XML structure and not guided by information about the actual data types, users that employ this compacted configuration are well-advised to not mix it with the usual collection-style configuration format for a given plugin parameter as the merged configuration likely doesn’t produce the intended result.

Bean default properties

We can take the idea of inlining configuration a little further. Have a look at this example configuration:

<resources>
  <resource>
    <directory>src/foo</directory>
    <filtering>true</filtering>
  </resource>
  <resource>src/bar</resource>
</resources>

Looks odd at first, doesn’t it? Obviously, the <resource> element describes some complex structure, but the second <resource> element in the example consists just of a mere string. It’s not hard to guess that<resource>src/bar</resource> could be a shorthand form of <resource><directory>src/bar</directory></resource> by assuming the <directory> element is the default/primary property of a <resource>. With the new plugin configurator, this is actually possible now.

To enable the feature, a plugin author would have to add a method called set() to the bean class in question:

public class Resource
{

    private File directory;

    public void set( File directory )
    {
        this.directory = directory;
    }

...
}

This set() method must be public, non-static and take a single argument; it may have a return value.

Besides saving users a few bits of XML, this feature can also be used to configure complex beans via system properties from the command line. Let’s say we have a plugin parameter like this:

/** @parameter expression="${artifact}" */
Artifact artifact;

Now further assuming the Artifact bean used here implements a nice set() method that is smart enough to parse a string into artifact coordinates, one could invoke the plugin directly via:

mvn <goal> -Dartifact=org.apache.maven:maven-core:3.0

Last but not least, the default property feature also enables a smooth upgrade path in case plugin parameters need to be changed from simple values to complex structures. Going back to the initial example with the <resource>elements, consider the plugin author originally didn’t anticipate the <filtering> element and designed the plugin parameter to be of type File[].

With previous Maven versions, the only way to extend the plugin to support the<filtering> element is to deprecate the existing <resources> parameter and introduce a new parameter using the complex type or alternatively just break compatibility with existing POMs that use the old plugin version. Using the default property support, a plugin can change the parameter type from File[] to Resource[] without affecting existing users.

Simpler configuration of properties parameter

While java.util.Properties is just a concrete implementation of a Map, the configuration required for parameters of type Properties is structurally different from the configuration format for Map parameters. For the sake of consistency and conciseness, plugin parameters of type Properties can now also be configured like a Map, that is:

<properties>
  <key1>value1</key1>
  <key2>value2</key2>
</properties>

User-specified implementation class for map parameters

Previous Maven versions always used a TreeMap to configure parameters of type Map. In other words, neither the user nor the plugin author had any control over the map implementation being used. Just like with the collections, the updated plugin configurator recognizes an optional implementation attribute:

<map implementation="java.util.LinkedHashMap">
  <key>value</key>
</map>

In absence of both the attribute and a concrete implementation class in the parameter declaration, TreeMap continues to get used.

Hexadecimal and octal numbers

In some contexts, it’s more convenient to specify a number in hexadecimal or octal notation. To support this, plugin authors previously had to declare the corresponding plugin parameters as strings and do the conversion themselves. Now, it’s natively supported, using the prefix “0x” to denote hex notation and the prefix “0″ to denote octal notation.

<rgb>0xFF00C0</rgb> <!-- hex number -->
<perms>0664</perms> <!-- octal number -->

If you missed Sonatype’s latest webinar on Maven 3.x: The Evolution of Enterprise Java Build Infrastructures, download the webinar recording here.

Maven 3 is the best version of Maven yet. Maven 3 is faster, has been optimized for IDE use, and is fully backward compatible with Maven 2.  In this webinar, Jason van Zyl discusses Maven 3, the future of Java Build Infrastructures and the upcoming Sonatype Professional suite.

For more from Sonatype including upcoming product releases, training sessions and webinars visit www.sonatype.com.

Sonatype will be hosting a free webinar on Maven 3 next week.  Maven 3 is the best version of Maven yet. Maven 3 is faster, has been optimized for IDE use, and is fully backward compatible with Maven 2. Please join us as Jason van Zyl discusses Maven 3, the future of Java Build Infrastructures.

Click here to register for this webinar.

Date: Thursday, October 28, 2010 Time:

• 6:00 am Pacific Daylight Time (San Francisco, GMT-07:00)
• 9:00 am Eastern Daylight Time (New York, GMT-04:00)
• 2:00 pm Western European Summer Time (London, GMT+01:00)
• 3:00 pm Europe Summer Time (Amsterdam, GMT+02:00)

Estimated duration: 45 minutes

Another step towards a final release of Maven 3.0 was made the other day when version 3.0-beta-2 was released. I’ve been using Maven 3 since its alpha days, and despite the alpha/beta moniker, I find it to be superior to any Maven 2.x version. If you are starting a new project, I strongly recommend using Maven 3.

That being said, in the complete development environment there are a few missing pieces when working with Maven 3. One of these is getting Sonar to work with Maven 3, which had not been possible until the latest version of Sonar was released.

This post will explain how to get Maven 3 and Sonar to work together.

To get started, the first thing you must do is install Sonar 2.2 and Maven 3.0-beta-1 or later. No extra configuration of Sonar is required for Maven 3, and the same configuration of properties in Maven also applies. Please note that the URL for the Sonar server — sonar.host.url — must not end with a slash character.

The difference when using Maven 3 lies in the Maven plugin. Currently, the plugin at Codehaus Mojo doesn’t work with Maven 3, so you need to use the one at the Sonar project instead.

Now, in your Maven project, execute the command below.  Until the Sonar Maven plugin at Codehaus Mojo is updated with Maven 3 support, this is the command to use:

mvn org.codehaus.sonar:sonar-maven3-plugin:2.2:sonar

Your project should now be analyzed and the result uploaded to Sonar.

One thing to be aware of is that you need to align the version of sonar-maven3-plugin with the version of Sonar that is installed. When you upgrade Sonar, you need to change the version on the Maven side as well.

To view the progress of Maven 3 support in the plugin at Codehaus Mojo, follow MOJO-1545.

Craig Tataryn of BasementCoders.com interviewed Brian Fox about the upcoming release of Maven 3. From Basementcoders.com:

“With the Maven 3 betas being out and packing a tonne of cool features we decided that we needed to sit down and talk with someone in the know. Enter Brian Fox, PMC Chair Apache Maven and VP of Engineering at Sonatype (the fellows who make Maven Repositories manageable via their Nexus product).”

This interview touches upon Brian’s background in build management and developer infrastructure, and how Brian started to use Maven and became involved in the Apache Maven project. You will also hear Brian discuss the history of Maven, the motivations behind the project, some comparisons between Maven and Ant, and new features planned for the Maven 3 release.

To listen to the full interview, click here.

JAXenter talked to Sonatype’s Jason van Zyl about the future of Maven, and what users can expect when migrating from Maven 2 to Maven 3.  In this interview, van Zyl and Sonatype’s Brian Fox outline Maven 3, it’s backward compatibility with Maven 2, the introduction of POM mixins, and repository management with Nexus.

The primary goal is a way forward for all Maven users, efficient embedding, increased performance, synchronizing the Maven 3.0 code base with m2eclipse, and adding extension points for tools like Tycho, Polyglot Maven, and the Maven Shell.

To read the full JAXenter interview, click here.

Devnexus 2010 is the annual Professional Developer Conference, and is being held in Atlanta on March 8 and 9.  Sonatype’s Jason van Zyl will be in Atlanta on March 8 to give a presentation on Maven 3 and Next Generation Development Infrastructure.  The presentation will cover the future of Maven, Maven 3, the release of m2eclipse 1.0, and the move towards a standardized development stack that includes tools like Maven, Hudson, m2eclipse, and Nexus.

This discussion will focus not only on the tools individually, but how they can work together to create a best practices approach to building and delivering your software in your organization.

For more information on Devnexus 2010 visit the conference website.  Devnexus 2010 is sponsored by the Atlanta Java User Group.