Interesting links (week 8 2016)
Interesting links for week 8 2016:
Posts by Hubert Klein Ikkink
Groovy Goodness: Customise Groovydoc Output With Gradle
When we write our Groovy application we of course add documentation to our classes. If we use Gradle to build our project we can run the groovydoc task that is added by the Groovy plugin to generate documentation. We can set document and windows titles and a footer for the generated documentation by changing some properties of the groovydoc task. If we want some further customisation we must take some extra steps. The groovydoc task uses the GroovyDoc tool that is bundled with the Groovy library. GroovyDoc tool uses the GStringTemplateEngine to generate the documentation. The default template files are stored in the package org.codehaus.tools.groovydoc.gstringTemplates. The following files are in the package:
└── org
└── codehaus
└── groovy
└── tools
└── groovydoc
└── gstringTemplates
├── classLevel
│ └── classDocName.html
├── packageLevel
│ ├── package-frame.html
│ └── package-summary.html
└── topLevel
├── allclasses-frame.html
├── deprecated-list.html
├── help-doc.html
├── index-all.html
├── index.html
├── overview-frame.html
├── overview-summary.html
└── stylesheet.css
Ratpacked: Running With LiveReload Using Gradle
When we develop our Ratpack application using Gradle we can use the continuous build feature of Gradle. If we make a change in a source file then our Ratpack application is automatically restarted. It would be nice to combine this with LiveReload using the Gradle LiveReload plugin. Then when we change for example a stylesheet file it is automatically reloaded in the web browser without invoking a refresh action.
In the following build file we add the Gradle LiveReload plugin and configure it to watch for changes in the output directory of the processResources task. This task is executed when we change a file in the source directory if we use Gradle's continuous build feature.
Gradle Goodness: Build Script Using Java Syntax
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.
Gradle Goodness: Using Nested Domain Object Containers
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:
Interesting links (week 7 2016)
Interesting links for week 7 2016:
Gradle Goodness: Create Objects Using DSL With Domain Object Containers
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:
Ratpacked: Debugging Application Defined Using Groovy DSL In IntelliJ IDEA
When we want to debug our Ratpack application written in Java we can simply use the Debug action on the main application class. When we described the application with the Groovy DSL we must add a Groovy runtime configuration to our project in IntelliJ IDEA to support debugging of the (R|r)atpack.groovy script file.
First we select Run | Edit configurations.... IntelliJ IDEA opens a new dialog window where we can add or modify run/debug configurations. We select the option New configuration and choose the option Groovy:
Ratpacked: Running Ratpack In Groovy Console
It is actually very easy to run a Ratpack application in the Groovy Console. The Groovy Console is a GUI application that is distributed with Groovy and allows us to write and run Groovy scripts. We start the Groovy Console with the groovyConsole command: $ groovyConsole. To run a Ratpack application we only have to add a dependency to Ratpack using the @Grab annotation. We can write an application with the Groovy DSL and select Script | Run from the menu. If we make a change in the script file we invoke the Run command again. The Ratpack application restarts with our changes. This is very useful for trying out some Ratpack features without much hassle.
The following screenshot shows a simple Ratpack application. At the bottom we see the logging output of the running application:
Interesting links (week 6 2016)
Interesting links for week 6 2016:
Ratpacked: Different Base Directory With Marker File
To set the base directory for serving static files in a Ratpack application we can use the baseDir method of the ServerConfigBuilder class. We must provide a Path or File to this method. If we want to serve files from the class path, for example a JAR file or directory, we can use the find method of the class BaseDir. The find method will search the class path for a marker file with the name .ratpack. If the file is found then the directory or JAR file it is found in is used as the root of the file system. Normally the root of the class path is searched, but we can change the search path with an argument for the find method.
In the following sample Ratpack application we use the value web-resources/.ratpack.base.dir for the BaseDir.find method. So in our class path we must have a web-resources directory with the file .ratpack.base.dir that will serve as the root file system for serving static files.
Gradle Goodness: Specify Spock As Test Framework At Initialization
Since Gradle 2.11 we can specify the test framework to use when we initialise a project with the init task. There is a new option for this task: --test-framework. By default JUnit dependencies are added, but if we specify the value spock the Spock libraries are included in the dependencies section of our build.gradle file.
Let's run the init task to create a Java project with Spock as test framework:
