Thursday, September 27, 2007

Maven Doesn't Suck, You Suck (And Maven Sucks)

There's been a lot of chatter going on the Maven user list about Maven being too hard. To some extent this is true.

As per usual, it is largely filled with whining about a particular user's difficulty with Maven, and how that is somehow reflective of the technology or philosophy. Normally I wouldn't give these bouts much credence, were it not for the fact that the same discussion has surfaced, oh, about 10 times prior with nary a resolution. Every couple months ago the same points get brought up:

  • Maven docs suck

  • Maven makes mundane tasks too complex (ie. is cumbersome)

  • Maven is only suitable for large projects

  • Maven is only suitable for small projects

Maven docs suck

True, sort of. The Maven website sucks out loud. It is cumbersome to navigate, and doesn't feel so much as being led gently through Maven the Beautiful City, as "wrassled" and "hogtied" to the back of a pickup and drug through Maven the Scattered Trash-Heap. I made a few suggestions on the list, mostly pointing out websites which are easy to navigate (Rails, Spring, Wicket) and then Maven's site. QED, methinks.

If I hear "cookbook" or "taxonomy" as the answer to Maven's documentation problems one more time I'm going to punch the first kitten I see. Set up a goddamn wiki and let people populate it with their own best practices. Stop using Confluence, because it's a pile of steaming elephant shit (A wiki with tight security and roles? No thanks). I guarantee if the front page had a giant link to a MediaWiki installation with bold letters: USER CONTRIBUTED DOCS, people would use it. Hell, I'll even do the first post.

In short my feeling is this: Maven documentation is fine, it's just freaking impossible to navigate. Most plugins are documented well, if you can find them (psst... they're here and here). Or better yet, make them searchable. When I hear "Maven docs suck!" I know what they really mean: "I Googled it and the answer wasn't on the front page!". Moreover, make a good wiki for anyone to post their problems and solutions. Finally, stop using Nabble - because it kills Google.

Maven makes mundane tasks too complex (ie. is cumbersome)

Again, this is true, sort of. These are the same complaints I heard about C from ASM users, and C++ from C users, and Java from C++ users, and now, Maven from Ant users. I can do anything I want in Maven... for course, that's because I know the core and most of the plugins fairly well. If I don't know the answer, I know where to find the docs, and finally, check out source code if I really need to know. So to this I can say - it's not Maven that sucks, it's you.

However, this is a terrible attitude to take, and I apologize for whoever wrote the previous paragraph. Because most people just want to get their milk, not buy the whole cow. That is one of Maven's problems. It is not just the documentation that sucks about Maven, it is its usability.

How do you get help from the command-line? mvn -help is nearly useless, and the help plugin is nigh-unusable (though, thanks to me, the new "-Dmedium" flag has gone a long way to making it easier). Of course, that is only meaningful if the plugin/goals are commented well, which they often ain't.

How do you write a POM? XML by hand? No way, says I - I write mine in yaml. But more to the point, there is a distinct lack of IDE support. Someone once said about Maven: "working in the command-line is like working in the Stone Age". I can't wholly agree, however, your average user would be fine with a few wizards, or at least, command-line editors (pomtools was a good idea, but kind of died). It's been over 2 years now since the release of Maven 2, and we are just now getting to the point where IDE support is getting decent. Decent, but still a ways to go. Maybe in another 6 months? Stay tuned.

How do you copy a file from point A to point B? This question gets asked probably more than any other. It wouldn't be so funny if it weren't the case that there are nearly a dozen ways to do it. But in this case, it is both a Maven and user problem. A Maven problem because such frequently asked questions should have an easily findable answer. A user problem because these kinds of questions always come from people who don't understand the fundamental shift of Maven in thinking. There are a dozen ways to move a file, because there are a dozen different reasons to move a file. Moving the web.xml file to the packaging directory is done by the war plugin, because it makes sense when creating a war. But it is not done when creating a jar, by default, so it will just sit in your project. If you want to make it move, add it into your src/main/resources directory and viola, it'll get packaged up too. If you want more control, then use the antrun plugin. If you don't like Ant, use jruby or groovy or write some Java code to do it.

One of the problems with Maven is it's run by a bunch of purists, who won't make mvn -help just execute a "help" goal. Or refuse to wave good-bye to the stone-ages and insist on keeping with XML-based configurations. Drools 2 sucks, Drools 3 rocks... why? Because 3 dropped the XML, making the syntax nice and terse. Maven should learn this lesson.

Maven is only suitable for large/small projects

These aren't really fair complaints, but I hear them often. I use Maven for both large and small projects without much problem, I don't even think about it. Both of these complaints can really be chalked up to user misunderstanding, which then can be chalked up to poor documentation and usability. Which brings us right back to where we started.

