Stefan Bodewig's Weblog

What's New in Ant 1.8.0?

Antoine Levy-Lambert has recently built the first release candidate for Ant 1.8.0 and called for a vote, so we should be close to the first Ant release since eighteen months. This release mostly brings enhancements and bug fixes to many tasks and types (this is the real strength of Ant IMHO) but there also are a few core changes, the full list is here.

My personal top five changes (I know there are six items, but the first one doesn't count ;-):

More than 275 fixed Bugzilla issues.
Lexically scoped local properties, i.e. properties that are only defined inside a target, sequential block or similar environment. This is very useful inside of <macrodef>s where a macro can now define a temporary property that will disappear once the task has finished.
<import> can now import from any file- or URL-providing resource - this includes <javaresource>. This means <import> can read build file snippets from JARs or fixed server URLs. There are several other improvements in the area of import.
Various improvements to the directory scanning code that help with symbolic link cycles (as can be found on MacOS X Java installations for example) and improve scanning performance. For big directory trees the improvement is dramatic.
The way developers can extend Ant's property expansion algorithm has been rewritten (breaking the older API) to be easier to use a be more powerful. The whole local properties mechanism is implemented using that API and could be implemented in a separate library without changes in Ant's core. Things like the yet-to-be-released props Antlib can now provide often required "scripty" fuctions without touching Ant itself.
At the same time the if and unless attributes have been rewritten to do the expected thing if applied to a property expansion (i.e. if="${foo}" will mean "yes, do it" if ${foo} expands to true, in Ant 1.7.1 it would mean "no" unless a property named "true" existed). This adds "testing conditions" as a new use-case to property expansion.

A new top-level element <extension-point> assists in writing re-usable build files that are meant to be imported. <extension-point> has a name and a dependency-list like <target> and can be used like a <target> from the command line or a dependy-list but the importing build file can add targets to the <extension-point>'s depends list.
In Ant 1.7.1 one would use something like

imported.xml:
<project name="imported"...>
  ...
  <target name="setup">
    ...
  </target>
  <target name="compile" depends="setup">
    ...
  </target>
</project>

importing.xml
<project ...>
  ...
  <import file="imported.xml">
  <target name="setup" depends="imported.setup">
    ... stuff that should happen before compile ...
  </target>
</project>

to define a pre-compilation stage by target overriding. With some planning it can be improved to

imported.xml:
<project name="imported"...>
  ...
  <target name="setup">
    ...
  </target>
  <target name="ready-to-compile" depends="setup"/>
  <target name="compile" depends="ready-to-compile">
    ...
  </target>
</project>

importing.xml
<project ...>
  ...
  <import file="imported.xml">
  <target name="ready-to-compile" depends="imported.ready-to-compile">
    ... stuff that should happen before compile ...
  </target>
</project>

In Ant 1.8.0 one would write this as

imported.xml:
<project name="imported"...>
  ...
  <target name="setup">
    ...
  </target>
  <extension-point name="ready-to-compile" depends="setup"/>
  <target name="compile" depends="ready-to-compile">
    ...
  </target>
</project>

importing.xml
<project ...>
  ...
  <import file="imported.xml">
  <target name="pre-compile" extensionOf="ready-to-compile">
    ... stuff that should happen before compile ...
  </target>
</project>

and the pre-compile target was added to ready-to-compile dependeny-list.

extension-point and some changes in import and its new cousin include have been inspired by Easyant which can now use an un-patched version of Ant together with a custom ProjectHelper to create a build system quite different from Ant's original ideas. ProjectHelper is the mechanism that allowed me to sketch JavaFront or Nicolas Lalevée to write GroovyFront which lets you write build files in Groovy.

Uncle Stefan

When my Mum called us this morning to tell us that my brother's first daughter was born my kids celebrated "finally I'm a cousin".

Welcome Carina - being born on 11/11 will not always be easy in the rhine area - and congratulations Claudia and Maik.

Ant-Task for .NET Build Tools 1.0.1

The GWT Tasks stuff made me work through some very old TODO items that have seriously been sitting in my inbox unanswered far too long.

More than three years ago I wrote an Ant task to be used inside NAnt or MSBuild build files and apparently some people actually use it. About a year ago Martin Harper told me that only lower case Ant properties worked but I never got around looking into it.

It turned out that I foolishly used used System.Collections.Specialized.StringDictionary to store the properties, which is not case sensitive. While I was at at it, I moved the whole class up to .NET 2.0 using generics and provided a Visual Studio solution.

Here is a new drop of source code as well as a pre-compiled DLL containing the task. The DLL has been compiled against NAnt 0.8.5 using VS 2008 - if you need any other combination (or a version not compiled against NAnt), please grab the source ZIP and compile it yourself.

The source is also available from a darcs repository:

darcs get http://stefan.samaflost.de/repos/anttask/

Gump Gets git Support for its Birthday

The Apache Gump project is five years old today and its birthday present is support for git.

To be honest I started working on git support when I saw JUnit moving away from Sourceforge a few weeks ago - and I didn't realize Gump's birthday was upcoming until last week. Still it is a nice coincidence and made a good tag line.

The Python code to use git has been in trunk for a a few days and I merged it into the code base running main Gump yesterday. Of course I managed to break the four lines of Python code I didn't run via Pylint, twice. Sorry for the broken Gump runs last night.

Norman Maurer helped me out when I had trouble getting git installed on the Solaris Zone (one of many people I owe a beer in Amsterdam) and I hope I now have a working version of git on vmgump. When all things look good I'll turn the switch on JUnit.

Next up will be darcs, Mercurial and Bazaar - but since we don't really have any project using them, it is a rather low priority project to me.

GWT Tasks 0.2

Back when GWT was all new and shiny (almost three years ago), I played with it and put together a tiny library of Ant tasks - nothing earth-shattering, really basically only a few macrodefs over Ant's java task.

Strangely I still get quite a few hits by searches for "GWT and Ant", so it seems as if nobody else has given GWT and Ant integration a try.

I don't use GWT. Not at all. When I create webapps at $JOB GWT isn't the right choice, either its technology is no fit (we mainly are a .NET shop after all) or the layout requirements can't be achieved by any component based framework I've tried (so far it is Velocity at the view layer for me).

Almost exactly two years ago Fernando Meyer sent me a patch to the Antlib that changed the hard coded directory names for source and destination into attributes on the gwt:shell and gwt:compile tasks. About a year ago I was asked how one could increase the memory size for gwt:compile. Somewhere very deeply buried on my TODO list I took note of them.

When I woke up this morning Apache's svn was read-only and suddenly I had time (I planned to hack on Gump) but no ASF project to keep me occupied so I finally managed to integrate Fernando's patch and make room for arbitrary extension arguments.

Code and sources are here and while I was at it, there is a darcs repository ¹ for it (I've been using darcs for years and didn't feel like installing a different SCM backend).

gwt:compile and gwt:shell have new attributes sourcedir that default to the old hard-coded value "src" for the source directory and both have a new nested element jvmargs that can be used to pass arbitrary nested elements supported by Ant's java task to the underlying task. I.e. one can now write

    <gwt:compile outDir="www" gwtHome="${gwt.home}"
                 classBase="de.samaflost.gwt.Foo">
      <gwt:jvmargs>
        <jvmarg value="-Xmx1024m"/>
      </gwt:jvmargs>
    </gwt:compile>

in order to bump the max memory to one gig. gwt:shell now also has an optional bindir attribute defaulting to the old hard-coded "bin".

The Antlib has seen some minimal manual testing against GWT 1.5.

It should be obvious that I don't really maintain these tasks, and to be honest I don't expect I'll ever do. If anybody wants to fork the code, reuse it, whatever, feel free to do so. If you are planning to maintain a more useful Ant integration than my hackish version did, please let me know so I can send people looking for "GWT and Ant" your way.

[1] The directory is not browseable, use

darcs get http://stefan.samaflost.de/repos/gwttasks/

in order to grab the contents.