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 :)

Adding the phrase "in my pants" to the end of any sentence makes it immediately funny.

For example: "I have a meeting to go to." Becomes "I have a meeting to go to in my pants." Which is far funnier.

This revelation was passed on to me by the best tech writer I know, Mark (who yesterday forgot how to spell "does"). The comic genius behind "in my pants" is one Sean Cummins whom I've never met "in my pants".

Bob has been good enough to provide me with blog space so as a small gesture of thanks I've added google ads to the blog with any income generated going to support the codehaus site. I hope you don't mind. Oh and if something interests you be sure to click through, it all helps :).

I woke at 4am this morning. It's starting to get to me now.

When I don't have my developer hat on I do some work helping development team improve their process. Recently I've been working with a very successful group of young developers who have a great learning management suite. Unfortunatly it is suffering from a growing bug count and the guys are spending the majority their time reacting to bugs rather than adding features.

The system is written on the .NET platform using visual studio. The project was the first for many of the developers (being straight out of university) and they took a look at the Microsoft tools available and said "hey this makes thing easy" and it did. For a while.

There are plenty of "organic growth" issues in the code base, but what struct me the most was the amount of infrastructure code for persistence, security etc, they'd had to develop. The sort of stuff I'd forgot about a long time ago. I realised that the reason I can be productive when creating a system is that for the majority of time I can just concentrate on the unique aspects of the system, not on the infracstruction.

Yesterday I needed a container to manage a small number of components and although I've used Avalon in the past it's fairly heavy and intrusive and the thought of adding all the dependencies to my web app just made me a little hesitent. After looking at a few containers I decided to go with PicoContainer. An hour later it was integrated and combining my components. You can't ask for much simplier than that. Now I've read all the arguments about the use of constructors being evil blah blah blah, but this thing just works and its nice and light (44K with debug symbols).

Well after toasting the mt install on my own box bob has set me up here on codehaus where I can do no more harm to myself.

I've also revamped the look of the blog. It's pretty untested on anything but Mozilla but I'm not doing anything too fancy so Internet Exploder should be able to handle it. Can you tell I don't think much of IE?