You’re Using Maven 2 – Are You Sure?


September 13, 2012 By Manfred Moser

When training the Maven Fundamentals or Advanced Maven Techniques classes or reading the Apache Maven users mailing list, it seems that again and again Maven 2 pops up. Sometimes even the long dead Maven 1 creeps up now and then.  Usually my first two questions to somebody using Maven 2 are Why? and Are you sure?

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

  • Jmini

    A lot of documentation mention that they use “Maven 2″ (and not just Maven). Maybe this is because at that time “Maven” vs “Maven 2″ was important. But when you read this now, you really ask you if it will work with Maven 3 or not…

    Example:
    Jenkins tutorial plugin:
    “To develop a plugin, you need Maven 2 (why?) and JDK 6.0 or later.”

    https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial

    Page: Why Maven2?
    https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=3309681

    If I had an account a would submit a change.

  • http://ccmcomputing.net/ Cole Markham

    How do you figure that Eclipse “compilation of your source on the fly”, “Run As – junit-tests” and “Run As – Java Application” are using Maven? Those are all part of the Eclipse JDT and have nothing to do with Maven.

    • EmDauPhu

      Yeah I had the same question.

    • http://twitter.com/fbricon Fred Bricon

      This is partially true actually. Even though the actual compilation and execution are performed by eclipse, the classpath and test classpath are resolved by the maven 3 embedder.

      Also note that non-java resources are excluded from JDT processing and entirely processed by the maven-resource-plugin under the hood.

      Other build participants based on the execution of some maven plugins can also happily hop into the build process

      • Manfred Moser

        Thank you for beating me to the explanation. I have also confirmed this with Igor Federenko (core committer on m2eclipse).

  • Michael Worthington

    I agree that Maven 3 is a big improvement on 2, but it is not always a drop in replacement. A reference to
    https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html is definitely worth while.

    Coincidentally, I came across an issue just today where a fellow developer was trying to support a Maven Archetype for both Maven 2 and 3. Maven 3 worked just fine, but Maven 2 was failing because it couldn’t find version 2.3-SNAPSHOT of the maven-archetype-plugin. Long story short, it was due to the change in Maven’s Automatic Plugin Version Resolution where Maven 2 allows Snapshots where Maven 3 only takes the latest Release.

  • http://twitter.com/briantopping Brian Topping

    Cool article, some stuff I didn’t know (like that Eclipse finally doesn’t require plugin roulette as soon as it’s downloaded just for Maven support).

    While certainly not the only reason, having had several years of reliable embedded support for Maven in IntelliJ IDEA has been one of many reasons that I pay them for upgrades. The same process has been true there from the start — the classpath is calculated via Maven and used by the tool runtime for the “run as” setup.

    • http://www.discursive.com Tim O’Brien

      IntelliJ IDEA is great. The Maven support in that tool used to be substandard, but it caught up quickly, and, I’d even venture to say that it might exceed m2eclipse at this point in terms of usability. It effectively hides complexity while m2eclipse exposes a bit much.

  • Alex

    Compatibility ends when it comes to repositories. There you have different behaviour using Maven 3. Support for non unique snapshots was dropped and metadata treatment is different. A nightmare for ci installations with both Maven.

  • Ryan

    Manfred, I remember having this conversation with you and hearing your dismay that we were using Maven 2. It turns out some of the ‘edge cases’ are very prevalent in our code, making it difficult to upgrade. It would have been nice if there was some sort of upgrade option to take maven 2 files and make them proper maven 3 files, or at least good documentation for all of the edge cases that includes examples of what to do. Some things work in Maven 2, that don’t work in Maven 3. For example,

    org.apache.maven.plugins
    maven-jar-plugin

    jar

    true

    target/classes/
    target/dist

    org.apache.maven.plugins
    maven-jar-plugin

    test-jar

    target/test-classes/
    target/dist

    Works in Maven 2, but in Maven 3:

    [WARNING] Some problems were encountered while building the effective model for com.foo.bar:blah:jar:1.2.3-SNAPSHOT
    [WARNING] ‘build.plugins.plugin.(groupId:artifactId)’ must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-jar-plugin @ line 38, column 12
    [WARNING] ‘build.plugins.plugin.version’ for org.apache.maven.plugins:maven-jar-plugin is missing. @ line 38, column 12

    This leads to:

    [exec] [INFO] [INFO] ————————————————————-
    [exec] [INFO] [ERROR] COMPILATION ERROR :
    [exec] [INFO] [INFO] ————————————————————-
    [exec] [INFO] [ERROR] /opt/workspace/foobar/src/main/java/com/foo/bar/blah/my.java:[11,39] package com.foo.bar.blah does not exist

    The solution is to refactor the plugin, so that there is only one definition, like this:

    org.apache.maven.plugins
    maven-jar-plugin

    jar

    jar

    true

    target/classes/
    target/dist

    test-jar

    test-jar

    target/test-classes/
    target/dist

    But given that there are 100′s of such fixes necessary, it’s not a simple task.

    • Manfred Moser

      @Ryan .. while this is true the reasons these things change is more related to the plugin upgrades you get when upgrading Maven rather than the upgrade of Maven itself. To get started on that I would suggest to start controlling plugin versions in a company pom and then then do it step by step.