Short answer: No

Slightly longer answer: Not yet.

Long answer: As a matter of policy, after Ant 1.8 is released, I will avoid making use of any 1.8 specific features for a relatively long period. I will definitely make sure that the ASL is fully compatible with Ant 1.8, but it will still be fully compatible with Ant 1.7.

This is because the ASL is intended to be used as an add-on library to an existing ant infrastructure. However, in my experience many companies and IDEs are quite conservative in upgrading their Ant installations. Probably in a year or two after Ant 1.8 is released, I might feel comfortable in adding dependencies on the latest features (probably keeping a 1.7 compatible branch of the ASL available for a longer time). By that time I expect that Ant 1.8 will have made inroads to corporate build installations and IDEs. However, I’ve worked in places where Ant 1.7 (now 3 years old!) is still under consideration. If history is anything to judge, there will be a long period before Ant 1.8 makes it into some development shops.

I would regard this as probably the major difference in philosophy between ASL and EasyAnt:

• EasyAnt is a replacement for Ant. It extends the internals of Ant to add non-standard features (e.g. “phases”). It is invoked by calling a completely different front end script. It contains an embedded and modified version of Ant, which must be installed separately. This gives them the freedom to make full use of new features, but it means a full switchover is required.
• ASL is less ambitious (it’s just a library), but I think it makes it easier to accept in more conservative organisations that are happy with Ant, but are looking for a way to control build script complexity. For this reason, the ASL must be more conservative, too (though I might end up having two versions of the ASL, one for Ant 1.7 and another for Ant 1.8)

During the session proposals, Ivan Moore originally suggested a talk on better builds for Java programs. There were later proposals for sessions regarding improvements to Maven, so I proposed my own session “Better Ant Builds” to differentiate it from the Maven sessions.

My main goal was to promote by own contribution to this area: the Ant Script Library. JTF knew about this, and asked some leading questions when I proposed the talk about my library, which I thought was funny. I thought it would have been a bit too cheeky to give a great big marketing pitch, but then again I’m not the best marketer. Thanks for the push, Jeff!

Despite there being no projector available, I was able to talk a fair bit about the ASL, along with some of it’s background and design. People seemed interested, which I’m taking as a good sign. I won’t go into details, the website already has everything I discussed.

Jeff also pointed out the Ant Master Build Scripts, which at a glance seems to be a very similar project to the ASL. Looking at them, I’m pretty impressed. The author of those scripts presented a session at JavaOne called “Object Oriented Ant Scripts for the Enterprise“, which I think nails the leading design principles for reusable Ant scripts. I’d say the the master build scripts have a higher emphasis on J2EE projects, which the ASL leans more to building Java libraries, applications and static analysis. Plenty of room for both projects to grow!

The main question I had for the group was this: “How do you test an Ant script”? Historically, this has not been a problem. You wrote a script for a specific project. You ran the script, and it either worked or it didn’t. However, the Ant Script Library doesn’t have it’s own project – it is reused to build other projects. From my point of view, I really want to be able to set up an “integration test”. The answer is pretty obvious: set up a real project that you can use to run the ant script against. After running the script, you should be able to assert that artifacts are created in the expected locations. Duh! (in hindsight, anyway)

One more good tip: GitHub is a good place to set up an open source project. Another alternative might be Google Code. Currently, I’m running ASL from my own Subversion server. I’m thinking about moving to a location that can handle proper project infrastructure (version control, wiki, mailing lists, etc). Personally, I really like subversion, and I think it’s a pretty nice way to integrate ASL with your own project using svn:externals (assuming you’re using Subversion, too). Google Code uses Subversion, but GitHub uses another version control system I can’t remember (oh, wait: Git). Food for thought; I’ll think about that one for a bit.

For more details of the session, there is a write up on the wiki.

Update: The Build Doctor was actually taking good notes (as opposed to my vague recollection from 2 days later), and has a lot more detail in his own blog post on the discussion.

There are quite a number of small enhancements throughout the library, and I’ve been filling in missing documentation, too. Here’s a summary of the major changes between version 1.0.2 and 1.1.0:

• Added new release module asl-release.xml.
• Added application package module asl-java-package.xml.
• Updated documentation for reports module
• New Java static analysis reports:
  • Checkstyle report
  • FindBugs report
  • Copy/paste detection report
• Added new SCM modules:
  • Subversion module
  • Perforce module
• New introductory tutorial
• Enhancements to the Ivy tasks
• Link generated JavaDoc to JRE JavaDoc

Please go to the download page if you want to try it out.

All the above reports give a great way to view the state of the code at a given time. One thing missing from those is trends over time. Trend information can help give you an idea of how a system is improving (or getting worse!) over time, and so enable better architectural oversight. For that reason, I started looking around for tools to help me there. I found three that I liked:

• Sonar appears to be the most advanced at the moment, at it has some great reports (check out the publicly available Sonar reports on Nemo). I have one problem, though: Sonar requires Maven to run. I’m loath to add a complete competing build system to the ASL.
• QALab looks interesting, but it also looks to be an abandoned project, with no update for over three years.
• XRadar appears to be the best bet at the moment, a new version was released a few weeks ago. It looks quite comprehensive.

