Putting your money where your mouth is

By Greg Turnquist

Greg L. Turnquist worked on the Spring team for over thirteen years and is a senior staff technical content engineer at Cockroach Labs. He was the lead for Spring Data JPA and Spring Web Services. He wrote Packt's best-selling title, Learning Spring Boot 2.0 2nd Edition, and its 3rd Edition follow-up along many others.

August 3, 2011

I like maven. There, I said it. Now where is my flame suit?

Last night at the Nashville Java User Group meeting, Kerry gave a good introductory presentation on maven. He talked about the pros and cons, and showed some things like phases, profiles, and parent/child projects. For those who had little to no experience with maven, it was a good introduction. Hopefully they will read more.

I jested afterwards that he should write a blog entry to generate traffic for his web site, because a discussion about maven is never luke warm. People come out either strongly for it or against it. I expressed this at last night’s meeting. Well, sitting here this morning and checking twitter, etc., I realized that I would be a bit of hypocrite if I wasn’t willing to put my money where my mouth was and write my own blog entry.

So here we go. I like maven for a handful of reasons:

  • consistent format of project layout
  • transitive dependency management
  • more plugins than I can imagine
  • declarative definition that supports convention over configuration
  • maven’s one-artifact-per-project promotes a better breakout of modules
Does maven have issues? Yes. What build system doesn’t?
Is it state-of-the-art? No. The XML can be wearying.
These seem to be the two key things that cause people to discard it and seek something else. I have seen this first hand. Instead of using maven, someone typically tries to replicate maven’s intentions using other technologies. If you are on a team where someone has built their own build system there is another dependency that can start to get in your way and come incredibly annoying: that person. Any issues with that build system require support of that person because there is not likely to be any documentation. I didn’t like this aspect, and when that person worked in a different time zone than me or was on vacation, it became detrimental to productivity on occasion.
So what about things like gradle? To tell you the truth, I am kind of excited about new technologies like gradle and sbt. They look very appealing, and I really like the idea of using groovy or scala instead of XML. XML is a strain to read, though for some reason, I find myself reading pom.xml files instead of using my IDE’s editor.
I guess being a command line junky, I prefer to work with the real file rather than a massaged presentation. Probably makes me sound like a dedicated emacs user. While I use vi a lot, I also edit a lot of code inside my IDE. Nothing beats the ability to highlight 200 lines inside my IDE and hit the comment key combo. I use both on equal footing, and it makes me feel like I’m versatile. But…I digress.
Back to the topic at hand: what about new build technologies like gradle? I think a critical feature of tools like gradle would be integration with maven. I understand this is in the core of it, so hopefully gradle will expand and become more mainstream. But right now, I haven’t adopted it.
Go and figure out what meets your needs. But take into consideration what happens when you hire more people. Will you be able to point them at standard documentation, or will you have to be on call to answer questions about your build system? It’s up to you. Just be aware that something like 85% of all java projects use maven. (Okay, I don’t remember the actual number, but according to a survey conducted by the Eclipse foundation, it is a HUGE majority like that). It’s one less impedance mismatch to deal with. Be sure to factor that into your TCO (total cost of ownership).
Whatever you choose, happy building!


  1. Jim Moore

    Out of curiosity, what do you mean by “integration with maven”?


Submit a Comment

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