This one uses a list of properties as it's project model.

It will be interesting to see how it's possible to pass parameters onto javac to do the compile.

Since his blog requires a Blogger account to post, I'm commenting here.

Simplicity:
Even though Maven is not a simple beast (lets not pretend that Hivemind is either), it does make quite a few things simple to the user of the build. Knowing that a project will always be able to have a standard set of functionality on it, removes the usual Ant build file reading and understanding most people go through when trying to start with a project.

However, he's fallen into the same trap with his proposed Ant build file, he's now got Ant XML documents pretending to be programs with the <import> tags.

Consistency:
This is probably one area maven shines above howards example build file. He now has his own common 'jar' and 'download' code, not a shared consistent one.

Efficiency
I'll agree Maven's not as slim as Ant, but then Ant's not as slim as make.exe either. As for needing to fork the unit tests, maybe if there was a bug report or a user list posting someone could fix this. Without it, there's no chance.

Feedback
I agree Maven sucks at this, but I still haven't seen a failure error message from an imported ant build file to compare it with.

On to the example maven and comparative build files.

• I believe the javacc plugin bug was fixed. So that removes the need for the maven.xml altogether.


• If you want to compare sizes, at least be consistent enough to show all the files, e.g. the jar-module.xml and javacc.xml


• Also be consistent about what you put licenses on as well. The project.properties file has a license taking up most of it, but no licenses are shown for build.xml


• project.xml contains lots of useful stuff for me that's not shown in the Ant build file.

In summary, yes Maven will be more verbose than hand crafting personal Ant build files, and yes the error message reporting in Maven is woeful.

I'm still waiting to see the build file that Howard comes up with to produce his "Integrated pretty documentation (with navigation)".

Go for it!

I'm happy that with Maven we have all this stuff centralised and standardised, and that 100s of developers aren't rewriting tasks, making up macros and other stuff to add into their Ant build files.

Maven's not everybody's cup of tea, but it does do quite a good job of cutting down on build file psychomania.

Howard, get a trackback link!

Firefox has this cool feature that allows you to parameterise a bookmark.

Take this bookmark:

to http://jakarta.apache.org/commons/jelly/tags.html#core:%s

Note the %s there.

I gave that bookmark a 'keyword' of jelly in the bookmark and I can now type
jelly forEach
or
jelly if
in the address bar and be taken straight to the docs for the tags.

I also use one for Ant.

Thanks to Mark Pilgrim for the details and Giulio Piancastelli for the Ant core tasks one.

Plugins live in $MAVEN_HOME/plugins.
- There is no documented location for non-maven plugins to persist between installs.
- No documented location for 'single user' plugins for a multi-user install.

Which plugins?
- There's no way to define a list of required plugins for a user or installation. This creates issues across larger installations.

Plugin defaults
- There's no way to provide a standard set of defaults for plugins across a set of developers. The ${user.home}/build.properties file becomes a maintenance issue. It would be better to externalise or parameterise defaults.properties.

Installation
- plugin:download is great, but an 'artifact:download' is needed as well.
- plugin:update is also needed to pick up new releases of existing plugins with a confirmation before install.
- installation should be to either a user-only or system directory.
- Version clashes (e.g. multiple versions of a plugin) should be displayed during the build so that they can be corrected.
- As the ${maven.home}/plugins dir is a single directory, clashes with plugin jar names seem inevitable, and it would seem better to structure the plugins dir like a repo with ${groupId}/plugins directories. e.g. all maven plugins go into ${maven.home}/plugins/maven/plugins, and plugins from sourceforge go into ${maven.home}/plugins/sourceforge/plugins
- Plugin dependencies are not usually provided with plugins. The download/install process should fetch them all rather than waiting until later.

Unzipping
- Plugins are automatically unzipped creating large numbers of directories and files in typically ${user.home}/.maven which are often left over on a new install causing issues

Caching
- Plugins contents are cached into files in ${user.home}/.maven/plugins. Until rc3 this cache would often become corrupt over time with unpredictable results. Once rc3 is out we'll see how this goes.

Plugin classpaths
- Plugins written in Jelly often have clashes with the libraries in use by Maven. The classloaders need to be isolated.
- Classes provided by Maven (ant junit etc) often require classes to be found in their classloader.
- Plugins often have issues with jdk 1.3 and the xml classes.

JDK Differentiation
- There's no easy way to specify dependencies for a project by jdk version (e.g. xml classes needed only for jdk13 etc)

Dependency specification
- There's no way to specify for example a released junit > 3.8, a specific version is always required. Some way to specify 3.x or > 3 would make keeping up to date a lot easier, and specific versions are still required for repeatable build situations.

Plugin information
- Once a plugin is installed, it would be nice to be able to dump info about the plugin (name, url, distribution site, authors, mailing lists etc....)

Goal naming
- Plugins usually define goals with a standard prefix, e.g. myplugin:theGoal. Exceptions to this rule should be reported, and prefixes being reused by other plugins reported as well.

A multiproject build of 24 projects into a single EAR file (including non-container tests) used to allocate 154MB of memory.

It now uses 67MB to do the same thing.

Not optimal, but a swag load better.

Update: Oh, and it also cut 10 minutes of the build time too

Good work Brett!

The was40 plugin has been useful, and I've added a generate-ejb-code goal to it, which generates the code needed for the ejb jar to run in WAS.

The EJBDeploy tool in WAS is a very fragile beasty. I've had lots of NPEs due to invalid chunks of metadata in the various files WAS/WSAD uses. With some help from IBM support I've been able to identify the bad chunks and clean them up.

I'll hopefully have the generate-ejb-code goal all cleaned up and ready for general usage in the next couple of days.

It's an offshoot of the ide development work. Go Milos

The 0.1 release works and was tested with Netbeans 3.5.1.
The 0.2 snapshot release works with the Netbeans 3.6 beta.

Cool.....

I hope that a 1.0 release happens sometime, but will happily remain using RC1 and the 1.0 Branch.

Good luck guys.

It's amazing how many people still handcraft Ant build files for all the simple stuff that happens on every project.

Saw dbdoclet which will produce docbook from javadoc comments, as well as class diagrams. It would be nice to integrate generating class diagrams into Maven.

To use it, you can check it out of Maven Plugins CVS