The answer to the “Why?” is often a mumbling about not enough time to upgrade and upon closer inspection,  I find that it was never honestly tried. It seems there is still a perception out there that Maven 3 is a new major version and is largely incompatible. However – that is completely false! It was true way back when Maven 1 was replaced by Maven 2, but is not true for the move to Maven 3. In fact, apart from a few minor edge cases, Maven 3 will work as a complete drop in replacement for Maven 2 with improved performance, better error reporting and many more enhancements.

One of the main goals for Maven 3 was to make it more suitable for embedding Maven in tools like an IDE or a CI server. This brings me to the second question “Are you sure?”. When asking about the IDE used for development on the project in question, the most frequent answer is Eclipse. I then find that a stock install of Eclipse with the m2Eclipse plugin, as provided in the last two Eclipse releases, is used. These integrations embed Maven 3 and therefore any work you do with your project in the IDE is actually using Maven 3. Assuming that it works, you are ready to move to Maven 3 on the command line. That is pretty much always the case since how would the developers otherwise do any work?

Now some people object that they have in fact configured Eclipse to use an external install of Maven 2. While that is correct and works for any execution of Maven from Eclipse that uses the “Run/Debug as Maven” features you are still using Maven 3 in many cases. In fact, compilation of your source on the fly, any POM editor work as well as “Run As – junit-tests” and “Run As – Java Application” is still being done by the embedded Maven 3. So whatever you do…you will most likely have Maven 3 in the mix. And realistically a mixed use case like that will be more complex and troublesome than an outright upgrade to Maven 3. Try it!

Writing extensions for sophisticated integrations and plugins like Tycho used for Eclipse and OSGi related development with Maven OS is in fact only possible with Maven 3 and therefore you may already be using Maven 3 for use cases like this.

With this knowledge and understanding you should now be ready to install Maven 3 and benefit from its increased performance and maybe fix some of the errors in your pom that it will find. While you’re at it, you should probably start creating a company POM and controlling your plugin versions used in your Maven builds. Then you could upgrade e.g. to the new Maven Compiler Plugin 2.5.1 and get another performance boost for your builds. To make sure that nobody sneaks in the creaky Maven 2, you could introduce a Maven Enforcer Plugin usage …

If you would like to learn more about Maven usage tips and tricks, you can join me in one of our upcoming virtual Maven training classes. — Or join me in our upcoming Nexus virtual training class to find out why and how you should really be using a repository manager with any build system that has built in dependency management (and they all do today).

See you then,

manfred

m2e 1.1 has been released as part of Eclipse Juno release this week. If you haven’t heard about Eclipse Juno, you should take a look. Eclipse 4.2 IDE for Java Developers includes m2e by default. If you use Maven and Nexus, download Eclipse 4.2 today.

Noteworthy in this version:

• A new embedded Maven runtime based on the latest released Maven version 3.0.4,
• Significantly improved “convert to maven project” implementation
• ….and many other fixes and improvements. You can find complete list of changes in this release in Eclipse’s Issue Tracker.

m2e 1.1 is already included in “Eclipse IDE for Java Developers” package available from http://eclipse.org/downloads/ or it can be installed from the Eclipse Juno release repository. Eclipse 3.7/Indigo users can install the new version from the m2e release repository

Sonatype software developer Pascal Rapicault recently answered those questions on his blog, and we’re passing the information on to you.

Helpful links:

Software developer Igor Fedorenko details the new features and changes to m2eclipse 1.0, including pom.xml editor enhancements and reworked build lifecycle mapping.

For more videos from the Sonatype team, visit our Resource Center, or go to our YouTube channel.

These changes are now in the core of Hudson. Even though JSR330 can now be used by plugin authors these changes should, in no way, affect plugin authors using the existing API. Since this question came up on the mailing list, I’ll give a short description of how it works here. The JSR330 integration allows you to take advantage of JSR330, if you wish, by using an alternative plugin strategy. Our new plugin strategy interoperates with the existing, classic plugin strategy. Sonatype’s Hudson Professional distribution actually ships with a mixture of JSR330 plugins and classic plugins and we find this works quite well. We tried to make it easier to use new strategies for wiring up plugin, and Stuart McCulloch has offered this strategy on the Jenkins development list and it appears to have been absorbed as part of JENKINS-8897. Now that the absorbtion of our first proposal is complete we will move on to our next proposals. These proposals are a mixture of project infrastructure proposals and core Hudson proposals.

New infrastructure for plugin developers. Winston Prakash and I have been working on setting up a new infrastructure for Hudson plugin Developers where it’s very easy for them to develop, stage to Nexus OSS, and synchronize their plugins to Maven Central. As part of this work Sonatype is also working on making Hudson plugin development dead-simple with m2eclipse. Winston and I have started testing this new infrastructure with a few plugin developers over the last couple of days and it’s working out quite well.

