DevOps Zone is brought to you in partnership with:

Kief is a software delivery consultant with ThoughtWorks in London, specializing in tools, practices, and processes for the continuous delivery of software. Kief is a DZone MVB and is not an employee of DZone and has posted 19 posts at DZone. You can read more from them at their website. View Full User Profile

Maven: great idea, poor implementation (Part 1)

  • submit to reddit

I've been building Java software using Ant for over 10 years. I've been giving Maven a try every few years since it first came out, and going back to Ant pretty quickly each time, until last year. Early last year I used Maven on a few smallish - pretty much one-person - projects, and found it to be pretty useful, so I decided it may be ready for prime time.

Recently I've begun working on my first build system for a ThoughtWorks project, which happens to be using Maven, and although I've been enthusiastic about the challenge, the weaknesses of the tool are showing pretty clearly.

The idea of Maven is a good one - it's a standardised build system that, off the shelf, does pretty much what you need for typical Java projects, using convention over configuration. Ant, on the other hand, is not a build system, it's a tool that you can use to create your own build system. It's almost a DSL for build systems, but far more flexible.


The thing is, at least 95% of Java projects have pretty much the same set of requirements from a build system. Get my dependencies. Compile my source. Run my unit tests. Run some analysis. Package my artefact. Run integration tests. Deploy. Build multiple modules into a single aggregated artefact. That's pretty much it.

So everyone who uses Ant is using it to do pretty much the same thing, but they create wildly different build systems to do it. As a result, new team members have a serious learning curve, and often require days or even weeks to get set up. Adding tools such as a new code analysis report is not a simple drop-in, and the build system's complexity tends to grow over time.

A typical project's Ant-based build system is as complex, and as time consuming to maintain, as any major component of the software it builds. It accumulates technical debt and adds drag on the project's velocity.

So rather than every team having it's own home-brewed special snowflake build system, Maven aims to be a build system that uses convention over configuration to build any Java project that follows a common pattern. It's become popular enough that other tools can just be dropped in, and a developer joining a Maven-based project could be up and running in less than a day, in ideal cases in under an hour.

Ideally, by using Maven on our project we eliminate the hassle of maintaining a complex build system, because Maven simply does what we need, by default.

This is a worthy goal. Unfortunately, Maven falls short. I'll share why I think this is in part 2 and part 3 of this series.

Published at DZone with permission of Kief Morris, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Thai Dang Vu replied on Mon, 2012/01/09 - 10:04am

I wonder if your project structure is as "weird" as the one I'm working on at my company which uses Ant by the way. This is how it is structured:

  •  There are directories (which are not Maven modules) with their own src directory, webapp directory, WEB-INF directory (of course only one WEB-INF has web.xml because it's not Servlet 3) and build.xml.
  • There's some kind of a main build.xml somewhere where we specify all the directories like the ones above we need in our application. The main build.xml will call some specific targets in the build.xml of each directory to compile classes and finally copy .class files, web-related files to an exploded EAR directory.

The idea sounds nice, doesn't it? because we seem to have independent directories. Actually, there's rarely a case where they all are independent. There's usually a dependency between them or there's another directory that glues all the other directories together.

 Do you think it will be better to switch to Maven or keep using Ant with huge, complicated build.xml files?

Mark Davidson replied on Mon, 2012/01/09 - 10:19am in response to: Thai Dang Vu

I'm currently playing about with a hybrid approach. I use the same folder structure as Maven. I define macros and most targets in a common.xml Ant script which gets imported by sub-projects. The build.xml Ant script in the sub-projects aren't that large as most of the good stuff comes from common.xml. Many of the targets are named after standard Maven goals. I use Maven Ant tasks to resolve, install and publish artifacts (using an pom.xml to define the dependencies). So far it's working OK but it requires Maven and Ant to be installed which may be too much for some. I played about with Gradle as well. It's quite nice but gave up on the idea as no one in my company uses Groovy.

Tomek Kaczanowski replied on Mon, 2012/01/09 - 5:06pm

Gradle seems to be the right answer to your pains.

Christopher Wong replied on Tue, 2012/01/10 - 8:42am

I have my own issues with Maven, particularly its own implementation of convention over configuration (CoC). CoC is a pain when not done right. Maven is verbose without being obvious, which means it lacks the advantages of CoC while bringing in the disadvantages. 

The trouble with being conventional

David Jones replied on Wed, 2012/01/18 - 8:52pm

I just have to defend Maven..... We have 60 projects covering every technology you can think of. Years of bloated ANT scripts and error prone deployments and builds. We converted to Maven gradually and adopted best practice. We now have automated deployments and testing and reproducible builds, library versioning is MUCH easier. The one thing that should be rigid is the build system, creativity can live with writing software, verbose XML code is really not an issue (syntactic sugar is not the problem). We STRICTLY stick with convention, it works and we have a significantly complex, old and new code base. I will never go back to ANT, I've tried both and spent time learning Maven properly, just as I'd spend time learning a language properly. Build systems are not an add on to software engineering, they are part of it! Build systems matter, so many companies never rationalize them.

Darryl Parks replied on Mon, 2012/03/05 - 10:23am in response to: David Jones

I agree with David, Maven is a great tool and solved lots of issues in builds.  I don't see Maven as a panacea and you may still need ANT or another build script for other things, but I think Maven rocks.  What it does, it does well.  Just check out, Maven is taking over.  From what I've seen Gradle doesn't solve any real issues and misses some of the advantages Maven provides.

But if you're idea of cool is coding scripts in of all things XML, feel free & stagnate.  The rest of the world is moving on. 

Sfafaef Adfasg replied on Fri, 2012/06/01 - 10:20am

We have 60 projects covering every technology you can think of. Years of bloated ANT scripts and error prone deployments and builds. We converted to Maven gradually and adopted best practice. We now have automated deployments and testing and reproducible builds, library versioning is MUCH easier. 10mb Internet

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.