This was a fun exercise, but where does that lead us? Back to the same old answers: wait for IDE support, documentation is slowly improving, we need more community support. Finally, may I make a small request? There are at least two commercial companies selling Maven support - can one of you, please, hire a goddamn graphic designer to revamp the homepage? Pleeeeeaaaassseeeee??? It's really, really ugly. This coming from a guy with a plain-white blog.


Robert Scholte said...

I recognize these complaints from the few java-teams in our company. We've got our own 'builder' which makes use of Ant and was created before the Maven2-age (I guess during maven1-alpha...). They fear the migration to maven2. The most difficult part is that some projects have more than 1 sourcefolder (thanks to eclipse).

Talking about wishes: I wish there would be a way to add some company-configurations to a maven-zip. This could then be distributed among all developers. By unpacking and when running maven for the first time they only have to give their name, email-address (and some other personal stuff) et voila! Maven is company-proof, including profiles, repository-mirrors, etc.
This way it's almost out-of-the-box, and you only have to learn the most important commands.

Keep up the good work!


Anonymous said...

we have our maven installation in version control. Every developer has to check it out and thats it. there is an example for the userspecific settings, where the plain xml syntax is quite easy it is just a really simple profile. To setup some paths and other attitude based developer unconformist things :)
basic repositorys are put in this installation too.

if there is a new maven version we put in cvs and tell every developer to upgrade thats it (ok we did it, only once yet, but it worked flawlessly)

Mike said...

You already know this, but this is a fantastic post.

Eric said...

Thanks Mike - I didn't!

Robert Scholte - you should take a closer look at Maven 2. The settings.xml files went a long way toward user-customized installations, however, not completely, since those settings files still need passed around. Enter: zeroconf. A little bird told me that someone is creating a server you can run which configures a user's setup by just running a goal... it discovers the server for you, which generates and installs a settings.xml file for you (using current credentials - I believe using LDAP right now - to customize per user as well). Talk about viola! Downside? IIRC, it's not free.

Tom Davies said...

As a former Confluence developer I must admit to being just a tiny bit miffed that you describe it as 'a steaming pile of ...' just because it has features you don't want to use. It is simple to allow any registered user (or indeed any anonymous user) to edit anything. And I mean simple -- not 'simple by comparison to Maven' :-)

David said...

This BLOG POST SUCKS. AND YOU SUCK for being so apologetic for one of the worst tools to ever curse the Java community. I used maven 1.x and 2 for the last 2 years and the little good maven offers is vastly overshadowed by the bad. Let me help all of the uninitiated out: DON'T USE MAVEN.

mojavelinux said...

Wow, this post is just...true. Amen brother. A lot of people have wasted breath on Maven 2 complaints, but you nailed it.

However, I think it is due time to start wailing on Eclipse. I blame the lack of IDE support on Eclipse's lack of multi-module project support. I hope IntelliJ kicks ass with Maven 2 support in 7. NetBeans gets the nod as well. I believe one other commenter mentioned the "all code in one project" fiasco.

So lets drop the purism and get mvn -h and a real IDE!

Eric said...

The funny thing is, ther are actually two Eclipse plugin projects in the works. But you are right, until Eclipse can handle nested projects most of the other points are kind of moot. The chilly fact is, Maven and Eclipse file structures are just plain incompatable - as it stands.

I have an IDEA 7 license, and really need to check it out. I've heard the same, that the support kicks ass. Maybe I'll check it out and do a write-up on it.

Anonymous said...

I've been a proponent of maven for quite some time. I love the idea of it. I hate it for all of the reasons stated, plus a few more including lack of J2EE project support. I've recently hit the wall with a maven project and will likely have to convert it to ant. The latest addition of dependencies pushed me into this bug:

Notice that this bug was reported in July and has yet to be assigned. Is anyone still working on maven?

Tim O'Brien said...

2+ years since Maven 2 and people are just now getting around to:

1. Using attributes in XML
2. Completely ruling out the idea of a YAML POM.


Sherif said...

Great article about Maven and YAML files. I use YAML files with the Symfony framework, and I find them much better than bloated XML files.

Regarding Confluence vs MediaWiki - well I have to completly disagree with you. Confluence is perfectly suited to the Enterprise. Security allows it to me. With Media Wiki, Its much more complex to create groups and organise permissions - and is much more open. Which is great, but when you have a company of 10,000 employees, and people want to restrict pages - Media Wiki is a nightmare, we use Confluence, with over 1500 active users growing by around 20 users a day - its perfect for our needs.

Lukesterx said...
This comment has been removed by the author.
Lukesterx said...
This comment has been removed by the author.
Lukesterx said...

I just want to say thanks to everyone. The negative and positive comments really helped me to put together a document for work on why we should use maven to manage our binaries. Please see if you are curious.

viagra online said...

I like this text: "Talking about wishes: I wish there would be a way to add some company-configurations to a maven-zip. This could then be distributed among all developers..." is very interesting!! thanks for sharing!