Plugins update site generation from Maven Central. Once Hudson plugin developers have synchronized their plugins to Maven Central we want them to be made immediately available to Hudson users. I have been working on a plugin for Nexus that will listen for incoming changes to Hudson plugins and dynamically modify the JSON metadata required by the Hudson update manager. The information about available Hudson plugins will be made available from Maven Central as a set of REST services. The integration possibilities here are very interesting.

JAXRS-based REST API. Jeanfrancois Arcand has been working on adding support for the dynamic addition of resources in Jersey and adding support for a JSR330-based component provider. We want to be able to use JSR330 and we want Hudson plugins using JSR330 to be able to dynamically register their own REST resources. Once this work is done on Jersey we will be making the proposal for its inclusion to the Hudson core.

Modularizing the Hudson core using JSR330. Stuart McCulloch has started analyzing the Hudson core and finding ways to help us reduce the complexity by breaking it apart into distinct JSR330 components. This will be an ongoing process, but one we believe will help us with all other work we intend to do with Hudson.

Hudson Core Testing. There is simply no way that we can aggressively refactor the core and know the changes are not harmful without drastically increasing the amount of testing done. This will be another ongoing process and I believe the most important contribution we will be making.

We are moving more carefully and probably slower then we might like, but we feel that, in order to aggressively add features in the future, the testing infrastructure, development infrastructure, and core features need to be in place. All this work I’m talking about will likely take a release or two to get in place but once that is done we will be moving at a radically different pace.

The screenshot below shows options that are available to you by hovering over on an expression in the m2eclipse POM XML Editor.

When hovering your mouse on top of a managed dependency, we show the currently resolved version of the artifact (dependency or plugin) and also where the artifact is managed (the model’s coordinates).

Invoking a hyperlink on the managed artifact gives you some new options as well. If the location is in another pom.xml file, that POM file is opened for you, and the cursor is placed at the location of the artifact’s definition.

Next to the preexisting option to open the artifact’s POM, you can now also navigate to the location where the artifact is managed. Let’s see where it leads us.

As you can see the artifact’s managed location is using an expression for declaring the version. Here you can again hover your mouse over the expression to see what it resolves to in the effective POM. To get to the definition of the property, just invoke the hyperlink again (Ctrl-Left Click on most platforms, Cmd-Left Click on MacOSX). See the next screenshot.

After hyperlinking, you reach the definition of the antlr.version property and you can finally change the property value and upgrade your ant-antlr dependency. If you find any issues with this feature or have a great idea for improvement, please don’t hesitate to file an issue in the eclipse.org bugzilla.

These improvements will be available from the Indigo repository at the end of this week as part of the M5 release. If you are adventurous you can try the temporary Hudson build which can be found here.

Today we are releasing m2e 0.12.1. Despite our previous announcement that 0.12.0 would be the last version made available from Sonatype, we have decided to cut this point release to make available new versions of the m2e dependencies.

Most notably, this release includes recently released Maven 3.0.2 embedded runtime and an updated version of Async HTTP Client that resolves all known issues reported against m2e 0.12.0, and thus helps make m2e work better in corporate environments.

As usual this version of m2e is made available from the Eclipse Marketplace and from http://m2eclipse.sonatype.org/sites/m2e/.

Enjoy!

Instead of expecting a user to supply these artifacts directly in the XML editor, you now have the option to search for an artifact and let m2eclipse take care of the details. We’ve also made some improvements to the Artifact Search dialog. Screenshots speak as thousands of words though so let’s take a look.

Read the rest of this post to learn more about this new way to insert artifact coordinates in a Maven POM using m2eclipse.

Inserting a dependency using auto-complete

In the POM shown in the previous figure, I have invoked completion within the <project> element. I haven’t started typing anything prior to invoking auto-complete and, as a result, m2eclipse shows me some extra insertion options: “Insert dependency”, “Insert plugin”, and “Insert reference to parent POM”.  In this particular example, I’m inserting a parent element.  Since I have no parent defined in this project, m2eclipse gives me the option to “Insert reference to parent POM” in this auto-complete menu. As a courtesy we will use the current groupId as the initial search term as it is likely that your parent shares the same groupId and we want save you some typing.

The dependency and plugin insertion proposals appear in multiple contexts. Here it’s <project>, but you will encounter them in <depedencyManagement>, <pluginManagement>, <build>, <dependencies>, and so on. If we are in <project> xml element, we will either generate the <build>/<plugins> elements as well (at the chosen location), or if you already have your <build>/<plugins> subelements defined, we will append the plugin definition there.

