Maven testing

One of the bothering thing being a contractor is that you often happen to work on a project with a skip tests flag set on all developers computer.

One of the thing I tend to do when on such project is enabling tests and trying to fix as much as possible (often the fixes are easy to do).

Multi module testing

By design, surefire plugin make the build fail if there is a test failure. While this is ok in single module, when working with multi-module project it can be nice to run all tests on all modules regardless of the failures happening in some modules.

Maven is a great tool and allows such a behavior very easily, it allows two command line switches for that :

  • --fail-at-end : will fail the build at the end if there is test failures
  • --fail-never : will never fail the build, even if there is test failures

Flags behavior differences

There is one thing to understand when using the --fail-at-end flag, it will fail the build at end for a module with test failure but it will also prevents building of dependent modules.

With a small example it become obvious. Let’s say that we have a multi project containing the following :

  • core : containing model objects and services
  • web : containing web views for browser access
  • javafx : containing desktop application classes

It is straightforward to see that web and javafx modules will depends on the core module.


If using the --fail-at-end flag, a test failure in the core module will prevent building the web and javafx module completely : you will not be able to track tests failure before fixing the ones from core (at least on a single build command).


If using the --fail-never flag, a test failure in the core module will be reported but the build and tests of the web and javafx modules will be built and their respective tests errors will also be reported.

Tired of typing

If you find that typing --fail-at-end is too long, remember yourself it short alias : -fae.

The same is also available for the --fail-never flag with : -fn.

Switching keymap

As some of you might know, I am now using a Typematrix 2030 on a daily basis. When I switched to this great keyboard I also adopted a new layout on it : Colemak.

However, to be able to pair with others not using a Colemak mapping, I did not set the default mapping to Colemak but I instead use an udev rule to set the input method to Colemak only for the Typematrix.

Write a keymap switch script

Thanks to @BitardMichael tips and existing scripts I ended up with the following script saved in /usr/local/bin/set_typematrix_colemak_mapping

One of the tricky part was having a way of executing the script only when the keyboard is ready, without blocking udev’s job (or the keyboard is not yet visible by the X system). The workaround I found was scheduling the execution of the job with the simple at command.

Tell udev to run the script on keyboard detection

The process is really easy, all you need to do is to add the following to a new file : /lib/udev/rules.d/85-typematrix.rules

Adapting it to your use case

If you are using another keyboard than a Typematrix you will need to adapt the udev rule with the proper Vendor / Product IDs (you can grab them with lsusb). For the xinput part, you will need to adjust the grep to match your hardware.

Of course the same goes for your layout : colemak / dvorak / bépo …

Arquillian testing

Arquillian testing is very convenient to get a full environment deployed on an application server and test quickly. However sometimes we need to debug what’s inside.

Launch Maven in Debug mode

One way of doing it can be launching Maven in debug mode with the mvnDebug command instead of the classical mvn. It will open a JPDA debugger on port 8000 by default, you then just need to connect to it with your preferred IDE. But, if there is forked processes, you won’t be able to debug inside them.

Launch Failsafe Integration Tests in Debug mode

When using Arquillian, there is a high probability that Arquillian is running in a forked process (with embedded containers).

There is an easy way to tell maven-failsafe-plugin to wait for a debugger when starting : use the -Dmaven.failsafe.debug property.

You can even specify the options as you would in $JAVA_OPTS to change ports / wait…


A few days ago, I finally decided to upgrade the installed Linux on my dedicated box hosted at OVH. As with every task you tend to postpone until it is too late, it failed miserably, Murphy’s law I am looking at you right now !

During the install process, the machine hanged (I am not sure whether the machine is faulty or not, it seems to shut down under heavy load). Fortunately for me, OVH is kind enough to send a tech resets the machine, and if it does not ping when booted, the tech reboots the machine in rescue mode.

Rescue mode

The rescue mode is a lightweight Linux booted on the machine so you can run fsckand other commands to rescue your filesystem (you can even scp files to backup before a reinstall for example.

My problem was simple, I needed to allow dpkg to finish its job in order for me to get a working machine. Then I think of the good old powerful chroot command and I remembered how powerful Unixes are !

Mounting filesystems

As you should know, chroot is a command allowing to change the root of a file system, litterally jailing it into a directory (popular things of today like pico containers like Docker are improved versions of chroot).

The partition layout of my machine is the following :

  • sda1 contains the root filesystem
  • sda2 contains home directories

I issued the following commands to “jail” the rescue mode into my machine :

$ mount /dev/sda1 /mnt
$ mount /dev/sda2 /mnt/home
$ mount -o bind /proc /mnt/proc
$ mount -o bind /dev /mnt/dev
$ mount -o bind /dev/pts /mnt/dev/pts
$ mount -o bind /sys /mnt/sys 
$ chroot /mnt/

From then, I was on my machine, with my files and so on, so I have been able to run dpkg to finish the install :

$ dpkg --configure --a

Finally, dpkg sent me back to a working prompt and I have been able to reboot the machine (do not forget to change boot disk in OVH manager to hd or netboot to prevent rebooting in rescue mode).

Command line nerd

As a command line geek, I always have at least one open and tend to use it for everything on my machine.

HomeBrew is a very convenient tool to install command line tools to your Mac without cluttering up your environment. You can use it like your Linux friends are using apt-get or yum and it feels really nice.

One thing that your friend can do and you cannot, is installing Google Chrome only using command line, this is where HomeBrew Cask comes to the rescue.

Installation guide

Cask will be up and running in a very few steps :

$ brew tap phinze/cask
$ brew install brew-cask
$ brew cask install dropbox #for example

Usage hint

This tool is really nice because it allows you to script your machine setup. No more headaches forgetting the installation of when you want to use it.

Don’t hesitate to add a small script in your .dotfiles to seed your software on new machines, and if your preferred software is missing, it is really easy to add new casks.