Maven 3.0 Released

by Alex Blewitt on Oct 08, 2010 |

Sonatype today announced the release of Maven 3 (release notes), the biggest change since Maven 2 was released in 2005. Unlike the change from Maven 1 to Maven 2, which had changes to the POM as well and caused a significant impact to the Maven community (not the least was the ejection of the Jelly scripting language in favour of Java MOJOs), the release of Maven 3 has been backed up by significant automated testing using open-source projects in the field to try and prevent backward incompatibilities. As a result, Maven 3 should just be a drop-in replacement for Maven 2, with few noticeable differences other than an increase in performance. Any known problems are listed on the compatibility page.

The new version of Maven 3 is built upon Google Guice, a light-weight dependency injection framework, rather than the Plexus container that was solely used before. This refactoring allows other containers to be used in the future, such as Pico Container. The abstraction layer is provided by Sisu, which will also compatible with Spring.

The reporting aspects of Maven have been changed; the dedicated reporting section is now found in a per-report configuration options (similar to plugins). For existing Maven POMs, automatic translation will take care of re-writing, but as Maven 3 becomes widespread, the use of a standalone reporting tag will fade away. In addition, the processing of reports (and site generation) has had to be revamped for Maven 3, and in previous betas, there were some limitations on what the site generation will publish; see the release notes for more details.

Maven Shell

Maven 3 introduces the concept of a Maven Shell, a standalone Java process that is part Maven build, part build server. Maven Shell will load and parse all the necessary POMs for the project, and keep them in memory for faster builds subsequently. In future, this may mean faster builds available for build servers that repeatedly build the same code. The source code is available from GitHub if you'd like to see the code; there's also a FAQ available. Maven Shell will be the replacement of the older maven-cli-plugin, and in future will have built-in support for Hudson, Nexus, JIRA and Confluence .

Tycho and M2Eclipse

As well as improvements to the runtime, Maven 3 also permits other extensions that were not possible in Maven 2. Tycho is a build plugin which allows Maven to build Eclipse plugins, Eclipse features, Eclipse (P2) update sites and Eclipse RCP applications. Not only that, but it can also consume other P2 update sites for those libraries which aren't available in standard Maven repository formats. Several Eclipse projects now use Tycho over the antiquated Eclipse PDE/Ant build, with one saying “Probably the hardest thing about using Maven and Tycho to build my Eclipse project was getting my brain around how easy it is” – anyone who has created an Eclipse build in the past knows how fragile it can be getting it working in the first place, with a “don't touch it!” attitude once it finally does start working. Currently, Tycho is hosted by Sonatype, but will be moving to the Tycho project at Eclipse.org in the future.

The plugin which manages Maven builds inside Eclipse, M2Eclipse, has been updated to use Maven 3.0 with Guice and Aether as well. This provides a simple way of building and managing projects that use Maven. If you've used Maven in the past, then one thing to watch out for is a difference between the maven instance pointed to by M2_HOME and Eclipse, since M2Eclipse will install its own copy of Maven. Currently, M2Eclipse is hosted at Sonatype, but it is being moved to the M2E project at Eclipse.org in the future.

The future

Maven 3 opens a number of possibilities for the future. The format of the POM has been decoupled with the internal data structures, which means it's potentially possible to use other (non-XML) formats. Although not released as part of Maven 3, experiments into Polyglot Maven show this to be a future avenue for development.

Another advantage to the separation of concerns is the ability for POMs to be split over more than one file. This permits “POM Mixins”, a feature which won't be immediately available in Maven 3 but which has already been partially developed. A POM mixin will allow a sub-set of plugins and reports to be defined – somewhat similar to a parent POM, but a standalone entity in its own right which can be applied to multiple projects (which may not otherwise have a common ancestor). Companies and open-source organisations wanting to achieve a degree of uniformity between projects will be able to use the mixin approach to configure standard builds without having to organise them hierarchically.

Finally, the Maven 3.x tree will be moving towards an OSGi runtime after the 3.0 release. This will be enabled by using Peaberry to wire in the dependency injection hooks. One of the big challenges here will be the migration to using OSGi-like versioning schemes (explained at the Semantic Versioning site). Migrating to the OSGi runtime will likely not be a challenging process; however, minor differences between the way that OSGi and Maven treats versions are likely to be more problematic (the unqualified version is 'bottom' in the OSGi range but 'top' in the Maven range), as will symbolic references like SNAPSHOT. Other symbolic references, like LATEST and RELEASE can't be used any more.

