Rick Hightower once asked: "After using Maven, how could you go back to Ant?" Because it sucked. It sucked because it was unreliable, and your build tools can't be unreliable. Ant for the most part works and works in a transparent fashion. Maven has always been hit and miss - heaven help you if you're end requirements are not to produce a few jars, a website and a dist.tar.gz, or if something goes wrong and you have to debug it. Maven is like a person, nice on on the outside but on the inside it's all entrails. I just haven't been able to rely on it, preferring instead to enforce dependency management through policy, standard project layouts and targets through an ant script that generates ant scripts (the nearest open source thingie to that seems to be Jam). Policy management of dependencies is hard work, can be risky and is probably best left to SCM and build management specialists in large organisations that needs lots of process to function, not the kind of place I work in. That should give you an idea of how problematic I found maven. Now here's Maven2. It's an alpha, but it's so much better than maven, they might want to think about renaming the project. It's much faster. It doesn't try to force Jelly on you. It's not intuitive, but nor is actively obtuse as maven was. I have some medium-large projects that I could see moving to Maven2. It's an alpha, so it has problems. Most of these seem to be design problems rather bugs. When you do something wrong you typically get a an unhelpful stacktrace - that's no good, because it's not telling you whether you're doing something wrong or whether it's busted. For example, the copy of Maven2 I have blows up if I happen to run it in a directory with no project file. It blows up when I run genapp. It blows up when I run install. There's no obvious way to find the list of available targets (it doesn't follow, say, unix tool idioms). The package target is as best I can tell, broken from a usability viewpoint. The Maven2 team are honest enough in admitting that the documentation is lacking, but they need to clean up the error reporting to the end user before releasing a 1.0. Critically, Maven2 is not just a build system it's also a networked application, but one that behaves as though the network will just be on hand to provide content. That's a fundamental design problem. I really want to stop supporting my 'AntAnt' project generation hack mentioned earlier, despite the fact I have dozens on projects running on its artefacts, personally and in Propylon. I mention it here from time to time, so people have asked about its availablity. I am thinking about open sourcing it, tho' it's really only a quite small stuntwork. Bizarre as it sounds I don't have time to organize a release. I'm not a believer in just chucking projects into open source and Brian Zimmer will be after me soon for some Jython I promised. The 'roadmap' for AntAnt was to integrate Jam and/or Ivy (see Ivy is everything Maven should be ) and target the 1.7 Ant snapshots, maybe start describing projects using DOAP. Maven2 might mean I'll have to do none of that. The two things to figure out next are how flexible Maven2 is with regard to repository location and management (Brett Porter's subversion hack suggests this might be ok), and how easy it is to have an end result that is not a website and zip file. Finally Maven2 really, really, really, really, really, really, really, really, really, really, really, really, really, really, really needs to drop the idea of using badly conceived XML scripting languages for extensions. Replacing Jelly with Marmalade might sound funny, but it's not. Beanshell, Jython, Javascript - pick three....
Previous Topic