Does anyone else have any recommondations for tools?

The major changes are:

• I’ve reworked the website to give it a distinct style from the rest of exubero.com, which is much more in line with its Ant focus. See http://www.exubero.com/asl/ for the skinny on that.
• The documentation is now packaged along with the scripts, making them available offline
• I’ve excluded a large number of optional library jars from the default download. If you call any script target that requires an optional jar, you will be prompted to run the automatic download script. This makes the download much smaller for those people who don’t use any of the reporting features.
• There is a new installer module (asl-java-install.xml). This can be used to install an application jar, along with all its library dependencies and configuration into an application assembly.

To get a copy, please visit the download page.

So far, I’ve managed to write some fairly complete documentation for the asl-java-build.xml module, but there’s still a long way to go for the other modules. In writing these, I’ve discovered some pretty neat tools: yEd and KImageMapEditor. yEd makes it trivial to read in an Ant build file and generate a dependency diagram, while KImageMapEditor makes it a snap to add links without having to break up the diagrams. This is probably old hat to a number of people out there, but I’ve found it very interesting to catch up on these tools.

http://www.exubero.com/asl/index.html

There’s still a lot to do in terms of documenting the scripts, but I was able to create this handy visualisation of the ASL target dependencies:

(This image was generated by yEd – thanks yWorks!)

http://www.exubero.com/asl/ant-script-library-1.0.1.zip

I’m getting around to writing more complete documentation for how to use these, but for the moment I wanted to explain the considerations behind design of these scripts (referred to as the ASL in the remainder of this post).

Orthogonal Modules

The ASL is composed of a number of files, each containing a relatively small number of targets. The targets are named in relatively generic terms. The purpose is to allow alternate scripts to be imported if a different implementation is required. For example, if you like to use Apache Ivy to manage your dependencies in a repository, you can import the Ivy targets as follows:

<import file="ant-script-library/asl-repo-ivy.xml"/>

This import will then make the following targets available in your script: repo-cleancache, repo-report, repo-resolve, repo-retrieve.

If you later decided that you didn’t want to use Ivy, but rather the Maven Ant Tasks instead, you could replace the previous import with the following:

<import file="ant-script-library/asl-repo-maven.xml"/>

With this one change, your build script then changes to use a completely different repository management tool. Because this different module provides targets with the same names, no other changes would be required in the script (though in this case, you would have to replace the ivy.xml file with an equivalent pom.xml).

Small Targets

Each ASL module is composed a number of top level targets public targets (these have descriptions, and so are described when you type `ant -p`), as well as a number of private targets (these are prefixed with a ‘-’ to ensure that they can’t accidentally be invoked from the command line). Looking over the scripts, you will not that no target is more than 5 – 10 lines long, and does at most one or two tasks. The are a number of reasons for this:

• It becomes much easier to understand and maintain the scripts, because there is nothing really complex in any one target
• It becomes very easy to override specific targets to give different functionality. This is especially important when you are writing library scripts – it is almost certain that some targets will need to be overridden in the main script.

Convention Over Configuration

The ASL has a number of build in configuration defaults, such as the location of the source directory, the location of the test source directory, and so on.  If your application conforms to these expected default, your build script can become incredibly simple. The simplest possible script might be:

<project name="my-project" default="dist">
<import file="ant-script-library/asl-java.xml"/>
</project>

In general, the ASL scripts tend to expect your project conforms to the Maven standard directory layout.

Configuration Over Overriding

Not everyone has their project laid out in exactly the way, and it’s not always easy to change this. In these cases, it’s usually just a matter of defining specific properties with the actual values for your project before importing the ASL scripts. For example:

<project name="my-project" default="dist">
<property name="java-build.src-dir location="src"/>
<property name="java-test.src-dir location="test"/>
<import file="ant-script-library/asl-java.xml"/>
</project>

Admittedly,the documentation for the properties is not there right now, but these can easily be determined by inspecting the ASL scripts.

Overriding Over Reimplementation

In cases where you need to do something complete different to what the ASL scripts are doing, you can override specific targets in the top level build script. Just those targets will be overriden, and everything will work without change. For example:

<project name="my-project" default="dist">
<import file="ant-script-library/asl-java.xml"/>
<!-- ***********************************************************************
* target override: copy-resources
************************************************************************ -->
<target name="copy-resources"
description="Copies resources in preparation to be packaged in jar">
<copy todir="${java-build.classes-dir}">
<fileset dir="resources"/>
</copy>
</target>
</project>

You use this by unzipping the contents to your workspace, and create your own build.xml file similar to the following:

<project name="afp-renderer" default="dist">
<import file="../ant-script-library/asl-java.xml"/>
</project>

In the coming weeks I’ll explain more about the design and usage of these scripts, but for the moment you can have a poke about. I’m interested if anyone has any feedback about these.

You can get hold of the scripts from the download page.