So I was intrigued by Joe Ottinger’s call for requirements for a new java build system. I’ve had these thoughts for years now, especially after gruesome experiences with ant and maven.
I must admit, I like maven2. But I’ve experienced a rather steep learning curve using it. I now use it on all my projects. It definitely makes life easier, especially getting started. But I still find it rather difficult to at times find plugins or alternative ways of accomplishing something outside of maven’t conventions. Mostly I’ve adapter to maven’s conventions, but there are times when we just can’t escape the rest of the world. I was using GigaSpaces for a project and because of the OSGI-based build/deployment system, found it rather hard building and deploying the necessary artifacts from the standard maven build structure. After days of battling the obvious, I settled on a hybrid (maven/ant) approach. I build everything in maven, then package jars into GigaSpaces deployable units using ant. I also use ant for the rather custom deployment of PUs.
How much easier would that be had maven had straightforward scripting plugins. Just plugin a script tag into any lifecycle event as an AOP advice, for lifecycle before/after pointcuts.
Everything in maven requires a module. It’s pretty simple to incorporate and build a module, but you then have to maintain it outside of your build file and an average Joe (not Ottinger of course, he’s no average Joe:-), will most likely give up or find some rather dense and superfluous way of accomplishing a simple task.
I think an answer to this is a simple, extensible, DSL-based build system that would incorporate the best of both worlds. Convention and flexibility. We don’t have to sacrifice either one to accomplish what we want. Maven gives us convention, ant gives us great flexibility, Alex will give us both.
Anyone interested, the project is just starting up. You can get more details here…