2009-09-01

Maven -- the right idea implemented by the wrong people

I am in the process of adopting Maven for a project I am working on. I didn't do this on a whim much in the same way you do not decide, on a whim, that it would be fun to find out what it would be like to have an organ transplant. You do it because you have found the alternatives to be even less pleasing.

Adopting Maven is painful. You can safely ignore anyone telling you otherwise.

I decided to adopt Maven for several reasons. The most important reason being that I agree with the fundamental ideas behind Maven; small core with most of the functionality in plugins, convention over configuration and some appealing aspects like archetypes. Those are all ideas that I have tried to imbue my own software with and what I have been preaching to others when designing software.

The other reason was that a few people I trust recommended I do it and they recommended I do it now before the project amasses any significant bulk. Most of them were honest enough to say up front that it would be painful.

Despite what I am about to say, I still find it likely that adopting Maven is a good idea in the long run for my current project -- but I will most likely avoid it for projects that do not have significant dependencies.

While I think the basic premises for Maven are sound, a lot of the plugins I have come across have been written by people who should probably not write software or who should make more of an effort and start thinking about what they are doing rather than publishing that which is unfit for general consumption.

Maven appears to be the right idea implemented by the wrong people.

(...referring largely to the mass of Maven plugins rather than the Maven core)

Unintelligent output.

You can learn a lot about a programmer by looking at the log output that his or her software produces. Some programmers write software that log frugally, and when they do emit messages, every message is helpful. A helpful message gives you all the information you need in a way you understand while not including any unnecessary information.

When I look at the output from a typical Maven build I am dismayed at how much irrelevant rubbish it spews forth. Most of the messages should never have been in the console output because they display absolutely no helpful or necessary information. And a lot of the output you DO want to see, lacks critical information.

For instance, whose bright idea was it that when a test fails, you say which test failed, but not what line number? Yes, I know that you can find that in the surefire logs, but I don't want to have to look at them. When I do a repeated build to run my tests after a change, all I want to know is if the tests ran fine, and if there was a problen, I want only the relevant information: file, line number and error condition.
Did the author of that code forget to ask him- or herself what the user might be interested in?

Another annoyance is that you rarely know "who" says what. What plugin logged a particular message? If plugins insist on being chatty then at least they should have the courtesy of introducing themselves. Since I am in the process of adopting Maven, there is a lot of trying to figure out which plugin is complaining and which plugin is trying to do something it shouldn't be doing.

Output of the form "Tried to parse a file and there was a syntax error of type XYZ" is a terribly unhelpful message to begin with, but it is even more unhelpful when you do not have the faintest idea what plugin generated it.

Documentation

If you do not provide simple examples for your plugin inlined in the docs you have not yet documented the plugin. It is as simple as that.

If your excuse of the day is that "my plugin is too complex" then you are most likely stupid as well as lazy and you need to make your plugin require less complex configuration. Remember, the idea was "convention over configuration".

If you have provided no docs whatsoever you are stupid, lazy and your mother dresses you funny.

Archetypes

Archetypes are a great idea. Archetypes that produce projects that won't build are a terrible idea. Archetypes that blatantly break convention are evil. I am a Maven novice, but even I know that someone should not be writing plugins when three different incarnations of the same generated files show up in as many different locations for no good reason.


Command line help

When I started reading up on Maven I was taken aback by the lack of forehead-touching-ground-apologies, or at least some sign of light embarrassment, over the help facilities available in Maven. Seriously? In these times where people are so lazy that microblogging is hugely popular, do you really think that having to type almost a full line of text, just right, to display the help for a given artifact is such a fantastic idea? I certainly do not.


Concluding remarks

As I stated earlier, I think the basic premises for Maven are sound. Unfortunately, I think there are too many contributors to the Maven universe who simply just aim too low and who need to get a lot better at thinking about what they are doing. If you can't be arsed to do a decent job, then please, consider not contributing -- because the existence of a useless artifact might make someone who could have done the job better not bother. (And replacing it later or duplicating the effort causes even more confusion).

No comments:

Post a Comment