A Technologist Who Speaks Business


3 years ago
It’s Official: I Dislike Maven

Apache Maven is a build tool and dependency management system for Java that aims to solve a lot of sticky problems. I’ve been trying to give it a fair chance because people I respect are fans of it, but after giving it many tries I’ve decided it’s official: I dislike it and will not recommend it to my clients.

Here are the reasons I dislike it. For me, any one of them is enough not to use it but all of them together makes the decision a no-brainer:

1) You can’t check your project out of source control and build it based soley on what’s in source control. This means if you have a project in production, lose all your developers, and then have to try to build it again you’re in for a world of hurt. This is not theoretical: I’ve worked on so many projects like this that it’s becoming a specialty of mine. I’ve worked on projects where nobody even knows the login to source control, much less would they know anything about a Maven repo.

2) It’s too hard to tell what’s going on, especially for newbies and even with a simple build. A newbie can only understand a basic Maven build if he first reads a ton of documentation and understands most of the Maven lifecycle.

3) Dependency resolution isn’t consistent. For example, “mvn dependency:tree” doesn’t always give you the same results as “mvn eclipse:eclipse” or “mvn package:single” when using the “jar-with-dependencies” descriptor of the Maven Assembly plugin. For example, on one project I work on I end up with jaxb jars when I run package:single and eclipse:eclipse, but they don’t show up anywhere when I run dependency:tree. This means I have to spend many, many hours figuring out where these Jaxb (or commons-collections, log4j, etc are other common ones) jars are coming from.

4) You are dependent on too much other infrastructure. In particular, you are dependent on (at best) a corporate or departmental Maven repo that needs care and feeding or (at worst) a public Maven repo. These kinds of things move/go down/get lost, etc. This is not theoretical: I worked on one project where an infrastructure team took down and decomissioned a corporate Maven repo without realizing it and even big boys like JBoss move their Maven repos unexpectedly.

5) Other people can mess with your dependent libraries on you. This means a build that works one day might not work the next day. Even though it isn’t best practice, I have seen with my own eyes in the real world where teams manually change jars in a Maven repo without making them new revisions. If you had the jars checked into source control and tagged/labeled then this would be impossible. This doesn’t only happen in private repos, it happens in public ones, too.

So, anyway, it’s Ant and SVN/Git for me. Sorry Maven.

♦ End

Comments are closed.


Run a SaaS app and want to know how to improve customer retention?

Sign up for our free 5-week email course on combating churn.