A lot of hard work has been done by Sonatype and others bringing Maven 3 to a successful release. You can download it now from maven.apache.org.

Related Editorial

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Moving to OSGI? by Jacek Furmankiewicz

Well, that will be a big productivity hit...I guess we can expect Maven 4 around 2020 then.

Maven is still garbage by peter lin

Recently I tried maven 2 again, since I was playing with apache roller. What I found is that m2eclipse is garbage and so is maven 2. It's improved since maven 1, but frankly maven 2 is still junk. flame on!

Re: Maven is still garbage by Richard L. Burton III

I suspect you're an Ant guy. Defining your build in XML is #fail

Flame on!

Re: Maven is still garbage by peter lin

I'm not really pro ANT, until I have to use maven, then I think to myself "ant would be so much easier right now". The whole directory structure imposed by maven is retarded. Forcing users to "comply" with maven's silly structure for "optimal" builds is just a huge sign that maven sucks! A build system should seamlessly fit into existing project without forcing stupid structure or complete refactoring of the project layout. Maven should have been aborted before it was ever born!!!!

Re: Maven is still garbage by Behrang Saeedzadeh

The whole directory structure imposed by maven is retarded.


Directory structures are only a matter of preference. It takes some time to give up on your preferred directory structure, but in the end a well-thought directory structure is a well-thought directory structure. What's great about your preferred directory structure that's better than Maven's?

without forcing stupid structure or complete refactoring of the project layout.


There's this thing called opinionated software aka convention or configuration aka configuration by exception. When a project is built according to a known convention, it makes it much much easier for new developers that have to work on that project to understand what's going on inside it, what modules it's comprised of, etc. This is not true about custom in-house project structures, etc.

Besides, you can configure Maven to work with your preferred directory structure.

m2eclipse is garbage


Yes, it is. Fortunately I'm using IntelliJ IDEA and IDEA's integration with Maven is rock solid and very well-done.

Re: Maven is still garbage by Jimmy K.

What I found is that m2eclipse is garbage and so is maven 2


I think Maven2 could be improved in a number of ways, but to say it is garbage is one bridge too far. But I admit it takes some time to appreciate and get used to it.
To say that m2eclipse is garbage, well, that's a massive understatement. It's buggy and with each release they make changes that makes your current workspace crash in another way than the previous release. It's a real shame.

Re: Maven is still garbage by peter lin

Clearly I'm completely bias and hate maven 1 & 2. If I didn't have to suffer maven repository stupidity, and odd maven 1 bugs in the past, my opinion "might" be different. I'm happy to see others have also suffered with m2eclipse. At least I'm not alone and others have had to endure the pain that is m2eclipse. If I never had to run builds and someone else was responsible for maintaining maven2 builds, I probably wouldn't care. The over head of maintain maven 2 builds is extremely high from first hand experience. Then again, I'm bias from first hand experience. I'm sure there are people who are blissfully happy with maven.

Re: Maven is still garbage by Zilvinas Kybartas

I'm one of those happy users. I use maven for about 5 years now, in every single project. I found out that maven works best when you have to start small and then eventually grow big by adding new poms.
Yeah, m2eclipse was bad, so i was using q4e for some time, but recently i gave m2eclipse one more try, and found out that it was improved alot, so now i'm using m2eclipse and im happy with it.

Re: Maven is still garbage by Peter Veentjer

The good thing about Maven is that it works reasonably well when you don't do special things. But as soon when you need to, you are in a world of pain. Most of the plugins lack serious documentation, and the order plugins are executed in is total magic.

For my open source projects I already moved to Gradle. All the benefits of Maven, but none of the problems.

Peter Veentjer
Multiverse: Software Transactional Memory for Java
multiverse.codehaus.org

Re: Maven is still garbage by peter lin

I still haven't tried gradle yet. the next time I need a build tool, I'd try that over maven in a heart beat.

Re: Maven is still garbage by Wong Yuen Ho

Maven was born out of a need to unify the directory structures and build processes for projects, but to call Maven a "solution" is perhaps an over-exaggeration. After 9 years, one cannot help but ask why on earth were they problems in the first place? There aren't any two projects that have completely equivalent build requirements. When the build requirements are different, they almost necessarily require different directory structures and/or build sequences. The Maven people just couldn't accept that and made this contorted giant piece of clusterf**k that cause more problems then they solve.

