I've made a small update to dependency-targets.xslt that will add marked jars to the defined web app library area (defaults to ${build.webapp}/WEB-INF/lib ). I've also updated the target names to make them a little more sensible.

In a moment of weakness at the start of a project I decided to use Maven for build management (hey all the cool kids were doing it and I felt really square). Now Maven is great as long as your happy to play in it's sandbox with the toys it provides. Beware if you step outside of the sandbox though. Nanny will come and slap your botty hard. You see nanny manges all the dependencies between "plugins" so if you want to use the new version of aspectj to weave some sexy aspects through your code and a couple of third party libs and that's not the way nanny does it, well put it this way, your bot bot is going to be sore.

So I looked at adding custom targets to my maven.xml file (effectivley duplicating a lot of the code in the plugins to reorder the dependencies), but it looked like more effort than it was worth so I decided to go back to crawling back to my old friend Ant.

My favorite thing about Maven is its jar loading. Add a dependency to your project and down comes the jar. It's added to your compile classpath and into your war lib dir, no mess, no fuss. I wanted this in Ant.

I grabbed a copy of the latest and greatest source code and built a nice fresh version. 1.6 has some nice new features the one I was really interested in was import . I'd used an early version of this when I was playing with Centipede a year or so ago.

I grabbed the dependency section out of my Maven project.xml file and stuck it into a seperate file (dependencies.xml ).

<dependencies>
  <dependency>
    <id>concurrent</id>
    <version>1.3.2</version>
    <url>http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html</url>
    <properties>
      <war.bundle>true</war.bundle>
    </properties>
  </dependency>
</dependencies>

Then I created an XSLT (dependency-targets.xslt) that created the ant targets to make the project class path and fetch each of the jars I didn't have it in my local jar repository.

All that was left was add the style and import tasks to my build.xml and make my compile target depend on the generated fetch-dependencies target.

<!-- import dependencies targets -->
<style
  basedir="${basedir}"
  out="${work.dir}/dependency-targets.xml"
  in="dependencies.xml"
  style="${src.build}/dependency-targets.xslt">

  <param name="project-name" expression="${ant.project.name}"/>
  <param name="local-repository" expression="${repository.local}"/>
  <param name="remote-repository" expression="${repository.remote}"/>
</style>

<import file="${work.dir}/dependency-targets.xml"/>

45 minutes and it was all good. Now my friend Ant and I can play together and nannys spankings are a distant and best forgotten memory.

I once heard that insanity was doing the same thing over and over and expecting a different result. I have recently encountered an example of this. A development team I'm working with has a bug count that is spiriling out of control. Having talked to the developers and looked at the code it wasn't hard to see why. There has been very little thought put into overall design of the system and more copy and paste code than I think I ever seen (a friend of mine swears that the copy and paste function should be removed from all development software).

So I talked to them about writing a few unit test. Before addressing a bug, write a test. Once it it running (and presumably failing), fix the bug. That way you slowly build up a test suite. Okay yeah, that easy, they said.

Last week I went in to see them again there where a number of new bugs so I asked to take a look at the tests. Not one had been written. I restated that it was going to be an up hill battle trying to stabilise the system if they don't start writing tests. They said that the code was too hard to write test for. So I sat down with them and wrote a test for one of the bugs. Along the way I refactored the underlying code a little to make working with the test system a little easier and fixed the bug. I then refactored the code some more to get rid of some copy and paste. Ran the test, all green, sweet. Oh, that was easy they said.

Today I got a call. Bugs had let bitten them again in areas they'd fixed two days before. Again I asked about the tests. Mine was the only one they had.

Sometimes getting developers to change their ways is more force than logic. Tommorrow I'm taking a hammer in with me :)