Support for managed versions

Child projects can inherit a set of default versions for both plugins and dependencies from parent projects that make use of dependencyManagement and pluginManagement elements. We call the versions defined in these elements “managed versions” – they allow you to specify a global version for any dependency or plugin at the top-level of a large multi-module project. If your dependency/plugin inherits managed versions (in parent POM for example) and you pick the managed version in the selection, we will omit the version element in the child POM.

Let’s take a look at the Selection dialog now, because we made it easier for you to spot and pick the managed versions of your artifacts as well.

We’ve reduced the amount of information shown, so for each dependency/plugin you only get to see the version, type and classifier If you want to see more details, like size or date of creation, just select the appropriate tree in the node.

As you can see the ant-antlr artifacts appear with the lock icon overlay and a decorator text. Both of these attempt to hint that this artifact is being managed in the current effective pom. Note: effective pom is only calculated when the pom file is saved. So any unsaved changes will not be taken into account.

To make it really easy for you to pick the managed artifact, the top node (ant ant-antlr) represents the managed version in this case (otherwise it’s the latest version). So you don’t have to drill down to the list of version to select the managed one. Just go with the artifact’s top node.

If you find any issues with this feature or have a great idea for improvement, please don’t hesitate to file an issue in the eclipse.org bugzilla.   We look forward to your feedback.

Sonatype is investing heavily to ensure the baseline M2Eclipse 1.0 is of high quality, stable, and maintainable. With the help of the amazing IP team at the Eclipse Foundation M2Eclipse has passed its initial IP review, has entered the parallel IP process and is slated to be released as part of the 2011 Indigo release of Eclipse. To be certain, this will be a great milestone for the Maven and Eclipse ecosystems: users have been asking for years to have good Maven integration included in the standard Eclipse distributions and this will be the year they get it. Indigo will ship this year on June 22nd, but in the meantime Sonatype will be working on and soon releasing Maven IDE!

What is Maven IDE exactly? Maven IDE is a Maven-focused distribution of Eclipse that will consist of a base Eclipse distribution, M2Eclipse and a series of Maven-focused integrations where there is strong support within the Maven and Eclipse ecosystems. What are some of the things we are looking at potentially integrating?

Frameworks and languages

JSR-330 & Guice integration: JSR-330 & Guice are now critical to the Maven ecosystem and very important to Sonatype as a technology. The JSR-330 implementation provided by Guice provides core functionality for Maven 3.x, Nexus, M2Eclipse, and Sonatype’s Maven 3.x integration for Hudson. We will create tooling for JSR-330 to help with our own work, general integration work for development infrastructures, and anyone using JSR-330.

Webapp development tooling: Webapp development is the most requested form of integration and we are still evaluating what’s available in WTP versus making something that is simpler and integrates more tightly with Maven. For those that don’t know, the WTP integration for M2Eclipse is not part of the codebase that moved to Eclipse. Sonatype will be working with the community on the M2Eclipse/WTP integration and will help distribute it from Sonatype, but we are also looking at alternatives to WTP.

Tycho integration: We already have support for Tycho inside Eclipse that allows Tycho projects to interoperate with PDE at a rudimentary level, but we would like to improve this integration and bring support for Tycho-based projects into the Eclipse IDE.

Maven Shell integration: This is where the Maven command line will intersect with the IDE. We see in the future being JSR-330 component based so we can leverage them from the Maven Shell and Maven IDE, and these components will participate in long-lived workflows that aid in the development of applications. We plan to use Drools Flow for the workflow implementation and the Eclipse tooling that exists for Drools Flow. The workflows will be accessible and usable from the Maven Shell as well as from within Maven IDE.

Polyglot Maven integration: For some of the selected grammars and dialects of Polyglot Maven we will provide support in Maven IDE. The folks at Itemis have been a great in helping us understand how Xtext can play a critical role in this regard. If a grammar can be represented in a form that Xtext understands then much of the plumbing for powerful editors can be created automatically using the Xtext framework. There are currently some integration issues between standard Maven and OSGi that need to be resolved but Xtext is an incredibly powerful language workbench. The Itemis guys have really done some incredible work.

Android development tooling: Android is becoming very popular and has a strong Maven contingent. There are sophisticated Maven-based tools for developing Android apps that have been created by Android community: the maven-android-plugin by Hugo Josefson from Jayway, the Eclipse integration exists as part of what Google provides, and Ricardo Gladwell has created the bridge between Maven and Eclipse with his Android M2Eclipse integration.

