IntelliJ IDEA 2016.1 introduced better support for Gradle source sets. Each source set in our project becomes a module in the IntelliJ IDEA project. And each module has it’s own dependencies, also between source sets. For example if we simply apply the java plugin in our project we already get two source sets: main and test. For compiling the test sources there is a dependency to the main source set. IntelliJ now knows how to handle this.
To create IntelliJ IDEA project files with Gradle we first need to apply the
idea plugin. We can then further customise the created files. In this blog post we will add a Spring facet to the generated module file. By adding the Spring facet IntelliJ IDEA can automatically search for Spring configuration files. We can then use the Spring view to see which beans are configured in our project.
When we use the IDEA plugin in Gradle we can generate IntelliJ IDEA project files. We can customise the generated files in different ways. One of them is using a simple DSL to configure certain parts of the project file. With the DSL it is easy to set the version control system (VCS) used in our project.
In the next example build file we customise the generated IDEA project file and set Git as the version control system. The property is still incubating, but we can use it to have a proper configuration.
// File: build.gradle
apply plugin: 'groovy'
apply plugin: 'idea'
// Set the version control system
// to Git for this project.
// All values IntelliJ IDEA supports
// can be used. E.g. Subversion, Mercurial.
vcs = 'Git'
Written with Gradle 2.12 and IntelliJ IDEA 15.
When we run tests in IntelliJ IDEA the code is compiled by IntelliJ IDEA and the JUnit test runner is used. We get a nice graphical overview of the tasks that are executed and their results. If we use Gradle as the build tool for our project we can tell IntelliJ IDEA to always use Gradle for running tests.
To quickly start with a Spring project we can use the website start.spring.io. Via a user interface we can set project properties and at the end we have a project archive (Zip or gzipped Tar file) or build file (
build.gradle). We can also directory access an URL to create the output files and we set the properties via request parameters. This way you can share a link with someone and if they click on it they will download the generated project archive or build files.
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.
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
It has already been a week since Javaland 2016 started on Tuesday March 8th. Javaland is 3-day community driven conference in the amusement park Phantasialand in Brühl, Germany. I had the fortune to attend the conference this year and speak about Asciidoctor on the first day with my talk “Writing documentation in Asciidoctor is Awesome”. The code and examples from the presentation are on Github. Also my colleague Rob Brinkman was at the conference for this talk about “Westy Tracking (turning a VW van into a Tesla)” and his presentation is online as well.
What I really liked about the conference is a lot of technical talks about all kind of Java subjects. Even for a non-German person there were a lot of talks in English to follow. Also the atmosphere was very nice, people are approachable and in between talks there was a nice community and sponsor exhibition room. The organization uses the knowledge and experience of 29 JUGs from Germany, Austria and Switzerland. And then the location is also great to have a conference. The amusement park wasn’t open for the public so we as Java developers had part of the park for ourselves. The location of the talks were partially in theaters and in business rooms. And at Tuesday night we were allowed to go on rides as well. (Remember: first rides, then eat and drink, if you alter the order you might get in trouble).
The first day started with an explanation about the program, talks, different community events from the organization. Next we attended a session about how to visualize relations between Wikipedia articles from James Weaver. He showed a Spring application backend with an Angular frontend running on Cloudfoundry. Next up was Rob Brinkman with his excellent talk on how he added electronics to an “old” VW van, so he could save his trips and tracking information. He showed the software architecture he used with Vert.x 3, Redis, Java 8 and Angular to make it all work together. It was time for lunch and that was very good organized. A lot of different things to choose from and it tasted very well. After lunch we attended a short talk about streams and reactive programming that was very informative given by Jan Carsten Lohmüller. In the afternoon we stayed a while at the community floor and stumbled upon a nice small presentation from Andres Almiray about a JSR for desktop applications. The setting was very informative and I really liked this aspect of the conference. Furthermore we attended a session about Lombok to reduce the boilerplate code in Java presented by Roel Spilker and Reinier Zwitserloot. Bert Jan Schrijver gave a good presentation about performance testing with Gatling. He even did live Scala coding on stage! Gatling looks like a very nice tool to define scenario’s for simulating multiple users accessing your application.
At night the park was open and some attractions were open, especially the roller coaster rides. Also there was a good diner organized at different locations.
The second day of the conference started for me with a talk by Josh Long about Spring Cloud. The Spring Cloud project has a lot of very useful subprojects to work with microservices in a distributed manner. Even though the session could only last 40 minutes Josh managed to show a lot of cool stuff with live coding small applications. At lunch time I attended a good talk which started with a cool Lego demo by Johan Janssen and Martin Kanters. They managed to control Lego trains and a fairy wheel from their browser. And it all worked as well. They used Akka on Raspberry Pi’s to make it all work and explained the software architecture.
After another tasteful lunch I learned more about monads in Java 8. Normally this is a very theoretical subject, but presenter Oleg Shelajev did a good job and showed real code on how monads appear in Java. The last session of the day was about using Groovy as a system scripting language by Andrey Adamovich. He showed the cool stuff of Groovy to make as script developer so much easier. Instead of relying on Bash or another script language, just use Groovy and all the Java libaries we already know.
The final day of the conference was a tutorial/workshop day. I attended a Vert.x 3 workshop given by Jochen Mader. Although it was in German I could still follow it very well. He presented some theory and then we could make small exercises in Vert.x 3. Then we would look at possible solutions for the exercise given by Jochen. I learned a lot during this day.
It was the first time I went to Javaland and it was a very good experience. The location, the organization and the content are all excellent. Although I already know I cannot make it next year, I still want to come back during the next years.
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.
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
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
Callable to get the real value of the task property.