Groovy cli app with specifyable log4j target logfile

It may happen, that you wish to specify a custom location of your logfile when running your Java app. Within this post I use an example cli application that is written in Groovy and build with Gradle. By passing „–logfile=mylogfile.log“ it will write all logs to the specified location, while it is using the Slf4j-annotation described in one of my previous posts.

Continuous Delivery-ready Gradle project with Artifactory and Sonarqube integration

When playing around with the concepts of Continuous Integration/Delivery/Deployment I struggled over Gradle builds and how to integrate them in these concepts. Gradle is getting more and more important in build tool landscape and so I created a template or archetype about how to use it.
I choose a scenario that I saw already implemented with Maven and other tools:

  1. pushing a VCS change to central VCS
  2. tagging that change to a specific id and pushing it back to central VCS
  3. executing the build with unit tests
  4. executing the sonar analysis
  5. executing the artifactory upload

This chain gives you the ability of continuously having every change explicitely tagged, unit-tested, analyzed and uploaded to your artifact repository, ready for deployment. In short, this is (from my point of view) the spirit of Continuous Delivery.


Deploy specific versions of Jenkins-plugins via Artifactory-caching

Jenkins can be configured in many ways. When trying to find a suitable solution for deployment of plugins, we’ve been facing to the problem of using not (!) the latest and greatest plugin versions. This can be necessary when using the jobdsl plugin without having the resources to update our own dsl library when there comes up a non-downstream-compatible version of the jobdsl plugin. But this is only one example, there are more 🙂