Why Maven is a Schmuck (part II)

This evening I had an excellent dinner with my friends Anthony and Erik, both of whom I hold in high esteem. There is nothing like a full-blown argument in good company and while we broached several topics, the one most noteworthy was that of Maven.

Anthony opened his broadside fire by claiming that a lot of the problems he saw in projects nowadays were Maven-related. I couldn't believe what I heard: a kindred spirit with sharp criticism on the untouchable Maven!

Maven adds considerable complexity by adding a layer of abstraction, obfuscating a lot of the dependency magic. Developers like Erik have no problem grasping the whole playing field, but the impact of this complexity on the team must not be underestimated. After all, team members must be facilitated by the tools, not obstructed or forced to learn more than they need to know, which in a way is what Maven imposes.

Anthony went so far as to claim that for large projects a dedicated Maven expert is required. I feel a lot of sympathy for that claim.

We concluded on the following regarding Maven's upsides:

• IDE support; it has solid support in setting up project structures -- think Eclipse and IDEA plugins which generate from the POM. With the right POM, you are up and running literally in minutes
  
• Reports; the built-in support of Maven for many types of reports is way more advanced than what its peers offer
  
• Intermediate product support; any project which produces intermediate JARs to be reused by other projects is bound to be a dependency nightmare, but Maven takes care of that mess best. Question is: aren't these the niche projects?
  

One thing we dealt with resolutely was the convention to split up a project in many sub-projects. A sub-project which does not result in its own deployable, nor is about to be reused in any way, does not deserve its own sub-project. The argument that future architecture splits are thus enabled is an academic train of thought which is rarely exercised in real life, though imposes heavy costs throughout the life cycle of the project. Keep it simple. Most projects belong in just one project folder.

At the end of the argument, both Anthony and I were more in favor of internalization of the dependencies (see my other article on Maven), while Erik remained firmly on the side of Maven dependency management.

For internalization, there is a price to pay though: internalization means that one developer goes through the pain of "getting it right", but after that it works for all other team members and for deployment to the target environments.

Excellent discussion of which I hope to see a lot more in the future.