Why do so few people use Maven? Are there alternative tools?

Question

I am new to Java, and when I started my development, my friends recommended Maven for project management. I almost immediately realized that it is an indispensable tool, and at that time I was thinking that all programmers use it. But when I see statistics on the NetBeans site, I was in shock: 67% of developers are not using Maven. Why? Are there some alternative tools that make project management easy?

UPDATE

I agree with feicipet on 100%.

1) IDE independents it's really good. This was proved on my own experience. First, our team used the Eclipse, then we decided to switch to NetBeans, the people who help us with the project using IDEA. And it does not matter because the project can be run even with the console:)

2)Well structured and clean project. I think Maven structure convention is very helpful, because tests and main code are separate.

3)Project management. Maven it is not only build tool, it give you ability to configure you environment, run unit tests, and create reports.

For me, it turned surprised when the experienced programming talk about the difficulties of Maven, when I saw Ant in some project Maven showed me a miracle. And all comments about the complexity of the transition from Ant are strange. This is two different logic, what do you expect?

There are some problems with documentation, this is really bad. But I think this situation will change for the better

Answer 1

I think Maven suffers from a relatively high barrier to entry compared to tools like Ant. The difficulties with earlier versions and the complexity of 2.0 have kept me away. It's not 100% necessary, especially if you have a good IDE.

Answer 2

Maven is a great tools, the concepts and worlflow it puts forth are a great leap forward from the days not so far when we just ducked tape code together to create software (I am just now diving in a legacy Deplhi app with over 1M LOC.. ho the pain... how much I miss Maven)

This being said.. IMHO maven is still in it's infancy, documentation, although much better than before, is still scarce and hard to get at. Plugin control still has a few kinks in that it can become hard to have complete control over your build environment. Also behavior of the system still changes a lot from one version to the next so it is hard to guarantee stable builds in time.

So I can see why people would backoff from Maven coming from Ant for example. Maven, for an Ant user, has a lot of magic properties and behavior that creates an uncomfortable aura of uncertainty that does not sit very well with the typical build master paranoia we get when we start deploying apps to client and want stable versionning.

In spite all this they are on the right track and the slow penetration it sees is actually a "good thing" because it will in keeping the growth of the system within manageable rages so the problems are ironed out in time.

Learning Ant as a build system may be a better first step as it will help you understand the requirements and difficulties in a build. Also if Maven is not acting the way you want you can always revert to Ant and then integrate in the maven bigger picture.

The goals Maven tries to achieve are commendable and the road is very complex. But if you let your mind extrapolate what would the world be like in the Age of Information you quickly realize that manually dealing with dependencies to name just one aspect of Maven will soon just me plain impossible.

If Maven fails for lack of adoption but leaves just the idea of convention over configuration it will have achieved a great thing already...

... But it is so much more that that.

Long story short :

• Maven like tools are essential, but keep close watch on it it WILL bite you as it matures
• Do keep a healthy diversity in your build mechanism so you can always fall back to other simpler methods if Maven fails that one particular need.
• Subscribe to the newsgroup and read a lot on it from others experience, writing docs take time and is almost always outdated, especially in a tool as bleeding edge as maven is.
• Survive your early frustrations, your efforts will reward you richly in time.

My 2 cent

Answer 3

Maven adoption is fairly low because it is an over-engineered Rube Goldberg machine. Or in the words of Graeme Rocher (founder of Grails), "the EJB2 of build tools".

I think the goals of the Maven project are very worthy. Convention over configuration? Great! Automatic dependency resolution? Super! But unfortunately the practice is very different from the theory. In my experience, the introduction of Maven to projects that were previously built with Ant has invariably created more problems than it solved. In one case Maven started to take up so much of our time that we eventually migrated back to Ant again.

I think Maven could be worth the pain if you're building a large number of projects that all depend on each other, and development is widely distributed. But if you're building a single application, and just want to do something simple like "build a WAR from the stuff in these directories", then I would run a mile from Maven.

Also, in terms of dependency management, the default Maven behaviour runs contrary to good version management practices. Specifically, IMO a project's dependencies should be checked into version control along with the source code and other resources it uses. However, the default Maven behaviour is to declaratively specify your dependencies which then get "magically" downloaded from maven repos at build-time. So what happens then if these dependencies disappear from the repos or you lose your internet connection? You can no longer build your project! I realise you can change the way dependencies are managed, but I think the default behaviour should be the right behaviour for the common case.

To answer the second part of your question about alternatives: I haven't used it personally, but have heard very good things about Gradle.

Answer 4

Well, for one thing, that survey is hardly accurate considering you saw it on the NetBeans page. If it was conducted by NetBeans (as opposed to a link from NetBeans), then all the more likely that the large numbers of developers not running NetBeans will have missed it. Maven usage is lower compared to Ant, but just how much lower is not really known.

For another, Apache Ant came first. It is still very relevant today because it offers both powerful capabilities and flexibility. Maven encourages a conventional or standardised approach to project structure and build. Most existing projects do not conform to Maven's convention and hence, many projects are simply not bothered to spend the effort to migrate their already well-crafted Ant build system into another, especially if Maven does not offer anything that their Ant build can already do.

Answer 5