The dependency "management" in any version of Maven prior to Maven 2.1 was a joke. I can never understand why dependency management was an afterthought for a "build tool".

The technical decisions made during the evolution of Maven were also eclectic beyond imagination. How they justified the requirement of building a project site before you could see your test report is beyond me. Unchecked and liberal use of system properties were also a frequent source of build errors. 9 years later, they still haven't figured out how to throw in a decent command line parser and yet they have no problem with moving to OSGI. Never heard of Commons CLI? Hello? Want to run all tests and not stop at the first error? Here do mvn -Dmaven.test.failure.ignore=true test. Want the latest version of a jar to be automatically included in your classpath? Nope, no such thing, include the version at the top level yourself or exclude every other reference of the older versions of the jar.

"Engineers" who can't even write a decent build script to build your own effing project shouldn't even be allow to program. They should be put in medical patient restraint if they even attempt to design and write code for a "build system" and release it into the wild.

Re: Maven is still garbage by Brian Edwards

haha someone is very passionate. I have to generally agree. I started to use Maven about 1.5 years ago so I was late to the party. ANT did everything that I needed but I figured I should try Maven because it was getting a lot of press. It does have its strengths but I find myself wasting such an enormous amount of time trying to get it to work as everyone else seems to be be able to so effortlessly do. Either I'm using the wrong tools or I'm just pure stupid. Probably a mixture. I bought the O'Reilly book about it and it cleared some things up but I find myself hunting down nonexistent documentation or outdated methods on someone's blog. Maven is a good idea but I don't know where it went wrong. I have since just moved over to Ivy and/or back to Ant.
The main issue I have with maven is that their needs to be a central repository that is actually maintained. It is just full of junk and I found myself installing the latest jars directly from the project homepages locally which essentially renders the repository concept worthless. But, again, I must be in the minority because everyone else seems to be able to get it to work and is happy with it. Maybe it just needs an overhaul which I hope m3 is! I'm going to try again and see.

Re: Maven is still garbage by peter lin

Like you, the "dependency management" in maven never worked for me. Calling it a clusterf**k is what I call it every time I have to use it, so I'd that's an accurate description :)

Re: Maven is still garbage by Conor MacMahon

As per usual, maven has a love-hate relationship with developers.

As a fan of the tool, I do see the pros-cons of using the tool.

If all you need to do is create an application that say, contains jars/wars/ears, then maven is a create way to get you going, using the convention over configuration principle.

Like a few users have already mentioned in this thread....if you have to do something that's out of the normal lifecycle of sweet-spot of maven, DO go away from maven and go back into the scripting world (i.e. ant/gradle) to get that job done.

The main advantage I see with maven is the fact it is convention over configuration...if you follow the given convention, maven will give you lots out of it's toolset.

There are competitors out there nipping at it's heels (e.g. if you use the spring tech stack, then spring roo might be an option for you?), but maven is still the leading convention over configuration build tool for the java technology stack.

I'll continue to use maven, mainly for the benefits it gives me. If it doesn't give me something, I won't wrestle with it, I simply avoid maven's deficiency is certain areas by thinking of a lateral solution.

And by the by, I use m2eclipse day in-day out...I have to say I don't have any recent issues with it. In fact, I often use it's dependency graph to work out links or issues with my build...a picture paints a thousand words, and I've very happy this tool is available to me without cost to me.

Considering Sonatype also provide nexus, this company does provide a compelling solution around maven, assuming you know how to take advantage of maven in your enterprise.

Great news Sonatype, best of luck in the future.

Regards,
Conor

Re: Maven is still garbage by Edwin Quita

you need to invest some time in getting to know Maven to really get the benefit it offers, otherwise it may become your worse enemy and be a set back rather than a tool that promotes agility in your team. some knowledge in Nexus and Hudson can make portable and automated builds a breeze.

for us, it has become our best friend. it encouraged best practices in our development like having unit tests, standard project structure, project templates, re-usable components, and portable builds.

1. project templates

- i love Maven's archetype plugin. we used Nexus to host/publish our archetypes and have our developers access them in one place. (ex. mvn archetype:generate -DarchetypeCatalog=http://host:port/resource). we have a customized GWT, CXF, Axis2 archetypes for our project. made our projects IDE agnostic and we don't have to rely on IDEs for creating a project and to make our builds.

