A build tool should not have a steep learning curve. It should be intuitive, and flexible. It should not make any wide reaching assumptions about how all projects will be because these assumptions are rarely satisfied in practice.

Maven also encourages the developer to pile more and more logic into the build tool, to the point where the normal development cycle edit/compile/debug is negatively affected.

Sadly, people are buying into it. It’s reminding me of large corporations that spend millions on “ClearCase” because they’re terrified (so the salespeople tell them) of losing all their code. In the end, nobody can use it because of network problems.

Of course the salespeople tell you that “you just don’t understand it, but once you do, it’s great”.

No, it should be simple and flexible. The fact that it has a “steep learning curve” is proof that there is something seriously wrong with it.

Yeah, you should have come along, it was a good couple of days. Anyhow, it is good to hear that things are being addressed. No doubt I didn’t mention anything the Maven team didn’t already know. I just find it interesting that holy wars over Maven don’t focus much on the “religion” (i.e. the theory) as normally happens. The good thing about this is it is easier to improve the implementation than completely change your approach.

You make some valid points. The issue of better plugin control is on the top of the list for the Maven 2.1 release. In the space of providing Maven “distributions” – this is one of the key reasons that DevZuz provide the Maestro distribution. On the last point I certainly agree – we see a lot of use of the “antrun” or scripting plugins at the moment to achieve this and it certainly could be easier through a more flexible lifecycle mapping.

Thanks for the post!