Maven 3 - Worth it? [closed]

Question

Maven 3 beta is out since a couple of weeks and I just want to get your views on the feature list for Maven 3. Because to me, only two major features were added

1. Parallel execution of of project in the build lifecycle
2. Custom lifecycle

Everything else seems like a bug fix or a minor improvement. So what do you think? Will Maven 3 be worth the wait?

Answer 1

What's new in Maven 3? Here is a little compilation of what you can find around the net.

• Backward compatibility - Maven 3 is backward compatible, that is extremely important (especially for those who experienced the Maven 1 to Maven 2 transition).
• Versionless parent elements - Maven 3 will remove the need to specify the parent version in sub modules. THIS is great (in Maven 3.1).
• Mixins - For POM composition (in Maven 3.1 AFAIK).
• XML POM format using attributes - You can use attributes instead of elements.
• Polyglot Maven - You can write your POM files now in different languages (I'm personally not annoyed by the XML format so I'm not sure I'll use this that often).
• Extensions points - To decorate the lifecycle or plugins (to hook behavior instead of extending plugins).
• Queryable lifecycle - Decoupling of execution plans and execution.
• Changes in the Plugin-API - This is more targeted at plugins developers (annotations instead of javadoc tags, extensions points, queryable lifecycle).
• Better error and integrity reporting - Errors are more clear and linked to the Maven 3 wiki for a detailed explanation. Users will enjoy this.
• Mercury - Complete rewrite of the artifact resolution system (which is now a dedicated product) Actually, Maven 3 uses Aether instead of Mercury.
• Maven Embedder - This is great for IDEs and build tools (that can "listen" to the build process).
• Incremental build support - especially useful for M2Eclipse (big performance boost).
• Site and reporting extracted from Maven core - site doesn't work yet (will be fixed for the final release), reporting does (but you are invited to favor external quality tools like Sonar).
• Maven shell - An optimized execution environment (Maven Shell is awesome).

To summarize, you're not totally wrong, there aren't that many changes at the surface (although I really enjoy the better error reporting and just can't wait for the version-less parent elements stuff). But the changes under the hood make Maven 3 much faster and this is huge. And I expect great innovations to happen with the new offered possibilities (yet to come though).

At the end, the performance improvement is already enough to make it worth for me (building in less time is extremely valuable) and other things are bonuses. And since I'm not using the site plugin extensively, I'm already using Maven 3 for more than 4 months on some of my builds and I'm more than happy with it.

See also

• A Guide to Maven 3 Beta
• Maven reloaded (from devoxx)
• Maven 3.x preview
• Whats new in Maven 3
• Jason van Zyl on the Future of Maven: Maven 3

Answer 2

The idea of Maven 3 was to replace Maven 2 without any problems...currently there are some (site in particular). I would suggest to test the current existing Maven 2 projects with Maven 3 to see if some problems occur. Internally the complete Code has been refactored etc. to make new improvements possible. Removed some parts from the core (like site generation etc.).

Answer 3

No it is not compatible as matrix says. There is alot of incompatibilites between 2 and 3 and there is page pointing behavior. If you work on enterprise projects in a corporation you could be assured that you will run into these problems.

As far as perfomance well if you run enterprise builds that ain't 10k-100k code build... How about system 1.5 million lines? That's more common in enterprise. If your software builds 2-4 hours and you still need continuous integration you will be looking into parallel build and testing. Maven 3 comes handy at that point... but at this point it is not acceptable that tree resolution/classpath is different depending on goal (dependency:tree uses legacy mechanism while regular build goals rely on Aether). It is reminiscent of Ivy/Ant issues when one cannot rely on checking classpath prior to software packaing for deployments (you do not have local Maven repo in production, do you? ... but you still need to perform software audits, right?)