Maven2 progress!

Finally some information concerning the Maven 2 project. It was really quiet for almost a year! A lot of development has gone into the project, and I haven’t run the project yet, but I’m really exited to try it. The new features include:

  • TRANSITIVE DEPENDENCIES
  • increased performance due to Java code plugins
  • stopped doing double work (jar:jar will only create a jar, from what is in the build dir)

Too bad they don’t have the site generation in place yet as this is the feature I use most. Kudos to the maven2 team!

Finally some positive feedback on maven

Finally someone writing a good editorial about Maven, after the heat Maven got from community ‘leaders’. They seem to constantly regurgitate old beliefs.

I got introduced to Maven in the first half of 2003, when I was wrestling with maintaining Ant build scripts. Maven tickled my curiosity but I didn’t grasp the concepts. Only when I switched employers to Topicus my new collegues introduced me to Maven and I was hooked.

Maven was still in beta7 or so, but I found it really usable. I like the standard project structure, I do think that creating only one artifact per project is the correct way to build and maintain your projects, I enjoy writing my project documentation about building, installing, deployment and so forth in the XDoc format.

For my open source projects (JWebUnit, and Wicket) I constantly use Maven to maintain the dependencies and generate the website. For Wicket, I’ve created a special template to allow a much nicer design of the website than is possible with the default Maven template. Our corporate designer, Wouter de Jong, has created a special look-and-feel for the Wicket website, and I had little difficulty to transform his design into the stylesheet you see here.

In my distribution work for Wicket I use several plugins that make my life easier:

  • the distribution plugin (dist:build-bin)
  • the site plugin (site and site:sshdeploy)
  • the xdoc plugin (to generate the changed XDocs quickly use the maven console)
  • the sourceforge plugin
  • the create-upload-bundle plugin

Areas in which Maven could improve are the performance and the integration of the plugins. If I have run the test plugin, and then I run the site plugin, the tests are performed again, regardless whether anything has changed. This makes using Maven feel slow, and especially the process of performing a release on Sourceforge quite painful.

Although there are enough areas in which Maven could be better, it really makes my job a lot easier and I wouldn’t want to go back to solely using Ant at any time.

Embedding NedStat counter in your maven generated site

It is really a shame that SourceForge.net has disabled their statistics service. It would be nice to see what kind of effect creating a release has on your downloads. Just as we are planning to release our first release candidate we really would like to see some notion about whether the release makes an impression.

In order to be able to monitor some activity on the Wicket project I’ve installed a nedstat counter. As usual, it is not too trivial to embed the counter in a maven build. The JavaScript used by the nedstat counter was eaten by the XML processor used by Maven’s XDoc plugin.

According to the Wikipedia the JavaScript should be configured as follows inside XHTML documents (XDoc documents are XML, so they are treated the same)

<script type="text/javascript">
//<![CDATA[
   nedstat script goes here
//]]>
</script>

And this works as advertized! Be careful to only put the call to the nedstatbasic function inside this piece of markup.