Simple deployment from Gradle to Artifactory

The maven ecosystem works perfectly together with JFrog’s Artifactory, a wide spreaded repository manager for GAV artifacts, debian artifacts, bower, npm, ….. . Gradle, the rising competitor of Maven and Ant, fits also to the maven ecosystem but tries to stay independent by providing no native support for Maven repistories but plugins with (in my oppinion!) low documentation. Let’s have a look at the differences between a full fledged Artifactory integrated Maven setup and a similar Gradle setup.

Groovy Testcase with SSH Mock

package eu.christophburmeister.playground

class SshApp {

    private static final long SSH_TIMEOUT = 10000

    public String execute(String user, String host, int port, boolean strictHostKeyChecking, String command){
        String cmd

        if (strictHostKeyChecking) {
            cmd = "ssh ${user}@${host} -p ${port} '${command}'"
        } else {
            cmd = "ssh ${user}@${host} -p ${port} -o StrictHostKeyChecking=no ${command}"

        def cmdWithNewShell = ['/bin/sh', '-c', cmd]

        println cmd

        Process process = cmdWithNewShell.execute()
        def outBuffer = new StringBuffer()
        def errBuffer = new StringBuffer()

        process.consumeProcessOutput( outBuffer, errBuffer )

        if( outBuffer.size() > 0 ) return outBuffer.toString()
        if( errBuffer.size() > 0 ) throw new Exception(errBuffer.toString())

import static com.aestasit.ssh.mocks.MockSshServer.*

/** ... Thx guys, nice work 🙂 */
class SshAppTest extends GroovyTestCase{
    private static final String EXPECTED_RESPONSE = '''
            total 20
            drwxr-xr-x 3 1100 1100 4096 Aug  7 16:52 .
            drwxr-xr-x 8 1100 1100 4096 Aug  1 17:53 ..
            drwxr-xr-x 3 1100 1100 4096 Aug  7 16:49 examples
    private static final String EXPECTED_SUBSTRING = 'Unknown command: cat /etc/hosts'
    private static final String USER = 'christoph'
    private static final String HOST = 'localhost'
    private static final int SSH_PORT = 2323
    private static final boolean HOST_KEY_CHECK = false
    private static final String COMMAND_POSITIVE = 'ls -la'
    private static final String COMMAND_NEGATIVE = 'cat /etc/hosts'
    private SshApp cut;

    protected void setUp() {
        cut = new SshApp()
        command('^ls.*$') { inp, out, err, callback, env ->
            out << EXPECTED_RESPONSE

    protected void tearDown() {

    /** the command 'ls' is available in the ssh server's expectation */
    void testExecutePositive(){
        String actualResponse_positive = cut.execute(USER, HOST, SSH_PORT, HOST_KEY_CHECK, COMMAND_POSITIVE)
        assertEquals(EXPECTED_RESPONSE, actualResponse_positive)

    /** the command 'cat' is not (!) available in the ssh server's expectation */
    void testExecuteNegative(){
        String excMsg = shouldFail(){
group 'eu.christophburmeister.playground'
version '1.0-SNAPSHOT'

apply plugin: 'groovy'

repositories {

dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.3.11'
    testCompile group: 'junit', name: 'junit', version: '4.11'
    testCompile group: 'com.aestasit.infrastructure.mock', name: 'groovy-sshd-mock', version: '0.3'

Execute Jenkins Maven builds in Docker containers

When building software packages the build process itself might change some details in the underlying operating system or environment. This might also affect the next build as the environment is kind of „poluted“. So the best option would be to run the builds in an unchangeable environment or better: to run the different builds each in a new but identical machine. This could be reached via provisioning of heavy virtual os images. But this would mean to reserve a lot of system resources like CPU or RAM. So what we better need is a lightweight alternative for virtual machines. And one of those options is Docker. Docker containers provide process isolation on OS level while virtual machines offer isolation by creating hardware virtualization. For infrastucture use cases machine virtualization is an ideal option, but for our purposes (providing a recyclable build environment) software containers are the best choice.
With every build our build machine (jenkins) master will create a new runnable container from a docker image, run the build (including tests etc) and destroy it after everything was done. The build results can then be obtained from the jenkins master.

First steps with Ansible

Ansible is one part of the new hot stuff besides puppet, chef and other configuration management tools. This post will just present some first steps when playing around this tool.
Official documentation is quite good and there are lots of slides out there. For example the slides from Brian Candler where he shows a very good startup for anyone who is interested in Ansible.

So why should someone use Ansible instead of other tools? Maybe the most important point is the infrastructure you need, i.e. you only need a running SSH daemon and python (that is shipped by default with nearly all Linux distros). That’s it, no client required and SSH is manageable by most firewall operators as easy as HTTP traffic 🙂