Maven: great idea, poor implementation (Part 1)

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.