2. re-usable components

- from using the simple maven-archetype-quickstart archetype, we were able to build components (jar) and easily declare them as a dependency other maven projects, couldn't live without this.

3. portable builds

- how do you manage to build a project for different environments(dev, uat, prod) in Ant? with maven Profiles, it's like a walk in the park. we used separate Hudson instances (although one instance will do) to stage and automate our builds.

4. static analysis tool reports
checkstyle, findbugs, and cobertura code coverage reports all in one place. with this, i can give management a heatmap report for all our projects. i can instantly see the developers who mess around with coding :)

you may call me a Maven fanboy, but i wouldn't go back to user-defined Ant targets from standard maven plugins like clean, compile, test, package, deploy, and release (and i didn't have to refer to some build.xml file heh)

given this, i don't see maven as garbage. in our team, when we see a project built using ANT it's a LEGACY as in old!

Re: Maven is still garbage by peter lin

Frankly, it has nothing to do with "getting to know maven". I've studied maven code in an effort to fix bugs in maven 1 several years back before maven 2 came out. I don't get why maven apologist assume people who hate maven haven't invested time to learn how "maven is suppose to work." Back when I supported maven builds, we spent an inordinate amount of time getting maven to work reliably for a very complex project. We had to run a huge suit of tests on multiple platforms including windows, linux, aix, hpux and zos. we also has to test against sql server, oracle and db2. We had several repositories setup due to back testing requirements of previous releases.

Every weak maven builds broke and required spending 1-2 days to fix it. If it didn't break that week, everyone on the team rejoiced. ANT isn't legacy in my book. There are times when a build process is so complex that you have to handle all sorts of special cases. One might ask "why make it so complex?" Regardless of why it's complex, there's no getting around supporting complex use cases.

Re: Maven is still garbage by Tim McNerney

Maven is a decent solution if you meet all of the following:

* Your project follows the Maven structure.
* You don't do anything "unusual" in your build.
* You don't find it absurd that you have to use the ant plugin to do any one of a dozen useful tasks.
* You do not have to maintain the build.
* You do not change versions of your dependencies.
* Your dependencies are common and hosted by one of the major repositories.
* You haven't ever used a better build tool.
* You have plenty of free time to kill while maven is running to compile a single file.
* You enjoy reading through debug builds to track down errors in other users plugins.
* You enjoy trying to eek out some minor bit of understanding about third party plugins from their universally bad (and distributed) directions.

Unfortunately, there are a few projects that don't hit all of these.

Re: Maven is still garbage by Tim McNerney

I suspect you're an Ant guy. Defining your build in XML is #fail

Flame on!


Did I miss the part where pom.xml was written in something other than XML? Or are you advocating for make/gmake?

Re: Maven is still garbage by Edwin Quita

i suggest you study more, try looking at open source projects that use maven. i learned a lot from appfuse and other open source projects. a good understanding of the maven lifecycle and maven plugins will help a lot. i can imagine your projects having their jar dependencies checked-in your scm server ;-)

Re: Maven is still garbage by Wong Yuen Ho


we have a customized GWT, CXF, Axis2 archetypes for our project. made our projects IDE agnostic and we don't have to rely on IDEs for creating a project and to make our builds.


This tells me you've never written an Ant build.xml file that's IDE agnostic right there.


- from using the simple maven-archetype-quickstart archetype, we were able to build components (jar) and easily declare them as a dependency other maven projects, couldn't live without this.


Ant Ivy has a much much better dependency management system that knows that if I had a foo-1.0.1.jar and a foo-1.0.2.jar as transitive dependencies, foo-1.0.2.jar is the jar that I want and resolves the dependency automatically for me.


- how do you manage to build a project for different environments(dev, uat, prod) in Ant? with maven Profiles, it's like a walk in the park. we used separate Hudson instances (although one instance will do) to stage and automate our builds.


There's this thing called build.properties. Ant does text substitution way before Maven had filtering. Ant guys don't even need profiles.


4. static analysis tool reports
checkstyle, findbugs, and cobertura code coverage reports all in one place. with this, i can give management a heatmap report for all our projects. i can instantly see the developers who mess around with coding :)


All of them give ant tasks that you can just drop right into the project.


