Every 3 months or so, you’ll see a new article pop up somewhere written by an Ant (mostly, sometimes Gradle or Rake) lover discussing the horrible nature of Maven and how it works.
People, please! How old are you guys? I’ve used both and I like Maven more. Is that a reason for me to post another rant on Ant? Seriously, most rants are one-way. It’s easy to break down a tool based on some criteria, but how about proposing some solutions to problems some Maven users face that you can easily solve in [your favorite buid tool]? Whoops. Negative criticism is easy, isn’t it?
Recently, I read this article. It doesn’t take a genius to discover that this blogger is a Maven hater. Or to put it more bluntly: it doesn’t support the way HE wants to build software. Here’s an idea: try and take every feature you hate in Maven and give a Rake or Ant alternative way. Every single one. I’m waiting for the excuses you’ll throw at me.
Let’s see. According to this blogger, it’s really hard to build a war. Last time I built a WAR with Maven, I just needed to change the packaging to WAR. Okay, you do need to know that the WEB-INF folder goes into src/main/webapp. Is that really that hard? The other rant was about the WAR size. Here he actually has a (albeit minor) point. Maven projects (especially frameworks) really need to learn the value of optional dependencies. But then again, I’d like to see Ant projects solve this issue too without their usual solution: provide a README stating which jars should be included when you want to use certain functionalities.
I’ve heard the statement “Why use an entire toolbox (Maven) when you only need a hammer (Ant)”. Okay, you CAN put a screw in a wall with a hammer. The result ain’t pretty, but it works. Does that mean a hammer is the only tool to use. No. Know when to use a tool. Any tool for that matter. Would you throw the screwdriver out of your toolbox because it can’t handle a nail?
Any of the rants can be translated into either incorrect use of Maven or just plain stupidity (or even lazyness): I can point out a lot of Ant, Gradle or Rake misuse that is equally painful. Dependency resolving takes to much time? Use Artifactory or Nexus internally (it’ll even solve some other problems concerning snapshots). Got problems with plugins? Stop omitting the version number in your POM’s (or use a company-wide POM). Too many unused transitive dependencies that should be optional? Contact the author. Got a problem with XML POM’s? Maven 3 has polyglot functionality.
All I’m saying is: stop ranting. Either come up with non-abstract solutions, or shut up. Ranting is easy. Coming up with solutions using your own solutions is less so.
#1 by Martin Ellis on 2010/01/02 - 19:35
Quote from said rant: “Every project’s build process is unique”
Great way to make life difficult for your colleagues. But I still prefer putting drawing pins on their chairs when they’re not looking.
#2 by John Ferguson Smart on 2010/01/03 - 04:05
Nicely summarized, well put.
#3 by Marco Ehrentreich on 2010/01/03 - 11:52
“Great way to make life difficult for your colleagues.”
Exactly! Those people are only happy if things work the way they are used to – no matter if it makes everything difficult for others.
I personally prefer Maven because it makes things easier for me. It’s not a perfect solution for everything but it works quite nice if you know what you’re doing. And it surely doesn’t make typical tasks more complicated than it would be with other tools. As already pointed out above you should take care to use an internal repository manager, provide company wide POMs etc. to make the build process consistent within a company or team. But you’d have to do this in some way with other tools too. No matter if you use AntTasks or Maven plugins, no matter if you have JAR files for dependencies or some entries inside a Maven POM. You have to deal with the same problems in an appropriate way for the tool you want to use.
But I think it’s generally good to have a choice between different tools like Maven, Ant, Rake or whatever. So you can and should choose the tools which fits your needs better. Or you could even use multiple tools if this makes life easier. But I’m pretty sure that there will never be any tool which is the perfect solution to any problem or everyone’s personal taste.
What’s funny with these rants against one tool or another is that it’s easy to see that those people never took the time to learn at least the basics about the tool in question. They are complaining about problems which simply aren’t (major) problems if they’d really know how it works.
For example with Maven (I’m more familiar with Maven) it should be obvious for everyone who took the time to read a few lines of documentation that you’re going to create your own problems if you don’t want to stick with Maven’s conventions regarding directory layout etc. Why do such folks choose to use Maven if they prefer to make every build process a unique adventure?
Marco
Btw. I already posted a comment here:
http://blog.lick-me.org/2010/01/maven-sucks/
#4 by Jeff Darcy on 2010/01/03 - 13:54
I’m not going to pick on Maven as such, but I will say something general and if it applies to Maven then Maven really does suck. Language-specific build tools and package managers are a bad idea – one among many for which we can probably blame Perl. Build tools that try to do package management, subverting the system package manager, are broken. Build tools that pull in stuff from the net, without prompting or proper version checking, are broken. Repeatability of builds is an important software-engineering feature, and all of these “capabilities” make builds distinctly non-repeatable across machines or even on the same machine across time. Anybody who’s actually worth their salt as a software engineer will prefer to use the system package manager to manage dependencies, and a language-agnostic build tool to do builds.
#5 by Jason on 2010/01/03 - 14:47
Thank you very much for a very level headed discussion about Maven.
I switched to Maven about 2 years ago and joined a company 6 months ago where they are scared to death of Maven (or change for that matter). Many people are afraid when they see how easily code inspection tools can be integrated into Maven or how quickly it can generate an entire website or PDF documentation for you. Unfortunately being a developer who holds all the secrets of the build, the code, the documentation, etc is really hard to give up.
If all you need to do is make a build, perhaps Ant is the right tool for you. If you need your build script to make multiple WARs then perhaps you need a -Profile added.
Maven can be hell to configure sometimes, but usually the Matt Raible’s of the world have that figured out for you already.
Bottom line is we are all trained computer people. Part of our job is to grow and learn new things.
Great Article!
-Jason
#6 by Jason van Zyl on 2010/01/03 - 21:04
Yes, but consultancies when in place get paid to write anything. If they can convince the client that its development infrastructure is a unique snowflake then they get paid to develop the infrastructure as well. From development, testing, QA, and provisioning. Large services-dominant companies have know this for years. How do think these companies generate revenue and grow?
They not only need new clients, but they need to leave their consultants in existing clients or it’s a cycle of zero or little growth. All of these companies from the largest to the smallest sing that open source is beautiful and efficient, but they often contribute the point solutions into the OSS environment. Anyone who has ever done real software development knows that point solutions are not what an organization needs, but instead they need holistic solutions that can be reused across the organization.
Services-based companies harbor these holistic solutions internally because it makes them far more efficient as a companies. They talk about them in public, but are generally not codified in any meaningful way publicly because it would enable their competitors. It’s a dirty little secret in the industry that development infrastructure can generate a huge amount of revenue, and it’s one of the aspects that remain when projects are complete. When the development infrastructure is unique, you are at the mercy of who created them.
The point solutions may be good, but when assembled in variation yields a large number of permutations which is simply to hard to manage at a macro level. This is why Maven, for it’s flaws, bugs, lack of documentation or whatever else you want to call out, has spread like wild fire. It’s also not like the Maven developers are sitting on their laurels. Maven is improving on a daily basis. It’s not like it’s a static entity that you can just point to and say “that’s wrong.” We are adjusting to user requests but we get 600k unique visitors/month to Maven central so we have to deal with the users who have adopted Maven and make sure it continues to work as expected while we in parallel make improvements.
This is the subject of a larger blog entry, but I have managed to convince some of the largest companies in the world to sign NDAs amongst one another to show them that their infrastructures are not unique snowflakes and that they should be extremely leery of people internally in their own organizations who posit this view, and the services companies who also take this position. It just leads to many silos within an organization and then once a product hits production it’s then argued that the entire chain of infrastructure and practices which accompany it must or the project will be “at risk”, or “may potentially fail.” and then it’s extremeley hard to coalesce a set of tools and practices. Sure Maven has shortcomings but we are starting to get many organizations contribute to the improvement of Mavne in conjunction with holistic solutions which we hope become useful to many.
#7 by better builds on 2010/01/03 - 21:05
To use Maven is to hate Maven. However, Maven a necessary evil of java development. Someday something better will come along but for right now, Maven is it. It’s perfectly fine for people to rant about it since it sucks big fat hairy monkey balls, and deserves every bit of the criticism – that’s how things improve.
#8 by Alan on 2010/01/04 - 20:51
Like you, I’ve used both Ant and Maven. For my day job, we can afford a build master(s) along with 40 developers, etc. Ant makes sense when you can afford people to devote themselves full time to the build-deployment-integration cycle.
For smaller projects, I’d recommend Maven. This is not because I don’t think Maven can scale up to big projects. It’s simply a question of whether a smaller project can really afford a full-time build master. If I’m the chief arch, and I have a choice between spending 40 man-hours/week on a build master or a Java developer, what really makes better economic sense?
#9 by GRO on 2010/01/04 - 20:54
@Jason
“Part of our job is to grow and learn new things.”
@better builds
“Someday something better will come along”
Well said…let’s learn new things and try better solutions:
http://www.gradle.org/
Maven is a useful tool and I don’t know why people compare it to Ant.
What I don’t like in Maven is its big POM files when the project starts to get complex (OSGI + lots of dependencies). After migrating to Gradle, my build scripts became a lot smaller and easy to read and maintain.
It’s not mature as Maven and it’s far from be perfect, but at least my team have a clean and readable alternative to POM and I always have groovy script to handle something more complex.
I know Maven 3 has support to groovy scripts and I’ll give a try sometime soon, but I’m done with Maven 2.
#10 by Marco Ehrentreich on 2010/01/04 - 22:35
Gradle sounds really great! But there’s still one more thing which currently makes Maven the preferred tool for me: its support from other tools and IDEs!
Maven can not only be used as a simple build tool but instead continuous integration servers, code analysis tools and many more usually support Maven based projects out of the box. If you take care to keep your project setup platform independent and that the other tools have access to the same repository managers etc. it simply works. You don’t have to worry because of missing JARs or environment specific artifacts only available within your IDE.
The same is true for common IDEs. Unfortunately Maven integration in Eclipse is as poor as the IDE itself (that’s just my opinion!), but NetBeans and IntelliJ IDEA come with excellent Maven support. And here again: it just works. It works everywhere, with different operating systems without having to modify the project setup. You should just take care for the things already mentioned above like company wide default POM settings or repository managers.
I don’t know for sure but at least I’ve never seen comparable support for other build solutions. The only wide spread alternative is Ant but then again Ant builds are usually unique (at least varying from IDE to IDE) which makes it hard to build a project once and run it everywhere (although I’m aware that most IDEs allow to import/export projects for other IDEs).
#11 by 7zark7 on 2010/01/05 - 14:08
Seeing how many companies just end up rebuilding Maven-like functionality with Ant and other home-brew technologies, Maven is pretty decent.
I’m sure Ivy, etc are nice too, but not as much momentum behind them, and Maven is “good-enough” not to care.
#12 by Alexis on 2010/01/06 - 15:19
“but how about proposing some solutions to problems some Maven users face”
some people do propose a solution, and a neat one: http://buildr.apache.org
#13 by Pål Oliver on 2010/02/15 - 21:13
Nice rebuttal!
Isn’t it funny how many ways a standardized structured file like a WAR absolutely “needs” to be built in so many “special” ways?
Seriously, if there is no way you can get your WAR built with Maven, then there is something wrong with your building _process_ – not your building tool!
Although there are flaws in Maven, the “convention over configuration”-paradigm is something more people could benefit from.
#14 by Chris Kaminski on 2010/10/25 - 19:29
Though I love maven, I can attest that it is a timewaster at times.
Trying to get it to do integration testing with Cassandra was a bit of a chore (but I managed it).
I had no end of build difficulties once when my laptop version of Maven (2.0.3) was different from my desktop version (2.0.6). Yes, that small a difference broke builds, and these weren’t complicated projects.
#15 by Lieven Doclo on 2010/10/26 - 09:51
I won’t disagree on that, but it’s nothing compared to the time I lost using Ant.
Ant tends to lean towards the assumption that every build process is unique and has to be configured that way. Maven goes from the assumption that 90% or more of build processes is similar. Experience tells me the Maven point of view is correct.
#16 by Alech on 2011/03/04 - 15:55
@Gro
I am sorry, but gradle maturity is way behind Maven in term of … pretty much everything. Well, let’s see : integration with Sonar / Jenkins with a maven project : 0 effort, with gradle : you have to configure every aspect of the project so those tools can work properly ( check jenkins sonar plugin about integration with others project than maven).
If you want to enter deep technical matters (sorry about that) Gradle is now a day just able to generate some decent WTP configuration but till version 1.0 it was impossible to modularize a project using build tool, you had to configure project yourself to publish dependencies in a J2EE container… I am sorry but eclipse plugins on maven is way better than gradle eclipse.
Now for top-down people, model driven ones, the folks out there that try to work as little as possible : Where are the model driven plugins for Gradle ? How can I do Fill Water project like HyperJaxB to generate a cxf, hyperjaxb, jaxb, jpa, hibernate drived CRUD web services with controls and everything model driven ?
Don’t abuse yourself, Gradle is just a remake of Maven, trying to add some ant perspective but still it lack lot of maturity for 1) plugins 2) integration. We may agree that core is maybe a bit superior to maven 2. Maven 3 polyglot is really close to gradle with mature plugins.
A