In Gradle we can configure how duplicate files should be handled by the Copy task. Actually we can configure how duplicate files are handled by any task that implements the CopySpec interface. For example archive tasks also implements this interface. We must use the setDuplicatesStrategy method to configure how Gradle behaves. The parameter is a value of the enumeration DuplicatesStrategy. We can use the values from the enum class or use String values, which are automatically converted to enum DuplicatesStrategy values.

We can choose the following strategies:

Continue reading →

The nice thing about Gradle is that we can use Java libraries in our build script. This way we can add extra functionality to our build script in an easy way. We must use the classpath dependency configuration for our build script to include the library. For example we can include the library Grgit, which provides an easy way to interact with Git from Java or Groovy code. This library is also the basis for the Gradle Git plugin.

In the next example build file we add the Grgit library to our build script classpath. Then we use the open method of the Grgit class. From the returned object we invoke the head to get the commit id identified as id. With the abbreviatedId property we get the shorter version of the Git commit id. The build file also includes the application plugin. We customize the applicationDistribution CopySpec from the plugin and expand the properties in a VERSION file. This way our distribution always includes a plain text file VERSION with the Git commit id of the code.

Continue reading →

Scala has no default way to deal with dates and times. We have a few options. java.util.Date and java.util.Calendar These come included with java, so they may do if you don't need to do much and don't want to add any dependencies. But they're horrible and it's best not to use them. Joda-Time http://www.joda.org/joda-time/ The de facto standard date and time library for Java. nscala-time https://github.com/nscala-time/nscala-time A thin scala layer around Joda-Time. This adds some implicit conversions to make it easier to use, like the + and < operators.

import com.github.nscala_time.time.Imports._
DateTime.now + 2.months // returns org.joda.time.DateTime

Continue reading →

When we convert our Asciidoctor markup to HTML we automatically get a head and footer element. We can add custom content to the HTML head element and to the HTML div with id footer. We must set a document attribute and create the files that contain the HTML that needs to be added to the head or footer. We have three different document attributes we can set to include the custom content files:

• :docinfo: include document specific content. Files to be included must be named <docname>-docinfo.html for head element and <docname>-docinfo-footer.html for footer content.
• :docinfo1: include general custom content. Files to be included must be named docinfo.htmtl for head element and docinfo-footer.html for footer content.
• :docinfo2: include document specific and general custom content. Files to be included must be named <docname>-docinfo.html and docinfo.html for head element and <docname>-docinfo-footer.html and docinfo-footer.html for footer content.

Continue reading →

For Java or Groovy projects we can use the application plugin in Gradle to run and package our application. The plugin adds for example the startScripts task which creates OS specific scripts to run the project as a JVM application. This task is then used again by the installDist that installs the application, and distZip and distTar tasks that create a distributable archive of the application. The startScripts tasks has the properties unixScript and windowsScript that are the actual OS specific script files to run the application. We can use these properties to change the contents of the files.

In the following sample we add the directory configuration to the CLASSPATH definition:

Continue reading →

Grails 3 is based on Spring Boot. This means we can use a lot of the stuff that is available in Spring Boot now in our Grails application. If we look at the logging of a plain Spring Boot application we notice the logging has colors by default if our console supports ANSI. We can also configure our Grails logging so that we get colors.

First we need to change our logging configuration in the file grails-app/conf/logback.groovy:

Continue reading →

In Spring we can use the @Value annotation to set property or arguments values based on a SpEL expression. If we want to use the @Value annotation for a constructor argument we must not forget to add the @Autowired annotation on the constructor as well.

// File: sample/Message.groovy
package sample

import org.springframework.beans.factory.annotation.*
import org.springframework.stereotype.*

@Component
class Message {

    final String text

    // Use @Autowired to get @Value to work.
    @Autowired
    Message(
        // Refer to configuration property
        // app.message.text to set value for
        // constructor argument text.
        @Value('${app.message.text}') final String text) {
        this.text = text
    }

}

Continue reading →

One of the coolest things a standard Scala install will give you, is the Scala interpreter. Technically speaking, this is not an interpreter. In the background, each statement is quickly compiled into bytecode and executed on the jvm. Therefore, most people refer to it as the Scala REPL: Read-Evaluate-Print-Loop. You can access it by starting a command shell on your system and typing in 'scala'. Do make sure your either run it from the place where scala is installed or have scala on your environment PATH. By using the repl, you can quickly experiment and test out different statements. Once you press ENTER it will evaluate the statement and display the result. Frequently you want to execute multi-line statements and luckily the repl has a solution for that. Simply type in :paste and the repl will accept multiline statements. To exit this mode and evaluate your code, simply type CTRL+D. Example:

$ scala
Welcome to Scala version 2.11.4 (Java HotSpot(TM) Client VM, Java 1.7.0\_75).
Type in expressions to have them evaluated.
Type :help for more information.

scala> :paste
// Entering paste mode (ctrl-D to finish)

class Camera {

//this is a multiline example in the REPL

 val brand:String = "Canon"
 val model:String = "5D mark III"
}

// Exiting paste mode, now interpreting.

defined class Camera

scala> val cam = new Camera
cam: Camera = Camera@bfd117

scala> cam.brand
res0: String = Canon

Continue reading →

A good thing in Grails is that in Grails artifacts like controllers and services we have a log property to add log statements in our code. If we want to have the output of these log statements we must use a special naming convention for the log names. Each logger is prefixed with grails.app followed by the Grails artifact. Valid artifact values are controllers, services, domain, filters, conf and taglib. This is followed by the actual class name. So for example we have a controller SampleController in the package mrhaki.grails then the complete logger name is grails.app.controllers.mrhaki.grails.SampleContoller.

The following sample configuration is for pre-Grails 3:

Continue reading →

When I was a kid, I was a big Bruce Lee fan. I walked around the playground rubbing my nose with my thumb. When I had a piece of rope, I had to do my version of the nunchaku routine from Way of the Dragon and made cat-like noises. Looking back at Lee, I find it quite striking how many of the principles of his fighting style Jeet Kun Do apply to agile practices. Check out these descriptions of the fighting style:

• "Jeet Kune Do is not fixed or patterned, and is a philosophy with guiding thoughts."
• "Jeet Kune Do practitioners believe in minimal movements with maximum effects and extreme speed."
• "The system works by using different "tools" for different situations, where the situations are divided into ranges, which is kicking, punching, trapping, and grappling, where martial artists use techniques to flow smoothly between them. "
• "Through his studies Lee came to believe that styles had become too rigid and unrealistic. He called martial art competitions of the day "dry land swimming". He believed that combat was spontaneous, and that a martial artist cannot predict it, only react to it, and that a good martial artist should "be like water" and move fluidly without hesitation."

Continue reading →

When we a have Spring managed application, we want to let Spring manage all of our beans. Beside the regular way of creating beans with known solutions like Annotated beans, Java Configuration and XML Configuration, there is also a way in which we can create our own BeanDefinition. With a BeanDefinitionRegistryPostProcessor it is possible to create a specific post processor which can add BeanDefinitions to the BeanDefinitionRegistry. It differs from the BeanPostProcessor, which only has hooks for Bean Initialization (construction of your POJO), where the BeanDefinitionRegistryPostProcessor has a hook on the BeanDefinitionRegistry. This gives us the ability to define our own BeanDefinition. First we create a BeanDefinitionRegistryPostProcessor implementation as listed in the example. We implement the required method, and will be able to add our own bean definition to the registry. The defined BeanDefinition will be picked up by the ApplicationContext and the POJO will be constructed. Our result is A Spring managed bean

package com.jdriven;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.support.BeanDefinitionRegistry;
import org.springframework.beans.factory.support.BeanDefinitionRegistryPostProcessor;
import org.springframework.beans.factory.support.RootBeanDefinition;
import org.springframework.stereotype.Component;

@Component
public class LogicServiceRegistryPostProcessor
        implements BeanDefinitionRegistryPostProcessor {

    @Override
    public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry)
            throws BeansException {

        RootBeanDefinition beanDefinition =
                new RootBeanDefinition(MyServiceImpl.class); //The service implementation
        serviceDefinition.setTargetType(MyService.class); //The service interface
        serviceDefinition.setRole(BeanDefinition.ROLE_APPLICATION);
        registry.registerBeanDefinition("myBeanName", beanDefinition );
    }
}

Continue reading →

Grails 3 is based on Spring Boot. This means we get a lot of the functionality of Spring Boot into our Grails applications. A Spring Boot application has by default a banner that is shown when the application starts. The default Grails application overrides Spring Boot's behavior and disables the display of a banner. To add a banner again to our Grails application we have different options.

First we can add a file banner.txt to our classpath. If Grails finds the file it will display the contents when we start the application. Let's add a simple banner with Grails3 in Ascii art in the file src/main/resources/banner.txt. By placing the file in src/main/resources we can assure it is in the classpath as classpath:/banner.txt:

Continue reading →