Scala IDE: Miles Sabin is creating great Eclipse integration for Scala with his Scala IDE project and David Bernard is bridging that work into Maven m2eclipse-scala. We are seeing a lot of demand for Scala integration with Maven.

GWT integration: GWT has rapidly become one of the standard webapp toolkits for Java and we’ve seen a lot of demand for better integration with M2Eclipse. Within the realm of development infrastructure GWT is very popular. Sonar uses GWT, Gerrit uses GWT, XWiki uses GWT, and Sonatype has chosen GWT as the basis of the UI for our Maven 3.x integration in Hudson. GWT will continue to gain momentum so it’s very likely we will have more sophisticated integration with M2Eclipse sooner rather then later.

Development infrastructure

Sonar integration: Sonar is becoming the de facto standard reporting and quality system for Java projects. Sonar is very Maven-centric and SonarSource has provided Eclipse integration that can easily be integrated with Maven IDE.

Hudson integration: Hudson is the de facto standard continuous integration server for Java projects. Sonatype is currently working on finishing our Maven 3.x integration and it will be integrated within Maven IDE.

Wiki editing & site publishing: Sonatype has a wiki page editing and publishing framework called Idiom — that is based on the WikiModel project — that we will be open sourcing, and hopefully merging with the tools that exist in the WikiText project at Eclipse. Ultimately we would like to see WikiModel merged with WikiText and then work together within the community to make great editing tools. If WikiModel could be wed with Xtext it would be amazing.

SVN integration: Obviously important and we initially removed the SVN support to clean up and focus on the core. We’re layering it back in as resources permit. It’s not going anywhere and there are actually two options now. Sonatype supports the Subversive integration which is the official SVN integration at Eclipse, but the community has contributed the Subclipse support. So both variants will be available and Maven IDE will ship with the Java-based SVNKit connector.

Git integration: Git is sweeping over the development community and has taken off like wildfire. At Sonatype we use Git for the vast majority of our projects so great Git integration with Eclilpse and Maven is vital.

Maven Central statistics and metadata: Many OSS projects have been thrilled with the statistics we’ve provided them and we’ll be working in the future to provide more value from the information in Maven Central and deliver it into Maven IDE. Maven Central is an unparalleled source of interesting and useful information for developers and we want to make all that information more accessible.

So you can see that the number of paths we can potentially take are limitless. What will really help us limit our choices are the partners we find who are as committed as we are to the Maven and Eclipse ecosystems. We’re not interested in individuals, groups, or organizations that are hedging their bets with Maven and Eclipse. We are looking for individuals, groups, and organizations who are committed to the Eclipse Platform and Maven as the basis of their development infrastructures.

Things we’ll be looking for in integration partners, are: Tycho build, good test infrastructure, and a composite p2 repository for integration. Maven IDE will first be available in an OSS community edition and will be followed by future commercial versions. We are excited about building out a polished, Maven-focused distribution of Eclipse and we’re really looking for feedback from the community about what integrations to pursue first. So please let us know!

Apache and Apache Maven are trademarks of the Apache Software Foundation. Maven Central is a service mark of Sonatype, Inc. Nexus, Maven IDE, Maven Shell, and Polyglot Maven are trademarks of Sonatype, Inc. Maven Central, Maven IDE, Maven Shell, and Polyglot Maven are intended to complement Apache Maven and should not be confused with Apache Maven.

From an end-user perspective this means a wider availability of m2eclipse, but more importantly it means an alignment of m2e with the main Eclipse components and also with the Eclipse releases.  m2e will be participating in the Indigo release train and we have asked for its inclusion in the Java Developer Package.

Eclipse is known for IP cleanliness. Through its very thorough IP review process, the Eclipse Foundation has been known to only make available code with a very clear pedigree. In fact, it is this very process that prevented us from moving our code to Eclipse a couple years ago. We now have addressed all the issues uncovered in this initial attempt.

You may wonder, how does this help me? It does not make m2e run faster, or better? You are right, but it helps where you can’t see.  It helps making someone in your management chain more comfortable with the usage of m2e, but also enables m2e for inclusion into more Eclipse-based products and to some extent favor the creation of m2e extensions.

From an extender perspective, this move means work. In fact, since m2e namespace will now be org.eclipse.m2e instead of org.maven.ide, m2e extension developers will to be forced to change their code to have their extensions work with the new m2e. Despite our commitment to work in Eclipse 3.7 (Indigo), m2e is still targeted to work on Eclipse 3.5, 3.6 and 3.7, which means that you should not have to maintain two branches of your code one for the “old” Sonatype m2e and one for the new Eclipse m2e.

Overall despite the initial hurdle that can result from this sort of move, we are deeply convinced that it is a great opportunity for the m2e community at large.