I’ve received a lot of hits and discussion concerning my previous post regarding Maven 2 vs Ant+Ivy, and I’m writing a follow up post to clarify some things.
I now firmly believe that Maven 2 is a better build and project management tool than Ant+Ivy. I was wrong.
Yep, I said it. I’m man enough to admit when I’ve made mistakes and that I’ve learned from my experiences. And this is coming from the guy that wrote a (still popular) On Java article for Ant in the enterprise.
I almost always touted Ant + Ivy as a better solution in all cases compared to Maven 2, citing:
- Maven 2 has a steep learning curve and is a pain to come up to speed
- You can’t customize it easily if you just need to get stuff done
- It requires installation of a tool other than Ant
- It just doesn’t work well for very large enterprise projects
And a few other things.
I tried Maven 2 just for kicks one or two times and ran away screaming, “I don’t have the power that Ant gives me! I can thrash out anything I wanted in Ant, but I can’t do this easily in Maven! It takes longer! Maven sucks! God I hate Maven!”
Blah, Blah, Blah. Boy was that an ignorant viewpoint. The truth was that yes, I had tried maven a few times, but I never actually used it longer than a few days and reverted to my beloved Ant. I never truly experienced what it was like over a long period of time in a real working development environment, with other developers and other projects. So I honestly couldn’t judge Maven fairly, especially in the environment where Maven really shines – multiple project teams. Let me explain:
The thing that I loved, and what many others love about Ant is its absolute control. I can do almost _anything_ I want in Ant. Same with the newer script-like build systems like Gradle. It is uber flexible, and I know that if I needed to do something down ‘n dirty, I could hash it out in Ant in a couple of minutes.
If you’re a control freak, Ant is comforting. It allows you to hack out whatever you want whenever you want. But this ability is actually the very thing that makes Ant a poor choice in a team environment. It makes it a really poor choice in an enterprise environment with multiple teams, and here’s why:
Even the most intellegent, super-smart, uber genius-geek that knows everything about Ant will still do things in a way that fits their personal mental model. Even worse, the same uber genius-geek god-of-all-developers is apt to continually insist that their way is the best way, and that they’ve worked out all the kinks, and that everyone should use their oh-so-elegant and super slick Ant build setup.
This is something I see all too often across teams and companies. This mentality actually hurts a team and has a bigger negative impact on multiple teams. The reality is is that one guy (maybe 2 if you’re lucky) is the brains behind the build system. They’re the only one who knows how do things cleanly. They know the best practices, and their environment, no matter how elegant, is often confusing to many people. Their mental model is not always the best one for everyone.
So, you end up having this one (or two) nazi-build-master(s) maintaining a bunch of ant scripts, making them more complex over time (breaking them into separate files because it makes sense to them, but harder to trace for everyone else), and getting upset if other people try to modify them. Then team members that should be allowed to modify the build to meet a new need can’t or are afraid to.
In any event, the overall team productivity related to builds and continuous integration often slows to a trickle. This trickle causes frustration, alienates people and discourages their interest and help, and costs the company money. It is clearly a bad, bad thing.
Maven remedies this all too common situation and many others. Once a few developers use the Maven XML structure and understand what those tags do, they can jump from project to project, as business requirements deem necessary and immediately understand another project’s build environment. That means they can build the software and start testing it right away. This efficiency translates into enhanced developer and team productivity and that means real money saved for the company.
And guess what? Newer developers hired in to the company that have Maven experience can also jump right in on a project and understand its build environment for the most part. That is a big benefit. At my workplace it used to take a new hire almost a week to feel comfortable understanding and building a very large project. After converting to Maven, new hires are literally up and running in under an hour.
But this efficiency is not just valuable for the company. It is valuable for developers’ sanity. I am comforted now by knowing that I can jump from projects at work to a few hosted Apache projects to some other 3rd party projects and, if they use Maven, I am right at home and understand exactly what is going on. I know immediately how to
- download dependency source code
- run tests
- generate JavaDoc and other documentation
- Start up a test web environment if it is a web product
- view a continuous integration environment
- see source control repository details
- understand how the project is broken up into modules
and so much more. That I no longer have to think about these things, things that were very very time consuming when having to manage yourself, even with Ant, is a big load off of my mind. I just don’t want to mess with this stuff anymore. I want to have it all work, not waste my time, and allow me to have my piece of mind so I can go crazy worrying about other things like deadlines. That I can get this piece of mind from project to project and team to team when Maven is employed is a real benefit.
And to my previous comments about Maven not working well in very large enterprise projects because of the possibility for a lot of ‘one off’ custom logic? That didn’t hold. I’m working with a very large codebase at work that sometimes takes over 30 minutes to build, not including integration tests, and Maven fits the bill beautifully. Sure, there are those few ‘custom’ things that we needed done, but we learned to write a Maven plugin or two (as you should) and use them extensively. Sure, I couldn’t thrash out an Ant hack to get what I needed done, but so what – the team understands what these custom plugins do, they are self documenting, and easily maintained and managed in source control by other developers because Maven plugins themselves are fairly conventional and easy to understand once you learn about them. This goes back to continued efficiency…
Don’t get me wrong – there are some gripes I have with Maven, but they’re not really a big deal compared to all the benefits we receive. It is not a silver bullet – nothing is – so you take those few frustrations and set them aside, knowing the alternatives are much more painful. So maybe I’ll call it a bronze bullet?
And so, as JSecurity has moved to Apache and has been renamed to Apache Shiro, we too have moved to Maven 2. We have also moved to Maven 2 at work as well, and we now benefit from some other amazing tools like Nexus that integrate well in a Maven ecosystem.
Overall, life with Maven is good. I’m glad that I was able to swallow my pride, really give it a chance, and in turn reap the benefits. I haven’t used Ant in over a year since switching, nor have I ever felt the need to go back.