So you really need that java lib somebody made but they can’t be bothered to upload it to maven central or jcenter? Build it yourself and host it on your nexus repo. That’s what the script below does. Additionally, it includes a little xslt magic which allows to change the pom.xml in any way you want. Are they using snapshot versions? No problem, just insert your own (as shown in the script). Need to change a dependency? With some more xslt you can definitely do that too! You can run this script locally or on a build server (the script is using jenkins’ BUILD_NUMBER environment variable).

A project I’m working on has accumulated a bunch of repositories we need for the build.gradle script and for the build itself. I don’t want to keep everything twice so I thought some re-use is in order. Thanks to the excellent gradle javadocs and api design, it was easy to accomplish. The end result is this:

// add your repositories here
buildscript {
    repositories {
        mavenLocal()
        jcenter()
        maven {
            credentials {
                username 'user'
                password 'pass'
            }
            url 'https://example.com/maven2'
    }
}

// re-use repositories from buildscript
buildscript.repositories.each { repositories.add(it) }

I currently need to generate some java sources from a wsdl with Gradle. In Maven, I’ve done this using the cxf-codegen-plugin but I want to avoid using anything that’s maven in my new build. And there’s several resources out there who will either tell you to call WSDLToJava via cxf’s ant task or directly. The ‘direct’ way still leaves you with several possibilities like calling ProcessBuilder from your Gradle Task or using a JavaExec Task. I went for the last.

I currently need to generate some java sources from a wsdl with Gradle. In Maven, I’ve done this using the cxf-codegen-plugin but I want to avoid using anything that’s maven in my new build. And there’s several resources out there who will either tell you to call WSDLToJava via cxf’s ant task or directly. The ‘direct’ way still leaves you with several possibilities like calling ProcessBuilder from your Gradle Task or using a JavaExec Task. I went for the last.

Here’s another little “gotcha” on gradle tasks. When they’re triggered. I’ve seen quite a few posts on stackoverflow along the lines of “How can I call a gradle task”. You can’t (Well ok you could but you don’t want to). It is executed as a dependency of another task.

Going back to that little copy task I wanted to execute, I needed it to run roughly somewhere after the clean task and before jar task. I ended up making my copy task dependent of compile. That didn’t work so I tried compileJava and classes and… only to later realize that the dependency was in the wrong direction: My task depends on one that is being executed but that doesn’t trigger my task, it merely states that my task, should it be executed, can only be run after some other task.

Here’s another little “gotcha” on gradle tasks. When they’re triggered. I’ve seen quite a few posts on stackoverflow along the lines of “How can I call a gradle task”. You can’t (Well ok you could but you don’t want to). It is executed as a dependency of another task.

Going back to that little copy task I wanted to execute, I needed it to run roughly somewhere after the clean task and before jar task. I ended up making my copy task dependent of compile. That didn’t work so I tried compileJava and classes and… only to later realize that the dependency was in the wrong direction: My task depends on one that is being executed but that doesn’t trigger my task, it merely states that my task, should it be executed, can only be run after some other task.

So I’m trying out gradle in the hope of being able to simplify and streamline an existing maven build which is quite large and inconsistent. And I just spent some time to figure out a few gotcha about gradle tasks and this post is to help others understand, because I think the gradle docs aren’t clear enough on this point

What I wanted to achieve is, to copy all *.properties files in src/main/java to the resources-output directory so they are included in the jar, because javac won’t pick them up since they’re no java source files. What happened was that, depending on what approach I tried, sometimes the copy worked sometimes it didn’t and I couldn’t understand why.

So I’m trying out gradle in the hope of being able to simplify and streamline an existing maven build which is quite large and inconsistent. And I just spent some time to figure out a few gotcha about gradle tasks and this post is to help others understand, because I think the gradle docs aren’t clear enough on this point

What I wanted to achieve is, to copy all *.properties files in src/main/java to the resources-output directory so they are included in the jar, because javac won’t pick them up since they’re no java source files. What happened was that, depending on what approach I tried, sometimes the copy worked sometimes it didn’t and I couldn’t understand why.

I have one primary development notebook and take that with me wherever I go. Now in a company setting you usually have proxies and whatnot. And I think it’s an official best practice to roll your own company or departement maven proxy/cache.

So dependent on where you are, you might need a different maven ~/.m2/settings.xml file. Here’s a very simple shell function you can add to your ~/.bashrc

function mvn {
        MVN="$(which mvn)"
        if [ -n "$(ifconfig eth0 | grep YOUR-WORK-IP-HERE)" ]; then
                echo ">>> Running mvn whith work config"
                ${MVN} -gs ${HOME}/.m2/settings-work.xml $*
        else
                echo ">>> Running mvn with vanilla config"
                ${MVN} $*
        fi
}

This just checks for the ip of eth0 and calls mvn with a special settings.xml. In all other cases mvn is run with the vanilla config (or none, since the settings.xml is optional).

I have one primary development notebook and take that with me wherever I go. Now in a company setting you usually have proxies and whatnot. And I think it’s an official best practice to roll your own company or departement maven proxy/cache.

So dependent on where you are, you might need a different maven ~/.m2/settings.xml file. Here’s a very simple shell function you can add to your ~/.bashrc

function mvn {
        MVN="$(which mvn)"
        if [ -n "$(ifconfig eth0 | grep YOUR-WORK-IP-HERE)" ]; then
                echo ">>> Running mvn whith work config"
                ${MVN} -gs ${HOME}/.m2/settings-work.xml $*
        else
                echo ">>> Running mvn with vanilla config"
                ${MVN} $*
        fi
}

This just checks for the ip of eth0 and calls mvn with a special settings.xml. In all other cases mvn is run with the vanilla config (or none, since the settings.xml is optional).