See AntWorks for yet another library of reusable Ant imported tasks.

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.

Another post today on the maven users list about an exception hidden inside stack traces inside of others etc.

That the exception was allowed to bubble out so far is a testament to the complete evilness of throws Exception. I

Howard's posted a bit more about Moving away from Maven

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)".

I saw on Howard's blog how he's converting back to Ant from Maven.

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!

I often go looking up the syntax for jelly tags or ant tasks.

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.

I was reading Scot McPhee's blog about my recent entry:

"Forgive my possibly perverse Maven-hating Ant-loving sense of humour, but I think if the Maven guys think that's all they need to learn from Ant, they've got another think coming!"

We have lots of 'thinks' coming Scot. I'm glad you agree with us that there is a lot Maven can learn from Ant.

I was by no means saying that's all Maven could learn from Ant. That's too long a list to go into. I was simply pointing to Conor's great article for future reference.

I found this article from Conor on Ant's IO system, something Vincent and I have discussed on IRC as something Maven could readily do with.

A small brain dump on some of the bad things about Maven 1.0 and it's architecture .

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.

"Steve Hanson shows how to create and use XMLBeans in a Web service client and then leverages their capabilities in an actual client for the Google Web service."

"Raj Alagumalai and Raju Subramanian discuss how XMLBeans handles some schema types, how it provides access to the entire XML infoset, and how it provides access to the schema object model."

"Cezar Cristian Andrei presents how XML documents can be manipulated in Java applications in a strongly typed fashion."

"Scott Ryan looks at two of the more popular frameworks used to turn XML input into Java objects and Java objects into XML."

TSS thread

This article made me laugh out loud.

Axis is gone???

IBM pulled out sometime late in 2002, and the project has been healthy and developed ever since.

You know what they say about publicity....