Maven can definitely put a cramp in your style. I switched an ant build over to maven because I had a whole slew of projects with interdependencies. I got the build going, but I still don't feel like I have my head around the beast.

A lot of the problem comes down to documentation. The canonical guide is often a forum post or stackoverflow answer to a totally different problem that you just happen upon.

Like this guide to using cargo: http://stackoverflow.com/questions/175621/starting-external-process-during-integration-testing-in-maven/176345#176345, which I found not from the maven-cargo plugin website, but just because I happened to be trolling through stackoverflow.

But when you look at that mojo, and then the cargo page, is it really comprehensible to the average (read me) developer?

Perhaps maven is like capitalism, its the worst except for everything else.

Answer 6

I have only one thing to say : too many complains... Maybe is not the perfect tool, but there are definitely to many complains...Indeed, it adds some complexity and you could hit some road blocks(we didn't found anything unsolvable) but at the end you will see the benefits.

I read a few weeks ago about some guy who spent (this is what he claims) more than 500 hours trying to use Maven...You could write a few Maven plug-ins & build your application in 500 hours.

And by the way, it is open source and if you find a problem please report it or fix it

• if it is indeed a problem I'm sure it will be fixed.
• if it is a good suggestion I'm sure it will be taken into account.

PS. I'm not part of Maven team, just a regular user, nothing more.

Answer 7

As already said, there's a high barrier of entry. There's also tons of older projects that already have well established build scripts/tools - it makes no sense in most cases to replace something that already works with maven.

Lack of/scattered documentation doesn't help either - the only really good tutorial for maven is a full length book written by sonatype... and that's quite alot to ask someone to read and then go learn how the plugins work all for the sole purpose to build/manage a pom.xml to define how a project gets built/managed.

With that said though, maven's a great tool (even if a bit too complex for its own good).

Answer 8

A lot of the Maven gripes I've encountered are listed and answered in this blog entry. My experience is that java developers are used to having full control over their projects. Many of the reasons they're against Maven are basically "it's not ant" or I can't do X like I can in ant".

There are certainly some valid gripes. The documentation is often woeful, the learning curve can be steep, and the configuration is verbose. Because so much convention is involved, when something goes wrong it can be very hard to determine if it's your fault or a feature/bug in a plugin.

So given the negatives, it is understandable that people would be disinclined to invest time and effort in a build tool when you can go with what you know (ant/make/whatever) and get on with "doing the job", after all your customers don't care how sexy your build process is.

Answer 9

Regarding alternatives, the only one I know besides homegrown system using Ant is Apache Ivy

Answer 10

I like Maven and use it almost exclusively in my company. But I'd justify my reasons for doing so:

1. I run a team of developers and we need structure. I need most of my developers to follow a certain set of conventions down to project layouts. This is to make it easier for handovers when attrition occurs.
2. Maven archetypes are a major blessing in this regard. The seniors would just create specific archetypes for certain project templates which all developers just base their projects on. There's a really simple generic one for those cases where we didn't manage to cater for. Checking out an ant-based layout from SVN is less intuitive in this regard as the developer will still need to remove the original .svn metadata once it's checked out.
3. Maven helps us remain IDE-agnostic. I don't want to base any of my hiring policies on what IDE the developer prefers to use. At least 2 major IDEs (Eclipse and NetBeans) have pretty good integration to Maven already such that a pom.xml file already is the definition of an IDE project. I can tell any new developer that he can use whatever IDE he prefers as long as the build system itself is based on Maven.
4. I found that the development bootstrap process for picking up things midway was drastically cut down when I switched to Maven. New developers, even those unfamiliar with the project at hand, was able to at least compile, package and deploy within half hour of briefing them of the project. Support staff (who are typically not as technically adept) were able to concentrate on troubleshooting and not fret about building the project, which is an unnecessary irritation.

All in all, Maven suits my needs perfectly. I do agree to a certain extent that an independent developer who has his own workflow and project management practices may not derive much benefit from it, but none of us over here work in a void by ourselves.

Answer 11

There are a lot of alternatives - in the java and in the ruby community. For an overview look at this picture

Answer 12

My issue with Maven is that one of the main things it does is not a best practice. Maven will go out and download the newest version of any dependency you have. While that sounds good, it is a bad practice. I want the dependencies for my project in my project because I don't want each developer to have difference versions of jar files and I definitely don't want untested dependencies to be used when deploying to prod.

If maven had an easy way to allow me to package the dependencies with the project and not download them for me, I'd use it. For now, I only have it installed because some code I deal with forces me to use it.

Yes, I know that it is possible put a dependency repository in my project and make my project use it, but that is a huge pain. I just want a lib folder in my project and tell maven that those are the jars I'm using. period. I'd much rather write an ant build.xml file than spend tons of times writing pom.xml files.

Answer 13

For an alternative tool, I offer Gradle. It builds on Ant and Maven and supports all of the standard goals (compile, unit tests, etc). The key benefit is that the configuration is in Groovy, which makes for fluid, succinct files. (That said, one will have to learn Groovy, to some extent).

The key point is that it is a false dichotomy to pit Ant-Ivy versus Maven, as many do. I've blogged about this here. (Note that since the blog post, Gradle has superceded Gant as a general build tool.)