Best IT Recipes

Maven 3 - Worth it?

Beta version of Maven 3 has been missing for a couple of weeks, and I just want to get your views on the list of features for Maven 3. Since only two main functions have been added for me

  • Running a project in parallel in the build life cycle
  • User life cycle

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

+49
maven-3
Jul 01 '10 at 11:19
source share
4 answers

What's new in Maven 3? Here is a small build of what you can find online.

  • Backward compatibility . Maven 3 has backward compatibility, which is extremely important (especially for those who have experienced the transition of Maven 1 to Maven 2).
  • Infinite Parent Elements - Maven 3 will remove the need to specify a parent version in add-on modules. THIS is excellent (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 ​​(the XML format doesn’t annoy me personally, so I'm not sure I will use this often).
  • Extension points - To decorate the life cycle or plugins (to activate behavior instead of extension plugins).
  • Queryable lifecycle - Decoupling of execution and execution plans.
  • Changes to the Plugin API. This is more focused on plugin developers (annotations instead of javadoc tags, extension points, repeating life cycle).
  • Better reporting of errors and integrity. The errors are clearer and related to the Maven 3 wiki for a detailed explanation. Users will like it.
  • Mercury - Complete the rewriting of the artifact resolution system (now a dedicated product) In fact, Maven 3 uses Aether instead of Mercury.
  • Maven Embedder - This is great for IDEs and build tools (which can “listen” to the build process).
  • Incremental build support - especially useful for M2Eclipse (performance improvement).
  • The site and the report extracted from the main Maven core are not yet working (will be fixed for the final version) , reporting (but you are invited to use external quality tools such as Sonar).
  • Maven shell - an optimized runtime (Maven awesome shell).

To summarize, you are not completely mistaken, there are not many changes on the surface (although I really like the better reporting of errors and just can't wait for material elements without versions). But the changes under the hood make Maven 3 much faster , and that's huge. And I expect that with the new opportunities offered (but still ahead) there will be great innovations.

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

see also

+74
Jul 02 '10 at 14:50
source share

The idea of ​​Maven 3 was to replace Maven 2 without problems ... there are currently some (in particular, the site). I would suggest testing existing Maven 2 projects with Maven 3 to see if there are any problems. The internally complete code has been reorganized, etc., to make new improvements possible. Removed some parts from the kernel (for example, creating a site, etc.).

+1
Jul 01 '10 at 11:24
source share

No, it is not compatible, as the matrix says. There are many incompatibilities between 2 and 3, and there is behavior that points to the page. If you are working on corporate projects in a corporation, you can be sure that you will encounter these problems.

As for performance, if you run enterprise builds that don’t build 10k-100k code ... How about a 1.5 million line system? This is more common in the enterprise. If your software is 2-4 hours old and you still need continuous integration, you will learn about parallel assembly and testing. Maven 3 is right at this moment ... but at the moment it’s unacceptable that the resolution of the tree / class path is different depending on the target (dependency: the tree uses an outdated mechanism, and regular build targets depend on the ether). This is reminiscent of Ivy / Ant problems when you cannot rely on checking the class of the path to the software package for deployment (you do not have a local Maven repository during production, right? ... but you still need to audit the software, right? )

+1
Jan 10 '13 at 19:13
source share

They removed the -r option and replaced it with an extremely complex system.

Maven encourages copy / paste pops. I was hoping they would fix this in 3.0. They reset the mixins function to maven 3.1.

Besides build performance and a few minor bug fixes, this is not worth it.

0
Dec 29 '11 at 16:34
source share


More articles:


All Articles