Tag Archives: build script

I have been at many places, in many teams, where no-one has ownership of the build scripts. It’s an area where a company can bleed a vast amount of time and money without realising it. It  may even be what makes senior member leave in the end due to frustration with to much inaction.

What is unfortunate is that it is relatively simple to fix. Sure, there are risks associated with any legacy clean up. But getting the build to work is far simpler then many other tasks in a legacy codebase. I find that the main reason it is not done is that the team can't communicate the value to management (including product owners). Therefor it gets low priority and ends up at the bottom of the back log.

I have always found that one of the best ways to communicate value to management is in money. By putting forward a business case with a clear RoI (return of investment). When it comes to build scripts this is a pretty easy task. First, ask everyone on the team who uses the build scripts to keep track of how much time they spend doing build related stuff. How much time do they spend working around a broken or non-functional build. Try to count only time which is spent unnecessarily. Once you have enough data to know what the broken builds costs on a weekly/monthly/quarterly (which ever suites your needs) basis it is time to look at how much it will cost to fix the build. I suspect the ratio will be quite scary. The difference is how much you loose each week/month/quarter. Hopefully this should get managements attention and priority.

Now that fixing the build is top in the backlog we need to make sure it doesn't fall back into despair again. This is where ownership comes into play. In a well functioning self organising team this is never an issue. Everyone owns the build. Everyone makes sure the build is just as snappy as everything else.

But If you don't work in senior or self organising team? Who should be responsible? A good place to start is the team. Perhaps someone feels very strongly for it. Passion goes a long way. Granted, you can't have just one who owns the build. It is knowledge which is far to important not to share between at least two. But with one lead it's usually easy to follow. Make sure to pair often to distribute knowledge.

If it's difficult to find someone who wants to take responsibility the team should make sure to pass it around. Share the pain to make it lesser for everyone. The main responsibility will however always fall on the architect. A working build is part of the non functional requirements that makes up an architects main concerns. How will you as the architect be able to guarantee that the solution you are the master builder of will ever reach it's intended user or customer if it cannot be built?

Now, go and fix that build and remove the pain. It is so worth it. And remember, with a working build you'll have so much more time to code, and that is what's really fun!

The other day a colleague asked if I had ever tried to set up any of my GitHub projects using one of the free CI services available. I hadn't but thought it an interesting thing to do. It proved to be a ridiculously easy task.

I could find two service providers on the market. One is BuildHive from < href="http://www.cloudbees.com/" target="_blank">CloudBees. This is the the company behind the CI server Jenkins. The other is called Travis CI and is provided by Travis. Travis id a, to me new, CI company who also seem to offer some enterprise services in the cloud.

I have used Jenkins allot in the past and it's a very good CI server. The company behind, CloudBees, also offer an enterprise service which I think is a very good fit for any company who want to get first class support with their CI and CD needs. However I choose to go with Travis since they requested less permissions to my GitHub account. I have not contacted CloudBees yet to find out why the want write access to my account setting, followers and private repositories when I just want to build public ones but I'd like to know.

There are three simple steps to go through to set up Travis CI with your GitHub projects:

  1. Log in to Travis CI using your GitHub OpenId.
  2. Enable the project you want to build in the Travis CI control panel.
  3. Add the .travis.yml build script file matching the needs of your build to your project on GitHub.

It is literary this simple. Granted, the project I selected has no special requirements. It builds nicely (well actually it doesn't since I have test failures) with just a simple mvm install command. But I think this is remarkably easy and something that everyone should try. If for no other reason so just to have the experience of how simple some things in software can be when done well.

Thanks Travis CI for such a spotless integration!

Have you ever got a ClassNotFoundException when running tests and yet the dependency that contains the jar is clearly in your pom file? This is most commonly due to collations in transitive dependencies. If Maven cannot decide which version of a dependency to use it will not import it. It will expect you to sort the problem out first.

Handling transitive dependencies should always be done pro-actively. And there is some really good tooling for it. Being a IntelliJ/IDEA developer my self it saddens me to say that in this instance my favourite IDE is outdone by NetBeans. NetBeans uses Maven pom files as it's project descriptors which makes it very easy to open the project.

When the project is opened in NetBeans you will find the pom.xml file located under project files in the project navigator. Once opened you will find an item named "Show Dependency Graph" in the context menu. This will render a graphical representation of all the projects transitive dependencies.

If any of the dependencies has a red top left corner there is a version conflict. Resolving it is done quickest by opening the context menu for the dependency and selecting "Fix Version Conflict". Unless you have a specific preference that differs from the default suggestion in the dialogue it is usually fine to got with the default solution.

If any of the dependencies has a yellow top left corner there are more then one version of the dependency requested. Maven will always choose the latest version in the list. This can, and should, however be overridden using the exclusions tag. I tend to take control over all such dependencies buy making sure I clearly choose which one should be included. You have to do this manually by excluding the dependency from each of the dependencies where the version you do not want is included and then ensure that the dependency requiring the correct version is the only one still including it. Sometimes it's better to exclude it as a transitive dependency altogether and add it as a direct dependency.

Whenever a new dependency is added to the project I make sure to perform the same procedure to ensure that I have full control of the dependencies in my project.

I would be very pleased to find such a great tool in IDEA as well, then I wouldn't have to run two IDEs at the same time, they do require a lot of resources.

1 Comment

Ever wanted Maven to print the test output to the terminal to save yourself from digging around in the surefire report directory to find out what happened with the failing tests? I have many times but have never invested the time to find out how until now.

It's pretty straightforward. Set the useFile flag to false in the surefire plug-in. To also skip the xml report output you can set the disableXmlReport to true. Then there will be no reports created when running the tests. Use the profile below to enable this in your pom.

Please note that for some odd reason my syntax highlighter lower case all tags. It should be groupId, artifactId, disableXmlReport and useFile in camel case.

To activate this profile you need to add -Pdev. You could have it active by default but then your CI server will not have any test reports. And whilst no reports are fine on the developer machine it's not very practical on the CI server.


After having automated our android project and getting everything to work, up and running on hudson and so on, we realised that the Android manifest xml file did not get automatically updated with the correct version numbers.

My initial idea was to use normal Maven properties, we do that in other parts of the project, to populate the values. However this does not work since the versionCode attribute must have an integer value for Eclipse to work. This ment that I would need to change the actual values in the manifest.

I had read a couple of blog posts about a Maven plugin called GMaven that have intrigued me. The plugin makes it possible to embed a Groovy script into a pom file and execute it during the build. Since Groovy makes changing XML easy this was the perfect fit.

Below is a script, embedded into the pom directives needed, that will automate setting version in the AndroidManifest.xml. It is triggered using the profile manifest-version-update. When triggered it will set the versionName attribute to the maven project version. It will also increment the versionCode attribute with 1 (versionCode++). The script should be placed in the Android application pom (I.E if you use a hierarchical structure this does not go in the parent pom).

I have yet to figure out how I can automatically trigger this when running the Maven release plugins prepare step. It would be perfect if it can be triggered once for the release pom and once for the snapshot pom during the release:prepare phase so that both the release tag and the trunk of the project has the correct version numbers. But that will have to wait a while.