Tag Archives: Build

Building Mule 2 with Maven 3

Posted on by
Reply

For the project I was working on, I wanted to try out the Mule ebMS adapter written by Clockwork. This adapter needs Mule 2, but unfortunately some of the dependencies for the latest release of Mule 2 (2.2.1) seem to have vanished from the popular Maven repositories.

No worries though, the Mule 2.2 source is not dead yet! Looking into their subversion repository you will find newer tags, so I checked out the latest tag, 2.2.8, and tried to build it – only to get a build failure.
I was using Maven 3, but Mule 2 was written for Maven 2. Not wanting to install an older version of Maven, I set out to fix the problem. Turned out there were actually two:
Firstly, Maven 3 does not want you to use values directly in the <includes> element, not even if it is a single value instead of a comma-separated list. Rather, you should use the child <include> element.
Secondly, the gmaven-plugin version used by Mule does not play nice with Maven 3. Upgrading to the latest version (1.4) fixed that.

This one was not all that hard to solve in the end, but it took a lot of googling and experimenting. I hope I will save you that trouble!

Characteristics of a proper build

Posted on by
1

Wat are the characteristics of a proper build?

  •  It is built off a build server, not your laptop (although now and then I break this rule with no tangible damage until today).
  • The source code is then labeled.
  • You can branch of the source of a build.
  • The build is published somewhere, a network disk, ivy / maven repository, whatever. Just not your laptop.
  • You have an administration of what is in this particular build. A bill of materials with changes, known errors and installation instructions.
  • You do something with it, install it on a dev server at least.

The last one sounds pretty logical, but we have to give it good thought. It is the essence of the build. It is the sole reason to build. Someone is going to use that very build. It is not just the last box that you tick before you start working on the next build.

Time versus feature driven delivery

Posted on by
1

I’m a big fan of time driven delivery. You can read about it in several other posts. Especially early in the project, where nobody feels like making a tangible build at all, because there is not so much to build. I keep stressing to get into the habit of delivering, because time never ceases to be perfectly reliable, while units of work and estimates always fail.

Continue reading →