Qi4j community migrated away from Maven after several years of frustration, especially around release management, versioning and cross-module dependency resolution issues, in Feb 2011. The tool of choice is now Gradle.

What ?

The case study I want to describe today is quite simple. I’m writing an application using Qi4j, it’s build is maven based. As I am contributing to Qi4j alongside the development of my own application I’m using the development branch of Qi4j most of the time. In maven terms it means my application depends on the last version SNAPSHOT. I want to continue working this way so I’ll describe here how to use the Qi4j build system for this use case.

In other words, you’ll learn how to manage the Qi4j build system for developing Qi4j and use it in maven projects.

What not ?

I will not talk about IDE support here, only build systems, namely maven and gradle.

Making it work

The main goal is to find gradle commands for different aims and make their run as short as possible.

I used the same computer for all time mesures present in this post, a Samsung netbook N150 with 2GB RAM and a Vetrex II solid state drive from OCZ.

Commands described here last from 45 minutes to 5 minutes for building and installing the whole Qi4j ecosystem in the local maven repository. When dealing with single modules all this gets very quick. For example org.qi4j.core.api can run in 20 seconds when skipping tests and javadoc.

Here are some example gradle commands. I use the gradle daemon to get rid of the startup time.

$ gradle install -Dversion=1.3.0-SNAPSHOT

This one takes forever, it will buid and install locally all artifacts (main, -sources, -javadoc),run tests and then generate the qi4j-sdk distribution archives. Took my netbook ~40 minutes.

When a maven build fails in continuous integration you often end up reading the console output, sometimes browsing kilobytes of text (yes, maven outputs a lot and can seem chaotic). To ease build debugging you can tell maven to output some introspectional data.

The idea is to use the maven-help-plugin a lot but you can add others and home made ones to the mix. To quickly see what can easily get outputed my maven you can play with the following commands :

Adding such output at the very start of builds is really handy when setting up a CI service or during build refactorings.

Note that if a profile is defined in a parent pom it won’t be shown as activated in submodules by help:active-profiles but if you read the help:effective-pom output on one of the modules you’ll see it’s effectively activated, see this comment in MNG-3228.

Application Component Provider: “The application component provider is the company or person who creates web components, enterprise beans, applets, or application clients for use in Java EE applications.”

Application Assembler: “The application assembler is the company or person who receives application modules from component providers and assembles them into a Java EE application EAR file.”

Application Deployer and Administrator: “The application deployer and administrator is the company or person who configures and deploys the Java EE application …”

This page says that this is the Application Assembler job to configure the deployment descriptor before packaging the EAR.

Beside that, artifact produced by mavenized enterprise projects are EARs, already packaged. Plus, it often is the developer (or Application Component Provider) that write the packaging configuration.

Next comes the “configuration for deployment” time. Here, if deployment dependant configuration is in deployment descriptors you would have to unpack the EAR and possibly nested java archives (WARs and/or JARs) to get a hand on all deployment descriptors.