given this, i don't see maven as garbage. in our team, when we see a project built using ANT it's a LEGACY as in old!


When was the last time being old was considered a legitimate reason for choosing a different technology?

Re: Maven is still garbage by peter lin

Oh but I have spent time looking at how open source projects use maven. I won't bother listing them, but I've contributed to several well known open source projects. I've also seen the horrendous pain maven inflicts on people who want to contribute to a project. Again, more maven apologist making up excuses for what ever reason. On many of the projects I've worked on, the build order was complex because the jars were not checked into the source control. The order of the build was crucial, but the "dependency management and repository" of maven never worked properly. Some apps have over 20 components, which are separated into different eclipse projects. From my experience, with numerous eclipse projects and 20+ components, maven blows hard. You can get maven to work if you babysit maven and become a slave to it. Heck, we even wrote our own maven plugins to simplify our build process, but maven 1 was basically a huge pile of junk. Maven 2 is better, but it is still far too painful.

Re: Maven is still garbage by Edwin Quita


This tells me you've never written an Ant build.xml file that's IDE agnostic right there.

you can sulk in with your assumptions, go create a GWT project using ANT :p


There's this thing called build.properties. Ant does text substitution way before Maven had filtering. Ant guys don't even need profiles.

yay for hackers!


All of them give ant tasks that you can just drop right into the project.

another one of 'em jars to manually copy in Ant's lib directory :) worse gets checked-in the scm repository again!


Ant Ivy has a much much better dependency management system.

what is the value proposition? leshazlewood.com/2010/01/13/maven-2-vs-antivy-r...


When was the last time being old was considered a legitimate reason for choosing a different technology?

err, from ejb to hibernate.. that's just one of the many legitimate reasons out there ;-)

Re: Maven is still garbage by peter lin

"err, from ejb to hibernate.. that's just one of the many legitimate reasons out there ;-) "

depending on who you ask, I'm willing to bet many people consider hibernate old. After all, by tech standards it's more than 5 years old now. Lots of developers think anything older than 2 years to be "old". Then again, the concept of ORM actually predates EJB, so whether something is old or not really depends on how much one studies computer science and history. Making a decision based on "how old" is foolish. It should be based on the needs of the developer, the project scope, time line, functional requirements, R&D time, expected life span of the app and a host of other practical considerations.

Re: Maven is still garbage by Edwin Quita

that's the way to end the discussion: "depending on..." thanks! flame off ;-)

Re: Maven is still garbage by Bernd Schuller

hi,

[...]On many of the projects I've worked on, the build order was complex because the jars were not checked into the source control. The order of the build was crucial, but the "dependency management and repository" of maven never worked properly.

Would you really put dependencies into source control? The Maven dependency management stuff may have some quirks, but "never worked properly" seems a bit too much.


Some apps have over 20 components, which are separated into different eclipse projects. From my experience, with numerous eclipse projects and 20+ components, maven blows hard.

yeah, support for this scenario can probably be improved. One solution is to create a separate Eclipse workspace for such a large and complex app, like e.g. Apache CXF is doing.

Re: Maven is still garbage by Ben Sion

I admit that I am no Maven expert (nor fan) but I have tried to understand it. However I have always found the following types of statements about Maven confusing:


The main advantage I see with maven is the fact it is convention over configuration...if you follow the given convention, maven will give you lots out of it's toolset.


Part of that "convention" meant there were dozens (at least on the few projects I worked with Maven) of POM files. Which to the best of my understanding are Maven configuration files. This really does not feel like "Convention over Configuration" to me. My understanding of "Convention over Configuration" is really the need to have less configuration options explicitly specified and the application uses good defaults; not have dozens of configuration files in a known location. Iff you are not happy with the conventions then you specify the configurations to override.

So unless I am missing something (quite possible) it does not really provide that capability. If you mean "convention" by way of directory structure then I will concede Maven has that. But that is not really such an advantage IMO.

Happy to be enlightened.

Cheers,
Ben

Re: Maven is still garbage by peter lin

Using ant I would put jar dependencies in source control, but with maven that tends to cause huge headaches. then again, look at how bad some of the maven repositories are for some popular open source projects. Look at how many people have had issues getting the proper hibernate-entity manager jar from jboss maven repo. maven repo never worked properly and reliably for me. I'm sure others haven't had issues.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

27 comments

Educational Content

General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy