Maven Love and Hate

We Recommend These Resources

You get away from the large, complex build.xml scenario when you move from Ant to Maven, but depending on the software you're writing, you don't save on verbosity! Right?

I'm a big fan of Maven, and I'm excited about Maven 3. To be fair I've not been using it long - less than 6 months professionally - but in comparison to Ant it seems to be a no brainer.

Like most Ant fanatics I was staunchly opposed to Maven's despotic structure and have to admit that only through ignorance did I not try it sooner. The learning curve put me off too; my assumption was that the words "mvn" and "archetype" were far too alien and I was never going to learn. Thankfully I took the plunge and spent five minutes learning the basics and trying it out for myself.

What I love

Its design. The goal structure is simple yet powerful; it yields so much with such little effort. A quick "mvn install" and I have my web project WAR'd, my library JAR'd, my code compiled, versioned, packaged and ready to ship. Beautiful.

Its reliable and sturdy implementation. It never fails. If something's broken, it's either my fault or a bug in a plugin; Maven's always right.

Its object/hierarchical nature: I can be consistent and organised with very little effort.

Getting up and running with compilation, packaging and versioning in seconds by just typing "mvn archetype:generate".

Most of all, having unit testing out of the box, ready to go means I think of it sooner than I forget it which encourages me to write tests because I have little to do - there's a class already setup for me, and it'll be run every time I compile, so no laziness because "it's a tiny change, nothing will break".

What I don't love

I don't love the verbosity. Well that's not entirely true - verbosity can be a good thing when applied correctly - but with Maven I see level after level of elements describing the plugins that I need configured, the arguments passed to xjc and the like. It just gets quite heavy, and it does so quickly. In the Ant world, using a task was relatively painless; yes it meant your build process got complex and bloated in a matter of minutes, but some things were less...wordy. I wonder, how would an Ant build process perform if it took Maven's concepts and design and implemented it? A colleague did point out the other day though: you're building large & complex software, the build process is bound to be large too.

You know what I really hate? I hate having to configure the maven compiler plugin every time I start a new project. Seriously, cut it out! It's not big, and it's not clever. Yes, I could have a Super POM of my own that defines this, but when I'm hacking together something throwaway I still don't want to have to add a parent section no matter how easy and simple it is.

Another thing: where's the default maven Super POM exactly? :)

Are you convinced?

What are your experiences? Am I just being a typical newbie? How do you structure your projects? Do you see any other pitfalls or issues with Maven?

Disclaimer: I'm not writing Ant off. Apache Ant is a fantastic tool and has its place, I just enjoy Maven more right now.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Roberto Lo Giacco replied on Fri, 2010/09/24 - 2:07am

No Alex, I'm not convinced Maven is verbose, I think it's has a perfect balance between configurability and convention. I personally started with Maven 1 which had a lot of black holes, especially in young plugins: they were evolving at a such rate you could have an entire project build running perfectly on one machine and the same exact project not building at all on the same machine the day ater because a plugin changed a strange hidden parameter or an hidden configuration. Actually Maven 2 does not suffer from this any more and plugins are stable enough, even if I still applies old Maven 1 good practice to fix plugin versions in the POM. When you say you could provide other defaults through the Super POM and thereafter you ask for "where is located the Super POM" I think you are missing something: Super POM is there to provide default values for EVERY POM, if you want to provide defaults to YOUR POMS you should install or deploy (depending if you want to share your defaults to others or not) your own PARENT POM. Changing the super POM is very dangerous, but having your own parent POM is good practice and I actually prepared one for my previous company describing in its contents the company defaults: directory structure, checkstyle standards, maven repository location and stuff like that. We ended up in per project POM a lot less verbose and highly maintenable: we all loved that parent pom making our lifes easier! I've not still tried Maven 3, but I'm quite sure I'll love it too.

Alex Collins replied on Fri, 2010/09/24 - 2:17am in response to: Roberto Lo Giacco

No, there's a Maven super POM that I'm referring to - the default super POM - that I'm *jokingly* asking its location. I was referring to having my own super/uber POM (what you call parent POM) that defines the compilation/target version which every new project/prototype would extend so I don't have to reconfigure the POM of my new code to compile in 1.6. This is what I was referring to in the article. As for verbosity "A colleague did point out the other day though: you're building large & complex software, the build process is bound to be large too."

Mladen Girazovski replied on Fri, 2010/09/24 - 4:35am

I love Maven2, there is nothing i "hate" about it.

IMHO the biggest mistakes people make wenn applying maven:

1. They have no one experienced with Maven 2, pushing a novice to create a complex automated build, leading to point 2

2. They do not read the documentation carefully, leading straight top point 3

3. They are using it wrong, trying to make maven do something the way they want it to do it instead of going the maven way.

BTW., there is only 1 (one) Super Pom for Maven, but you can have as many Parent/Company Poms as you wish, usually there is (or should be) a Parent Pom for each kind of Project (Java 6, Java 5, w/o OSGi,, etc. pp.)

Alex Collins replied on Fri, 2010/09/24 - 6:11am in response to: Mladen Girazovski

I already stick as close to the Maven way as it were, and rarely come across a build necessity that requires me to think outside of the Maven box. I know what you mean, Ant lovers will habitually fall into implementing customised build processes when they should rethink what they're doing but tend to implement things their way because that's what they do in Ant. I personally don't do this, as I've stated - I'm a Maven convert. And for the record, I forced myself to read the documentation thoroughly. In fact, there's a "Maven in 5 minutes" page in the official docs that is perhaps there to alleviate the lazy/impatient who are trying out maven for the first time. It's very effective at getting to grips with the fundamentals before diving in. Helps with that initial steep learning curve.

Kristoffer Pete... replied on Fri, 2010/09/24 - 6:24am

My main problem with Maven is the release plugin. It seems very nice but once you start relying on it in a slightly complex project, it just falls apart.

Mladen Girazovski replied on Fri, 2010/09/24 - 7:58am in response to: Alex Collins

I've seen some scary stuff labeled as a "maven build", where the developers would all think that maven is unstable by definition... of course the mistakes where not on the maven side.

One time, there was a team trying to build a multimodule project with "mvn package" and got really confused("it doesn't work, now it works, not it doesn't work anymore, but it works on the developers X machine..."), the same team also thought it could force maven to not use dependecies anymore but instead reference artifacts directly in the target directory of another module... of course the blamed maven for their faults, those weren't former Ant users, but even worse: make users.

Alex Collins replied on Fri, 2010/09/24 - 9:39am in response to: Mladen Girazovski

Hah that is *nasty*!

Fabrizio Giudici replied on Fri, 2010/09/24 - 10:39am

As it has been said, you have to define your super POM (and, hell, including it in every project is just a matter of a few seconds). Either you define your own, by augmenting it step by step with your experience, our you start with something such as Maven CALM: http://www.theserverside.com/news/thread.tss?thread_id=55075

Since you're not using any super POM at the moment, I suggest you to try CALM. It is in my intentions to move from my own super POM to CALM as soon as I find the time to do.

Alexander Smirnov replied on Fri, 2010/09/24 - 2:02pm

Don't forget the biggest difference between Maven and Ant:

Ant is build script ( aka programm ) while Maven pom is project description. Therefore, every developer writes build.xml in its own way, invent the wheel with custom tasks and libraries. It's often hard for human to understand build script from mature and long time evolved project, and rarely possible for computer programm.

In the Maven case, build description is very formal, so it can be easy imported to any modern IDE - no restrictions to particular environment anymore, every developer free to use his favorite tool. Actually, I use Eclipse and Netbeans togever, it depends where particular feature better implemented. Hudson build server also understand Maven build very well and will create much more accurate build report for it.

Tim Boudreau replied on Sat, 2010/09/25 - 10:56am

I detailed some of my complaints about Maven here. In my experience, where life starts to really get horrible with Maven is

If you actually break out your project into a lot of small projects, and you routinely make changes in multiple projects at the same time you will find a huge amount of your day is spent cleaning and recompiling things (meaning running tests you don't need to run, checking for updates to libraries you already have). If you really have just one big project, that's not going to be a problem; also if the product is mature and typically people work on just one project at a time, this may not be a big deal.
When you do need to do something custom, what that customization actually is ends up embedded in a Maven plugin - that is, for anyone new to your build, it is not at all obvious what a given plugin does, where as a few lines of script would be very clear

Fabrizio Giudici replied on Sat, 2010/09/25 - 12:30pm in response to: Tim Boudreau

... but you can easily e.g. use the gmaven-plugin or the ant-plugin and bind a bunch of scripting in Groovy or in Ant to any phase of the lifecycle, without having to write a plugin.

Re: IDE independency, it's true. It's also true that all your projects, being JSE, JME, JEE, NetBeans Platform, Android, whatever, get all the same structure, which means it's easy to manage them, e.g. to add QA metrics etc... In other words, mvn findbugs:findbugs just works for any kind of project out there (while with Ant, you have to put your hands on possibly differently structured scripts).

cowwoc replied on Sat, 2010/09/25 - 11:12pm

Maven is great for common tasks like compiling or packaging Java files. It is extremely painful if you try doing the littlest thing outside of its comfort zone.

The idea behind Maven is great. The implementation is repulsive. There is absolutely no good reason for it to be as verbose as it is. Make no mistake: its verbosity has nothing to do with readability.

Jose Maria Arranz replied on Sun, 2010/09/26 - 5:17am

"Maven is great for common tasks like compiling or packaging Java files. It is extremely painful if you try doing the littlest thing outside of its comfort zone."

"... but you can easily e.g. use the gmaven-plugin or the ant-plugin and bind a bunch of scripting in Groovy or in Ant to any phase of the lifecycle, without having to write a plugin. "

Maybe is me, but I CANNOT UNDERSTAND WHY some kind of scripting in Maven IS NOT TIGHTLY INTEGRATED YET, for instance Ant.

Building process is a special kind of programming, nothing is wrong with imperative programming, declarative programming ALONGSIDE AND MIXED WITH imperative programming is EVER a win-win solution.

These days we are into the crazy of rigid-declarative programming, making simpler the simple and much harder (almost impossible) the complex.

I think many tool providers suppose that, we, developers, are stupid monkeys who need magic tags to solve ANY problem. The reality is the number of tags and attributes increase and increase trying to cope any casuistic. It is like a very rigid programming language ever adding new keywords instead of providing flexible Turin-complete artifacts and optionally methods for the most typical tasks.

Is the world upside down, in a place where scripting is the definitively the BEST option to provide extensibility to a build tool, Java (for plugins) is the ONLY option provided by default in Maven... is crazy.

Advice 1: be very cautious with any kind of tool promising 10% less work with the added risk of 500% more work when something relatively different or complex is found.

Advice 2: be very cautious with any kind of tool promising 10% less to learn with the added risk of 500% more to study when something relatively different or complex is found.

Advice 1 + Advice 2 sumarize in: pick the tool with the right level, the more high-level the more rigid, the more low-level the more time consuming.

The problem of Maven is that it is too high level.

Tim: the more I read your comments the more I value your experience and way of thinking :)

Mladen Girazovski replied on Sun, 2010/09/26 - 6:07am in response to: Tim Boudreau

Hi Tim

If you actually break out your project into a lot of small projects, and you routinely make changes in multiple projects at the same time you will find a huge amount of your day is spent cleaning and recompiling things (meaning running tests you don't need to run, checking for updates to libraries you already have). If you really have just one big project, that's not going to be a problem; also if the product is mature and typically people work on just one project at a time, this may not be a big deal.

Running a build inclding tests should go really fast (you ain't doing slow integration tests in the same module, as recommended by the maven best practices, right?), checking updates for libraries that you already have means that your repository manager is probalby configured wrong, maven should check for updates of snapshots only once a day.

When you do need to do something custom, what that customization actually is ends up embedded in a Maven plugin - that is, for anyone new to your build, it is not at all obvious what a given plugin does, where as a few lines of script would be very clear

"scripting" is not what maven is about, if you find yourself often having the need to script and roll your own show instead of sticking to the maven conventions, maven2 is not for you, try gradle instead.

Mladen Girazovski replied on Sun, 2010/09/26 - 6:10am in response to: Jose Maria Arranz

hi Jose,

there it is again, the "scripting argument".

As i said before, if you want scripting, you don't want Maven2.

This seems to be the most common misunterstanding with Maven2, but the documentation etc. clearly says, that Maven is not a build tool that is configured/used by scripting.

Jose Maria Arranz replied on Sun, 2010/09/26 - 7:20am in response to: Mladen Girazovski

"As i said before, if you want scripting, you don't want Maven2."

Bad solution because Maven is becoming a de facto standard on development software distribution.

Mladen Girazovski replied on Mon, 2010/09/27 - 7:50am in response to: Jose Maria Arranz

Yes Jose,

Maven2 is becoming a defacto standard, good news for you is, that the core of this defacto standard is the maven repo (including layout), so, if you use gradle or ant+ivy, you can script, and still deploy to an Maven repo wich can be used by Maven, Buckmister, ant+ivy or gradle, etc.

Jose Maria Arranz replied on Tue, 2010/09/28 - 1:58am in response to: Mladen Girazovski

Yes fortunately :)