Gradle - always use settings.gradle

             

I had an issue today where I was working with Jenkins and my release package was given the same name as the Jenkins job. For those of you familiar with Jenkins and the Git plugin, you will know that the workspace is given the same name as the job name, and the source is downloaded into the workspace. What you may not have known is that Gradle infers the name of the project from the root dir name.


Vagrant, Amazon EC2, Docker and Microservices pt4.

              · · · · · · ·

The Microservice For this tutorial I’m going to use a spring boot application that will help us prove the concepts behind this tutorial. There are loads of microservice frameworks to chose from, but for this tutorial we will use Spring Boot. Maybe in the future I will look at trying out some other popular frameworks. Links to the Spring guide are given at the bottom of this tutorial. At this point we could cheat and do everything in Gradle.


Vagrant, Amazon EC2, Docker and Microservices pt3.

              · · · · · ·

Part 3 - a bit of back pedaling After thinking about the ‘hack’ I put in to get Puppet installed on the box before I could use it, I felt a little dirty, and decided that maybe Puppet wasn’t the best decision after-all. So, the problem is that I need an agent installed before I can provision my box, but I’m trying to automate the provisioning - catch 22. Here’s where Ansible has really stepped up.


The GradleBuild task

             

task myTask(type: GradleBuild) { } If you have ever imported another build using apply from: "${rootDir}/gradle/publish.gradle" then you will appreciate how its a little difficult to know exactly what has been applied to your build by said apply action. I often use this pattern when I want to clearly seperate the parts of my build. In my build scripts you may see something like: apply from: "${rootDir}/gradle/sonar.gradle" apply from: "${rootDir}/gradle/acceptance-testing.


Vagrant, Amazon EC2, Docker and Microservices pt2.

              · · · · ·

Part 2 In the first part of this tutorial, we showed how to use Vagrant to automate and manage an Amazon EC2 instance. We defined a simple Vagrantfile to specify certain attributes for an instance to run, and got it running using Vagrant’s command line tools. In this part of the tutorial, we’ll be using Puppet to define and automate the configuration details for our instance. This way, whenever we start up the environment with vagrant up, it will be set up to run Docker without any additional manual configuration.


Dependency Management - Modeling Suppliers and Consumers pt.1

              · · · ·

Dependency management has come a long way over the past 10 years, but I believe it has some way to go before we can say the problem is solved. Consider the scenario where you have developed a library which inadvertently introduced a severe security vulnerability. Because your organisation believes in reuse it has been used in many different projects. The Maven POM (Project Object Model) does a good job in providing us with meta-data about the modules which are suppliers to a project, but it doesn’t capture information about who the consumers are.


Vagrant, Amazon EC2, Docker and Microservices pt1.

              · · · · ·

Microservices are all the rage at the moment, but from my experience they just move the bottleneck. Yes, the speed of development increases massively, but it does so at the cost of an increased dependency on the Build and Ops guys. This blog series is about using Docker to run a complete and fully functional microservice in the cloud using Vagrant, Amazon AWS and Docker. The goals are as follows:


Reading a POM from Gradle

              · ·

Reading a Maven POM is Easy with Gradle and Groovy! The inspiration for this post came from the post here: Reading info from existing pom.xml file using Gradle? Naively I implemented the first solution which is given below. defaultTasks 'hello' repositories { mavenCentral() } configurations { mavenAntTasks } dependencies { mavenAntTasks 'org.apache.maven:maven-ant-tasks:2.1.3' } task hello << { ant.taskdef( resource: 'org/apache/maven/artifact/ant/antlib.xml', uri: 'antlib:org.apache.maven.artifact.ant', classpath: configurations.mavenAntTasks.asPath) ant.'antlib:org.apache.maven.artifact.ant:pom'(id:'mypom', file:'pom.xml') println ant.references['mypom'].version } Now, this solution did meet the original posters requirement.


Debugging Gradle Plugins in Intellij

              · · ·

Ok, so this one had me stumped for a while and the solution was extremely simple. I read lots of information in the Gradle forums on this and it sent me in the wrong direction. Loads of articles saying to set certain flags/GRADLE_OPTS, which isnt necessary. So, in Intellij (im using version 14), set your breakpoint and from the Gradle Tool Window in ‘all tasks’ area, right click the task and select the debug option from the context menu.