Suppose we have a project where we use Lombok annotations. To use it we must change the compiler configuration for our project and enable annotation processing. We can find this in the Preferences or Settings window under Build, Execution, Deployment | Compiler | Annotation Processors. Here we have a checkbox Enable annotation processing that we must check to use the annotations from IntelliJ IDEA. We can automate this setting with some configuration in our Gradle build file.
In the next example build file we alter the generated IntelliJ IDEA project file using the withXml hook. We can access the generated XML as a groovy.util.Node and change the XML.
Continue reading →
A tuple is an ordered, immutable list of elements.
Groovy has it's own groovy.lang.Tuple class.
We can create an instance of a Tuple by providing all elements that need to be in the Tuple via the constructor.
We cannot add new elements to a Tuple instance or remove elements.
We cannot even change elements in a tuple, so it is completely immutable.
This makes it very useable as return value for a method where we need to return multiple values.
Groovy also provides a Tuple2 class that can be used for tuple instance of only two elements. The elements are typed in a Tuple2 instance.
In the following example we see different uses of the Tuple and Tuple2 classes:
Continue reading →
We can add extensions to our project in Gradle to extend the build script with extra capabilities. Actually we can add extensions to any object in Gradle that implements the ExtensionAware interface. The Task interface for example extends the ExtensionAware interface so we can add custom extensions to Gradle tasks as well. Inside a task configuration we can then use that extension.
In the following build script we use a custom extension for JavaCompile tasks to configure the compiler -Xlint arguments. The extension is added via the plugin com.mrhaki.gradle.JavaCompilerLintPlugin. First we take a look ate the extension class. This is a POGO for configuring the compiler arguments with -Xlint options:
Continue reading →
When we create our own custom tasks we might need to support lazy evaluation of task properties. A Gradle build has three phases: initialisation, configuration and execution. Task properties can be set during the configuration phase, for example when a task is configured in a build file. But our task can also evaluate the value for a task property at execution time. To support evaluation during execution time we must write a lazy getter method for the property. Also we must define the task property with def or type Object. Because of the Object type we can use different types to set a value. For example a Groovy Closure or Callable interface implementation can be used to execute later than during the configuration phase of our Gradle build. Inside the getter method we invoke the Closure or Callable to get the real value of the task property.
Let's see this with a example task. We create a simple class with two task properties: user and outputFile. The user property must return a String object and the outputFile property a File object. For the outputFile property we write a getOutputFile method. We delegate to the Project.file method, which already accepts different argument types for lazy evaluation. We also write an implementation for getUser method where we run a Closure or Callable object if that is used to set the property value.
Continue reading →
If we create our own tasks in Gradle we usually extend from the DefaultTask or a subclass of DefaultTask. The tasks that are included with Gradle also extend from this class. Gradle will create a proxy class for the actual class implementation and adds (among other things) also a property setter method. The method has the name of the property and has a single argument of the same type as the property. It is different from the setProperty and getProperty methods already added by Groovy. For example if we have a task with a property with the name message of type String then Gradle will add the method message(String) to the proxy class.
In the following example task we have one property user:
Continue reading →
When we define dependencies in Gradle we usually define them to compile source files. For example we create a Java project and need the Spring framework, then we define a dependencies configuration block with a dependency to the Spring libraries for the compile configuration. We can also use the dependencies configuration block to define dependencies on artifacts used in other tasks than the compiling source files. For example we might have a multi-module project where we want to aggregate artifacts from several projects into one place with the Copy task.
In the following example we have a multi-module project where projects projectA and projectB have a dist task to create a Tar file. In the project docker we want to copy the Tar files from those projects into the build directory. To achieve this we first apply the Gradle base plugin, because then we can use the artifacts configuration block. Inside the artifacts configuration we define that our dist task that creates the Tar file is assigned to the dockerDist configuration as artifact. This sets up our projects that create the artifact. The docker project uses these artifacts in the task prepare. The prepare task copies the artifacts of projectA and projectB to the build directory of the docker project.
Continue reading →
Interesting links for week 8 2016:
Continue reading →
A Gradle build script is actually a Groovy script. The Gradle API uses Groovy a lot so we can have a nice DSL to define our builds. But we can also use Java code in a Groovy script. The compiler that compiles the build script understands Java code as well as the Groovy code. Sometimes I hear from people new to Gradle that they have difficulty understanding the DSL. I thought it would be a fun exercise to write a very simple Gradle build script using Java syntax.
Most notable is that we invoke the getProject method to get a reference to org.grade.api.Project. In the Gradle DSL we could use the simpler Groovy property reference project or just leave it out, because all method invocations in the build script are delegated to Project.
Continue reading →
In a previous post we learned how to use the NamedDomainObjectContainer class. We could create new objects using a nice DSL in Gradle. But what if we want to use DSL syntax to create objects within objects? We can use the same mechanism to achieve this by nesting NamedDomainObjectContainer objects.
We want to support the following DSL to create a collection of Server objects, where each server can have multiple Node objects:
Continue reading →
Interesting links for week 7 2016:
Continue reading →
Gradle offers the NamedDomainObjectContainer class to create a collection of objects defined using a clean DSL. The only requirement for the objects we want to create is that they have a constructor that takes a String argument and a name property to identify the object. The value for the name property must be unique within the collection of objects. We create a new instance of a NamedDomainObjectContainer with the container method of the Gradle Project class. We can add the NamedDomainObjectContainer instance to the extensions property of our project, so we can use a DSL to create instances of objects that need to be in the NamedDomainObjectContainer object in our project.
The following code shows a simple build script in which we want to create a collection of Product objects. The creation of the NamedDomainObjectContainer object is done in a plugin so we only have to apply the plugin to use the DSL to create Product objects:
Continue reading →
I am still settling down from an awesome week in Sweden, where I went for the JFokus conference and subsequent speaker conference. Both were of epic proportions, and I would like to share my experience of giving a presentation there that I would not soon forget. My presentation on Evolutionary Algorithms titled “Making Darwin Proud: Coding Evolutionary Algorithms in Java” was scheduled for Tuesday, making it a very special session. Not only was it the 10th “birthday” of JFokus, it was also the 1st birthday of my son Olivier. It was a tough decision to speak at JFokus instead of being at home to celebrate my sons very first birthday, but as my wife said “he’s not going to remember you weren’t there on the specific day…we’ll celebrate extensively before you leave for Sweden” (I love my wife). However, I still wanted to do something special for my boy, which led me to come up with the ludicrous idea of starting out the presentation by asking the audience (some 450 developers) if they would sing Happy Birthday with me while I recorded it with my phone. They did, and it was awesome! I would like to use this opportunity to thank them from the bottom of my heart, because they made the day, and gave my wife, Olivier and me so much joy by doing this. The tweet that followed is one of the most retweeted and liked I’ve ever had (as well it should be!): https://twitter.com/BWknopper/status/697107401686675457 After our singing intro, I felt a connection with the audience I haven’t felt before (and I gave this talk a couple of times) which in turn led to one of the most fun and relaxed presentations I ever gave. The abstract of the presentation:
Java Developers sometimes face programming challenges, such as creating a school roster or determining a salesperson’s optimal route, that are extremely difficult to crack using conventional approaches. Discover how Evolutionary Algorithms can be applied to solve these complex puzzles. The session starts with a success story from the NASA space archives to explain the concepts. Once the stage is set, it’s puzzle solving time! Learn to code Evolutionary Algorithms using plain Java - although existing Java frameworks such as JGAP are also addressed. The session concludes with a checklist that can be used to determine whether Evolutionary Algorithms are a good fit to the problem. With this checklist, the decision has never been easier!
Continue reading →
