Re: Moving Away From Maven

Howard says he is moving away from Maven, and gives some fair reasons for it, and I thought it was appropriate to respond.

Howard starts out by stating what he likes about Maven:
# Automated donwload of dependencies (from http://www.ibiblio.org/maven)
# Integrated pretty documentation (with navigation)

For dependencies, a good solution in Ant is later given. I think Howard would agree with me here – if you are using Maven just so you can grab dependencies easily and intend to script the build yourself, then you are wasting your time and should stick with Ant 🙂

For the site – Howard doesn’t propose an alternative. I assume he will continue to us Maven to generate that.

There is a claim that the documentation has a “large” number of bugs, of which Howard points out just two. The reality of this is that many of these are problems with Jelly itself. As a result, for a long time we have been planning a rewrite of the xdoc plugin that will not use Jelly. This will land shortly after Maven 1.0 is released.

While discussing bugs, I’ll admit Maven has a huge QA issue. We rely a lot on users to report bugs and submit patches across the areas that we can’t cover.
Maven is a project that facilitates rapid reuse and we accepted a lot of plugins that were later abandoned and we did not have the resources to maintain. As a result, some time ago plugins were moved to an independant release cycle, and Maven simply bundles the latest releases. It is up to the plugin maintainers to release quality plugins. The next task here is to evict immature plugins and make sure all have an owner, which is under way. It would have been nice to remove some of the low quality stuff already and make people download it – but you don’t want to inconvenience users in that way during an RC cycle.

I think the approach that has been taken here is sensible. No project is ever going to be bug free, so we focus on fixing the things that can be done
– quickly and easily
– by applying a patch
– affect the most users
If a bug gets filed as minor, with no suggestion of a fix, no votes from other users, and sometimes not even a reproducible test case – there aren’t many projects in the open source world that can fix all of those.

This is all just a result of growing too fast, and something that the team are endeavouring to get under control, by getting back to a more simplistic model of what Maven is, and start emphasising that the plugins are somewhat separate to that.

Moving on, Howards points on simplicity and consistency are well taken. Funnily enough all the issues he lists here look something like the documentation naviagation that has just been proposed as it is going under a rewrite.

Effeciency: Maven has made huge strides in this area, but we have accepted that as long as Jelly is in the core there is going to be a problem here, especially when generating the site.
However, Maven is as fast as Ant to do your day to day development, and faster if you run it in console mode, and really – how often do you regenerate the project site or a distribution? You can afford the time there, which is why the efforts have gone into the big wins.

Feedback: I hate NPE’s too. I hate it when you get it in Maven deep inside one of the other libraries it is using like velocity. And it’s worse for a user. But Maven then explains to the user how to file a bug report, and these issues usually get addressed immediately. We still have work to do here, but I’m not sure what more can be done immediately to help.

Howard’s Ant example that follows shows just how Ant should be used. I have a couple of issues with the perception here that it is much briefer than Maven:
1. it doesn’t do the site generation at all, while part of the Maven build documents given are dedicted to this (specifying reports and their properties)
2. those are not standard components. That is basically a reimplementation of what maven-javacc-plugin and maven-jar-plugin would be doing for you, and I suspect they are quite large and not immediately reusable beyond your own projects.
3. maven.xml is just there to fix a bug in a plugin, so that really shouldn’t be necessary.
4. This doesn’t address a lot of other issues that Howard has with Maven, such as building multiprojects, and probably isn’t too scalable.

JAM sounds like a better way to do (2) above as it is reusable, but I think if it were as popular as Maven, it would probably suffer the same problems.

Anyway, I hope this brings some clarity. Essentially I agree with what Howard has said to some extent, and as far as the issues with Maven go, they have long been recognised and I am happy to say the current Maven roadmap addresses it all. I look forward to seeing it come to fruition.