Deploying your artifacts to a remote Maven repository with Gradle is possible, but the official documentation is rather thin at the time of this writing. Worse, it tells you to use a version of wagon-ssh that ignores the provided password and prompt for it at the command line (use gradle -i to see its message).

So, without further ado, here is a build.gradle that uploads its artifact via scp with a password. It has been tested with Gradle 1.0-milestone-6.

apply plugin: 'java'
apply plugin: 'maven'

configurations {
    deployerJars
}

repositories {
    mavenLocal()
    mavenCentral()
}

dependencies {
    //the one and only version that works
    deployerJars 'org.apache.maven.wagon:wagon-ssh:1.0-alpha-3'
}

uploadArchives {
    repositories.mavenDeployer {
        configuration = configurations.deployerJars
        uniqueVersion = false
        String username = 'me'
        String password = 'secret'
        repository(url: 'scp://repos.mycompany.com/releases') {
            authentication(userName: username, password: password)
        }
        snapshotRepository(url: 'scp://repos.mycompany.com/snapshots') {
            authentication(userName: username, password: password)
        }
    }
}

	

Of course, in a real world scenario, it would be wiser to get the username and password from your gradle.properties or any other non-public file.

Gradle is a very flexible and powerful build tool, allowing an extremely concise build file for conventional projects and letting you do whatever crazy thing your project requires using a Groovy DSL. I've been following its development for the last two years, and I introduced it to replace a legacy Ant based build system at my work about a year ago.

As far as I know, Building and Testing with Gradle, written by Tim Berglund and Matthew McCullough and published by O'Reilly, is the first book published on this topic.

The first chapter will guide you through the installation process and the use of the Gradle from the command line. I'm not sure someone willing to use Gradle needs that kind of information. It will also show you the shorter build file possible for a Java project, containing only 18 non-whitespace characters: compare this with Maven...

The second chapter is were the serious stuff begins. It presents the basic unit of Gradle build files: tasks. The two lifecycle phases, configuration and execution, are explained. You'll also learn how to use their rich API and how to simply write your own tasks. If you're used to the complexity of Maven, be prepared for a shock as this is dead simple and way conciser.

The third chapter shows how Gradle can leverage your existing Ant files and custom tasks. This particularity of Gradle allows a step-by-step migration from Ant.

The fourth chapter compares Maven and Gradle. Gradle takes the best ideas from Maven (and others): convention over configuration, consistently named artifacts and a solid dependency management with the same central repositories. It drops what makes Maven so painful to use: tons of XML, a rigid lifecycle and more generally its lack of flexibility.

The fifth chapter is about testing. The integration of JUnit, TestNG, Spock, Geb and EasyB will be rapidly shown.

The sixth and last chapter is focused on multiproject (or multimodule) builds. Once again, the tremendous flexibility of Gradle makes it bend to your needs rather than imposing its standards on you.

This is a short book with fewer than a hundred pages, read in a couple of hours, and full of code samples. It is an introduction to Gradle, not a complete reference guide: it will show you the power and the simplicity of Gradle, and - I hope - will convince you to give Gradle a try.

The Brother HL-2250DN is a laser printer with both a USB and an Ethernet interface. It understands PCL6, so I knew I could use it with my Ubuntu 10.10 box without too much troubles.

Here's how to configure your computer to enjoy the Ethernet interface. One doesn't buy a network printer to use USB, right?

First, one need to get the IP address of the printer. You could get it from your router, or you may just ask the printer. To print the settings of your printer, do the following:

1. Switch on the printer;
2. Wait till the printer is ready;
3. Press "Go" three times in less than 2 seconds.

The IP address will be on the third page.

Now, on your Ubuntu box:

1. Go to System / Administration / Printing;
2. Click on the "Add" button;
3. Select "LPD/LPR Host or Printer" on the left;
4. On the right, enter the printer's IP address;
5. The name of the queue is "PCL_P1";
6. When asked for a driver, pick "Generic PCL 6/PCL XL Printer - CUPS+Gutenprint v5.2.6 Simplified".

And voilà!

I had to parse in Java an rather big XML document that was looking something like that:

<root>
	<child1>
		<a>I need this element</a>
		<b>but not this one</b>
		<c>this one is also irrelevant</c>
	</child1>
	<child2>
		<a></a>
		<b></b>
		<c></c>
	</child2>
	<!-- and so on to fill more than 4 Mo -->
</root>

There are hundreds of first level child nodes, but each one only has a few children.

Given any child node, I had to get one of its own children by its name. I had two options:

• iterate over the list of children, and check each one to see if it's the one I am looking for (5 lines of code);
• or be lazy and use a very simple XPath expression (1 line of code).

Being lazy, and since the context nodes were having only a few child nodes, I decided to go with XPath. I knew there would be some overhead, but it shouldn't be very big, right?

Wrong.

My code wasn't doing anything fancy, but it took 40 seconds to complete. Being curious about the overhead introduced by XPath, I replaced it by a bunch of node.getChildNodes(). The total time dropped to 0.1 second.

I wrote a small benchmark to illustrate this problem. It boils down to these two methods:

/**
 * Returns the direct child of parent with the given name using XPath
 */
private static Node getChildXPath(Node parent, String name) throws Exception {
	return (Node)xpath.evaluate(name, parent, XPathConstants.NODE);
}

/**
 * Returns the direct child of parent with the given name using getChildNodes()
 */
private static Node getChildDom(Node parent, String name) throws Exception {
	NodeList list = parent.getChildNodes();
	for(int i=0; i<list.getLength(); i++) {
		Node child = list.item(i);
		if(child.getNodeType() == Node.ELEMENT_NODE && name.equals(child.getNodeName())) {
			return child;
		}
	}
	return null;
}

The full code is available on github.

On my linux box with OpenJDK 1.6.0_20, I got the following results:

Children were found using DOM in 2 ms
Children were found using XPath in 4016 ms

Lesson learned: javax.xml.xpath is slow as hell, even for very simple expressions.

This web site is still built with XSL using my good old Eclipse plugin Stylo Plume. Everything was OK for the past years, but a few weeks ago I wanted to redesign the news section on the home page, to add individual links to each announcement. I wanted something a bit like a blog, but without comments and fully in static html (no server-side PHP/Java/whatever).

In order to do so, I needed to add a new functionality to Stylo Plume, namely to enhance the dir:// protocol to be able to list sub-directories recursively. So 8 years after the last release, I searched in a bunch of old hard drives to recover my ancient CVS server and put the code in Mercurial. A public repository is now available on Bitbucket.

Release 0.2.0 is out today, it includes the modification to the dir:// protocol and the replacement of Xalan by the XML stack included in the JVM.

Oh, and there's even an Atom feed for the news, now!

More fun with modern JavaScript: here's another page to generate a small photo gallery.

I'm playing with HTML5 and modern JavaScript: here's a small page to generate a data url from a local file.

*looks on the right* Eh, what's that twitter thingy everybody's talking about?

New CSS theme, at last!

That was a loooooooong time, blame World of Warcraft... And I really need to change the look of these pages, they look so web 1.0 ;)

Anyway, I'm working on an HTTP debugging proxy called RedPill and entirely done in Java6. It monitors the traffic between your browser and the Internet, and can modify it. RedPill has a plugin mechanism, but sadly the GUI to configure it is not done yet.