Today, I needed to have a JAR of BSBM benchmark tools. Surprisingly, when I downloaded the bundled zip from SourceForge, there was neither JAR nor build file inside (no build.xml, no pom.xml, nothing) - or maybe I'm blind.
Well, Gradle to the rescue. :)

Do you know this nice tool called Clirr and its Maven plugin ? Well, it is very nice, although it fails miserably in case of some inner class changes. Thus, it doesn't work for some of my projects. :(

TestNG reports can be customized, so any style modification is possible. Did you know there is this nice ReportNG project, that makes TestNG produce very good looking reports without much trouble ?

In your opinion, the original reports of TestNG are (pick one or more options):

1. showing too much information,
2. showing not enough information,
3. not showing what you want to show,
4. require too many clicks to find out what has gone wrong,
5. not very pretty,

Because of this, you finally decide to create your own reports. Good, then read this post, and you will learn about one possible way of achieving this.

This is a review of "Apache Maven 2 Effective Implementation" book by Brett Porter and Maria Odea Ching (Packt Publishing, 2009)

This is a part of "Ant/Gradle/Maven comparison" series.

A common task during development is the creation of an installable version of software. The one I mention in this post is a real one - this is something I've been working working with since few months. It does few things related to Fuse ESB:

• unpacks Fuse sources,
• updates some config files,
• retrieves few JARs from Maven repository and put them into deploy folder,
• does some more file-related stuff - creates directories and copies files,
• produces ready-to-unpack-and-use file: tar.gz (for Linux) and zip (for Windows).

I started to write this with Ant/Maven, and then switched to Gradle. I'll present few code snippets here, that should give you a decent understanding of difference that Gradle makes. Please judge for yourself if the switch from Ant/Maven to Gradle was worth the effort.

So I became a cook... It is rather surprising, because my kitchen-fu is limited to boiling water. :) But well, life is unpredictable, you know - and so now I'm busy preparing recipes for Gradle users. In other words, I'm taking care of the Gradle Cookbook.

Is test-first better than test-last ? Is there a significant difference in the quality of code developed using these approaches ? It's hard to say for sure. My gut feeling (and experience) tells me that test-first is superior. Sometimes I find evidences for this claim. Like the one I present in this blog post.

So you decided to check some build prerequisites before doing any real job. You want to check if proper Java version is installed, if some configuration files are available etc.

I'll show you how you can do this using Ant, Gradle and Maven.

This is a part of "Untestable code" series. See the introduction to know what is it all about (yes, you really should go there, do it).

The main idea of the series is to write unit-tests for a particularly nasty piece of code. In this part I will use Groovy language to write test cases... well, not exactly. The point is that you can't do it with Groovy. :(