Ant vs Maven Argument…

Nope, you aren’t getting one here. I’ve argued Ant over Maven dozens of times in my life. Most recently, last night. 🙂 But, I’m not gonna start the argument again.

That said, my friend Pete has a post on his blog trying to pull me offsides again. He was the cause, last night over a few beers after our monthly Java user group meeting, of my most recent, and last, argument over Ant or Maven.

It’s just not worth the fight. I personally love Ant. It’s crazy-flexible. It can do anything. It can do anything, the way I want it done. It doesn’t force me to do things the way I don’t want to. Ant is easy to use. There is no learning curve.

Maven makes my head hurt. To get a team of developers up to speed on Maven is miserable. Ask Pete on his blog about the time he tried to push Maven on a team last year at MMA. It was ugly. Maven is a technology that makes you change everything you do. Nothing about it feels natural. It actually hurts to use Maven.

That said, I wish I was using Maven today. 😉 Kill me for saying that. It’s a love – hate with Maven. I’m at a new company and our standard tool is Ant. I just left Countrywide where they use Maven. I was forced to learn it and use it. I hated it…. Now, I miss it. 🙁

Pete, I hate you. 🙂

8 thoughts on “Ant vs Maven Argument…”

  1. Don’t worry, we still hate Maven too. Next project will revert back to Ant. We waste way too much time screwing with POMs and hidden dependencies. Maven is great for people with excessive time on their hands.

  2. Hate to hear that we lost one to Ant. The trick to a successful Maven implementation is a company Maven repository fronted by a MRM (Maven Repository Manager) such as Artifactory, Archiva, and there are others. There are other tricks but I think the company Maven repo and MRM are one of the easiest tecniques and gives the most “bang for buck” as far as easing the adoption of Maven. Tim, I’m curious to know if you guys used such techniques.

  3. We mirrored a Maven repository to cover the artifacts we needed and created our own base POM for internal applications. The major annoyance of Maven isn’t really Maven faults. The problem is in dependency management, and in particular, the transitive dependencies. We are always running into scenarios where we end up with multiple versions of the same library because we’ll grab a specific version, then grab a library that has that same library as a dependency. Invariably, it will specify an older version, so I end up with multiple copies. Another major annoyance is lack of naming consistency. Again, this comes in with the transitive dependencies, where one library might depend on jakarta-commons-logging and another on commons-logging and a third on apache-commons-logging. And, of course, they will be three different versions. Maven needs to come up with atomic URI-style references to libraries so it can detect overlaps.

  4. A bit of disclosure for people… The seven months I was using Maven was while I worked for Tim. So I know exactly what he is talking about. People try to use Maven’s transitive dependency support as a positive, but as Tim has said…. it’s more of a problem then a positive.

  5. Agreed, transitive dependencies can be painful at times, however for me they are more HELPFUL than PAINFUL. Case in point, if an app uses Spring, Hibernate and an MVC Framework, w/out trans-deps one would have to manually provide ALL dependent jars, which my guess would be over 20. With trans-deps all that is necessary are the main jar files, which is around 3-4 with the above mentioned app. And yes, commons-logging is a pain point in the Maven trans deps world, you guys may have already used this but one technique to get around it is to use the tag. For a good example of this technique take a look at Matt Raible’s AppFuse2 pom.xml. Like anything else, once the “mountain” is conquered all other “mountains” look like mole hills.

Leave a Reply

Your email address will not be published. Required fields are marked *