I was reading dion's response to Howard's Maven post, and saw a comment there that said:

Howard is also looking at using JAM, which provides a pre-built set of ant tasks, much like Maven except written so I don't have to learn a whole new tool and language. This seems to be what Maven should have been, if developed by people with sense.

Despite all the complaints about Jelly (most of which come from the Maven developers :), countless people have tried. I don't quite understand that - you shouldn't have to learn Jelly to use Maven. Maybe this is a problem with documentation and something I'm trying to fix right now.

I've said previously that JAM looks like a good idea - using what Maven is really about to generate Ant that everyone else understands until Maven can handle some of the things that get tricky (in particular multiple source directory handling is inconsistent in Maven 1.x).
A JAM developer posted this comment:

We actually see JAM as step towards Maven, not as a competing framework. But until Maven matures, Ant is still the reliable industry workhorse… and we hope JAM makes it a little easier to use.

This is good to see. I haven't tried JAM out, but if it does what you need it to do, then I'd say go for it.

It's a shame that Maven has come out being perceived as a glue for a bunch of Ant tasks. It's a fair perception, because as I said in my last post, when you give users the option of producing reusable build fragments, it tends to happen real fast, so Maven has a lot of plugins out there.

I certainly look forward to a stronger adoption of Maven's concepts of project information structure, and hope that Maven can continue to mature down its current path where it becomes the best tool to manage this information and build with it.

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.

The Maven team is pleased to announce the Maven 1.0-rc3 release!

http://maven.apache.org/start/download.html

Maven 1.0 RC3 is the final release candidate for Maven 1.0.

Maven is a project management and project comprehension tool. Maven is based
on the concept of a project object model: builds, documentation creation, site
publication, and distribution publication are all controlled from the project
object model. Maven also provides tools to create source metrics, change logs
based directly on source repository, and source cross-references.

Changes in this version include:

New Features:

o Introduce a backwards compatibility option maven.property.inheritance,
which disables the functionality when set to false. Issue: MAVEN-1255.
o Show help on how to submit a bug report if Maven dies with an unexpected
exception
o Add maven.remote.group to defaults.properties
o Add sort attribute to reactor tag.
o Add collectOnly and collectionVar attributes to reactor tag. Thanks to John
Casey.
o Improve maven -g output, and add -u and -P switches for additional usage
help.
o maven:get/maven:set tags replace maven:pluginVar
o Install and uninstall plugin jelly tags for managing plugins on the fly. Issue:
MAVEN-1219.
o Ships with the latest maven standard plugin releases.
o All plugin releases were polished up.

Fixed bugs:

o Parent project properties are now correctly loaded from extended
project.xml files. This was implemented previously, but the properties were
not being passed through to the final goal attainment context. Issue:
MAVEN-37.
o Evaluate context variables before inserting them into the ant properties
Issue: MAVEN-1275. Thanks to Henning Schmiedehausen.
o Have system entities with relative paths in maven.xml and plugin scripts
resolve relative to the correct location. Issue: MAVEN-1223. Thanks to
joseph benavidez.
o Setup dependency path for non-classpath dependencies Issue: MAVEN-1265.
o Fix install_repo.bat problems on Windows 98 Issue: MAVEN-956.
o Allow plugin installation and uninstallation from the plugin manager and
the cache so that it can be done on the fly. Issue: MAVEN-1219.
o Snapshot is now downloaded only if the remote version is more recent than
local version. Issue: MAVEN-1226.
o Fix fatal exception running goals defined inside j:import'ed scripts.
Issue: MPAPPSERVER-6.
o Correctly report certain types of fatal exceptions inside of silently
ignoring them.
o use correct new lines in maven -g output Issue: MAVEN-1227.
o Apply patch to use system encoding for project so that xdoc transformation
of POM works on non-ISO8859-1 systems. Issue: MAVEN-1050. Thanks to
Shinsuke SUGAYA.
o Improve error handling of HttpUtils Issue: MAVEN-558. Thanks to David
Zeleznik.

Changes:

o Add a Base64 implementation to replace the sun.* internal version. Issue:
MAVEN-1129. Thanks to John Casey.
o Remove tools.jar from startup classpath so it will run on non-Sun JVMs such
as Kaffe. Issue: MAVEN-1129.
o Move maven jelly tags to maven-jelly-tags subproject
o Show extended information with --info: list of installed plugins (including
versions), and ~/build.properties

Removed:

o The experimental codeswitcher and perforce plugins were removed from the
distribution.
o The StatCVS plugin has been moved to the StatCVS project and has been removed
from the distribution. see: http://statcvs-xml.berlios.de/

Plugin highlights:

o Add a "classic" theme CSS
o Items in navigation.xml and reports can define a target attribute. Items in
links can use an img attribute to create an icon. New CSS class named
"externalLink" used for links with an url beginning with 'http://'. New CSS
class named "newWindow" used for links with target='_blank'. Issue:
MPXDOC-97. Thanks to Fabrizio Giustina, Harald Ommang .
o Add a plugin:install-now goal that installs the plugin into the currently
running instance of maven so that it can be used by subsequent goals.
Issue: MAVEN-1219.
o Add plugin:uninstall-now that removes the plugin from the currently running
instance of Maven. Issue: MAVEN-1219.
o Fix issues with DOM classes and jdk1.3
o For individual plugin changes, see the Changes report for plugins at:
http://maven.apache.org/reference/plugins/plugins.html

We hope you enjoy using Maven! If you have any questions, please consult:

* the FAQ: http://maven.apache.org/faq.html
* the Wiki: http://wiki.codehaus.org/maven/
* the maven-user mailing list: http://maven.apache.org/mail-lists.html

For news and information, see:

* Maven Blogs: http://www.mavenblogs.com/

- The Apache Maven Team