Arrogant Maven, You Fill my Soul with Hatred

Unfortunately, I have to do work with java a lot. But even more unfortunately, I have to cope with a bloated all-in-one build tool called maven. Today I was doing a local build for testing some changes in a web application and typed the usual command:

$ mvn -Dmaven.test.skip=true -Denv=local war:war-exploded

For the curious, this builds a web application. Notice how I've specified "maven.test.skip=true" - this means to skip testing and just go straight to the build. That's right, maven by default wants to run unit tests for you amongst other miscellaneous tasks unrelated to compiling code. The problem is, by munging this functionality into one tool, the other roles of the tool are taken for granted - our association with it is linked most often to its primary role (building a jar or web application). Many developers pick up the habit of always using the skip tests flag because the perception of testing in the context of a build tool becomes: "Oh, that's the thing that slows down my build."

My argument is almost a wash, because ultimately unit testing on any production code base should be done in automated fashion leveraging tools like buildbot. Nonetheless, in an ideal world, a developer should assume the responsibility of running tests before pushing changes to the repository. I believe the steps to follow become clearer to a developer when these roles are cleanly separated into the right tools for the right job. A generic example:

$ build
$ runtests
$ generate-docs

Yes, maven wants to do all these things for you (and oh so much more) because the developers failed to appreciate an important tenet of the Unix philosophy: "Make each program do one thing well." maven might be argued to do a few very simple things well once you've spent a few weeks mastering its dense XML-based configuration. Even once you've mastered the ugly nuances of the project object model, transitive dependencies (which invariably get in a tangle when you introduce in-house repositories), site-specific configurations (which often breaks maven's design for portability), the convoluted plugin system, etc., etc., you just end with radically different aspects of a project's build life-cycle all munged into one tool. And developers on your team who are smart enough not to waste time becoming a guru at all this mess, will only learn:

$ mvn -Dmaven.test.skip=true ...