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.

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

Today I moved a build machine from Maven RC1 to RC2.

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!

Recently I've been taking our automated build process (using CruiseControl) and getting it to integrate in with WebSphere 4 AppServer.

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.

This is a maven plugin that helps building netbeans modules with Maven.

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

The ide plugin team on Sourceforge recently announced a NetBeans module that brings code completion for:
- your project.xml file (currently POM version 3 only)
- your maven.xml and plugin.jelly files.

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

Yesterday I resigned from the Project Management Committee of Maven and from here on in will take a definitely less active role in the project itself.

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

Good luck guys.

Went to Bill Dudney's talk on AntiPatterns using selected Jakarta Projects at CSS2003, and the Ant section was screaming to me: Use Maven.

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

Looking around at doclets after getting inspired by the JDK1.5 metadata facility.

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.

See this, a fairly unemotional article for a change.

There's now an NSIS plugin for maven, which automates the creation of a simple win32 installation program.

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

There is a refresh of the maven installer for windows.

This one adds an uninstaller, links to common documents, checks for JAVA_HOME before installing and shows the ASL on startup.

Maven gets a .exe for Windows users

I've finally moved all those pesky damn Jira issues and scheduled them all.

We're now only 61 issues from getting a release.

Go for it guys!

There's been lots of talk lately about release candidates vs betas for Maven.

I'm firmly in the RC camp, as the core of maven has had very little change for quite some time now, and barring the memory usage of the reactor, not much is majorly wrong with it for a release....

Just in case u missed it, 1.0 beta 10 has been released. It's a lot of bug fixes, documentation updates and a few new features.

Thanks to all the people who contributed to this release, there have been quite a few vocal users sending in patches and keeping us developers on our collective toes!

I've been asked this a few times by a few people, and as a nice example of how Jira works, here's the list of issues for the b10 release.

Once they're finished, we're ready to roll.

Well, maven now has a much better ability to work with multiple projects simultaneously. Thanks to Michal for helping out on this one.

This means it's easier to generate documentation sites for many projects and aggregate them all into one.

Beta 10 of Maven is almost ready to go.

If there's something you want in that release, please raise it in Jira and link it to the release place holder