Suppose we use the Gradle apply from: statement to import another Gradle build file into our build file. The external build file uses a Gradle plugin that needs a buildscript block to define the classpath configuration with the classes needed for the plugin. We cannot use the plugin id inside our external build script to use it, but we must use the type of the plugin. Otherwise Gradle cannot resolve the plugin from the main build file.
Let's create a simple Gradle build that we want to include in our main Gradle build file:
Continue reading →
Grails 3 makes it very easy to create a JAR file that is runnable with a simple $java -jar command. We must use the Grails command package or the Gradle task assemble to package our application as a so-called runnable JAR file. This JAR file has all the necessary classes to start up our Grails application.
In the following example we have a Grails application sample-app. We use the Gradle task assemble to package the application into a JAR file. The resulting JAR file can be found in the build/libs directory of our project:
Continue reading →
Asciidoctor is a great tool for writing technical documentation. The documentation to our Java source is what we write in Javadoc comments. Wouldn't it be nice if we could use Asciidoctor in our Javadoc comments? Of course! We can achieve this with the Asciidoclet Javadoc doclet. The doclet processes the Javadoc comments as Asciidoctor source and generates HTML in the final Javadoc documentation. We can use all of Asciidoc syntax like tables, lists, include directives, styling and more. We can even use Asciidoctor extensions like asciidoctor-diagram.
In the following Java source code we have Javadoc comments with Asciidoctor syntax. We have document attributes, list, styling, include macro, table and asciidoctor-diagram code in our Javadoc. Notice that we don't have the clutter of HTML tags we normally we would have if we write Javadoc.
Continue reading →
In a previous post we learned how to log request information in common log or NCSA format. But we can also provide our own implementation of a RequestLogger to log for example the time spent in processing a request. One of the easiest ways to do this is by using the RequestLogger.of method. We can provide a lambda expression or closure for this method with an argument type RequestOutcome. The RequestOutcome class has properties to access the request and sent response objects. And it also contains a Duration object which has the duration of the time spent for the total request (all handlers in the chain). This doesn't include the necessary time to send the request to the client.
import ratpack.handling.RequestLogger
import static ratpack.groovy.Groovy.ratpack
ratpack {
handlers {
// Here we use the of method to implement
// custom request logging.
all(RequestLogger.of { outcome ->
// Only log when logger is enabled.
if (RequestLogger.LOGGER.infoEnabled) {
// Log how long the request handling took.
RequestLogger.LOGGER.info(
'Request for {} took {}.{} seconds.',
outcome.request.uri,
outcome.duration.seconds,
outcome.duration.nano)
}
})
get {
render 'Ratpack rules!'
}
}
}
Continue reading →
Ratpack comes with a special handler to log requests in the common log or NCSA format. We need the (default) interface ratpack.handling.RequestLogger which has a method ncsa that returns a handler instance capable of logging our request data.
In the following example code we have a Groovy DSL definition of our Ratpack application. We use the all method to add the request logger. The RequestLogger implementation will make sure the complete handler chain is finished before logging the information.
Continue reading →
To start our Ratpack application with a random port number we must use the value 0 as port number. The value 0 tells Ratpack to use a random port number (in a safe port range).
In the following example Ratpack application we configure the server port to be random:
Continue reading →
When we define a Ratpack application we can set a server port in the server configuration code. When we do not define the port number in our code and use the default server configuration we can also set the server port with the environment variables PORT or RATPACK_PORT.
In the following example we use Gradle as build tool to run our Ratpack application. Gradle will pass on environment variables to the run task. We use the environment variable RATPACK_PORT to change the port to 9000:
Continue reading →
To define project properties outside the Gradle build file, we can define them in a file gradle.properties in our project directory. If we want to define property values that are used by all Gradle builds we can create a file gradle.properties in the GRADLE_USER_HOME directory. By default this is in the USER_HOME/.gradle directory.
In the following example gradle.properties file we assign values to some properties that can be used in all Gradle builds we run on our computer. We store the file in USER_HOME/.gradle.
Continue reading →
Ratpack applications can be written in Java and Groovy. The Java API is already very clean and on top is a Groovy DSL to work with Ratpack. When we use Groovy we can use the DSL, which allows for more clean code. The Ratpack developers have used the @DelegateTo annotation in the source code for the DSL definition. The annotation can be used to indicate which class or interface is used as delegate to execute the closure that is passed to the method. And this helps us a lot in the code editor of IntelliJ IDEA, because IDEA uses this information to give us code completion when we use the Groovy DSL in Ratpack. And that makes using the DSL very easy, because we rely on the IDE to give us the supported properties and methods and we make less mistakes.
Let's see this with an example in code. First we create a new Ratpack.groovy file:
Continue reading →
Gradle has an idea and eclipse plugin that we can use to configure IntelliJ IDEA and Eclipse project files. When we apply these plugins to our project we get extra tasks to generate and change project files. Inside our Gradle build file we get new configuration blocks to specify properties or invoke methods that will change the configuration files. One of the nice things to add is to let the IDE download Javadoc files for dependencies in our Java/Groovy projects. By default the sources for a dependency are already downloaded and added to the project, but Javadoc files are not downloaded.
In the example build file we use the idea and eclipse plugins. We also add an idea and eclipse configuration block. The place where we need to set the property downloadJavadoc is a bit different, but the end result will be the same.
Continue reading →
Ratpack is from the ground up build to be performant and asynchronous. Let's add a logging implementation that matches the asynchronous nature of Ratpack. Ratpack uses the SLF4J API for logging and if we write logging statement in our own code we should use the same API. For Groovy developers it is nothing more than adding the @Slf4j AST annotation to our classes. The Logback library has an asynchronous appender which has a queue to store incoming logging events. Then a worker on a different thread will invoke a classic blocking appender, like a file or console appender, to actually log the messages. But in our example we don't use the standard async appender from Logback, but use a asynchronous logbook appender from the Reactor project. Now our queue is backed by a very performant reactor ring buffer implementation.
The following Logback configuration file shows how we can configure the reactor.logback.AsyncAppender:
Continue reading →
To start our Ratpack application with a random port number we must use the value 0 as port number. The value 0 tells Ratpack to use a random port number (in a safe port range).
In the following example Ratpack application we configure the server port to be random:
Continue reading →
