Archive: September 2012

Groovy Goodness: Using Implicit call() Method

Posted on by  
Hubert Klein Ikkink

In Groovy we can invoke an implicit call() method on a Groovy object. We can leave out the call method name and just use (). We can use meta programming to add an implementation for the call() method to a class. In the following example script we add an implementation for the call() method with a single parameter to the String class. The implementation returns the element found at the range specified by the argument when we invoke the method:

String.metaClass.call = { range ->
    delegate[range]
}

def value = 'Groovy is Gr8'
assert value(0) == 'G'
assert value(10) == 'G'
assert value(4) == value[4]
assert value.call(1) == value(1)
assert value(0..5) == 'Groovy'

Continue reading →

Groovy Goodness: Boolean Implications

Posted on by  
Hubert Klein Ikkink

Since Groovy 1.8.3 we can use the implies() method on Boolean types. The implies() method implements a logical implication. This means that if we have two Boolean variables A and B, that if A is true, than B is true. So if A is true than it is implied B is true as well. If A is false than B can be either true or false. We could rewrite the implication as !A or B.

def a = true
def b = true

assert a.implies(b)
assert !(a.implies(false))

assert a.implies(b) == ((!a).or(b))

assert true.implies(true)
assert false.implies(true)
assert false.implies(false)
assert !true.implies(false)

Continue reading →

Why Time Is No Measure For Progress

Posted on by  
Arthur Arts

One of the questions that Project Managers always pop up during projects is: "how many days will it take to finish this work?". This is a very natural and sensible question. You want to know when a project will be finished, so people can have an expectancy of the needed budget, what functionality is in it and when it will be finished. However, answering the question is more difficult than traditionally is assumed.

Imagine you're expecting a friend from a distant city, to come over to your house for a visit. The city is 150 miles away. He's been traveling for a while and you want to know how long it will take to arrive to your house. You expected him to make the trip in three hours. You give him a call and pop him the question. "How long will it take for you to get here?". Imagine him answering "I've been traveling for two hours" What kind of conclusion can you get from this?

Continue reading →

Gradle Goodness: Customize IDEA Project File Generation

Posted on by  
Hubert Klein Ikkink

With the Gradle IDEA plugin we can generate JetBrains IntelliJ IDEA project files. The plugin uses defaults from our project to generate the files. If we also apply the Java plugin to our project then the Java settings for the project files are generated. We can customize the file generation in several ways. The most low level method is using the withXml hook. With this hook we have access to the XML before the file is written to disk. Here we can add or change XML elements and attribute values. We use a closure as argument for the withXml hook and Gradle adds a XmlProvider object as argument. The easiest way to manipulate the XML is getting a groovy.util.Node from the XmlProvider. We also can get a DOM Element or StringBuilder to work with. In the following example build file we change the contents of the IDEA project file (with extension .ipr). We change the output directory of the JavaDoc tool. We use Groovy syntax to find the JavadocGenerationManager which is automatically added, because we have the Java plugin in our build file. We also change the Encoding component or create it when it doesn't exist:

apply plugin: 'java'
apply plugin: 'idea'

idea {
    project {
        // Here we customize the .ipr file generation.
        ipr {
            // XML hook to customize the XML before
            // it is written to disk
            withXml { xmlProvider ->
                // Get root node.
                def project = xmlProvider.asNode()

                customizeJavaDoc project
                customizeEncoding project
            }
        }
    }
}

/* Customize JavadocGenerationManger component */
def customizeJavaDoc(project) {
    def javaDocGenerationManager = findComponent(project, 'JavadocGenerationManager')
    changeOption javaDocGenerationManager, 'OUTPUT_DIRECTORY', '$PROJECT_DIR$/out/javadoc'
}

/* Search component with given name */
def findComponent(project, name) {
    project.component.find { it.@name == name }
}

/* Set value for option node with given name */
def changeOption(node, name, value) {
    node.option.find { it.@name == name }.@value = value
}

/* Customize Encoding component */
def customizeEncoding(project) {
    def encoding = findComponent(project, 'Encoding')

    if (encoding) {
        // Change existing node.
        encoding.@useUTFGuessing = true
        encoding.@native2AsciiForPropertiesFiles = true
        encoding.@defaultCharsetForPropertiesFiles = 'UTF-8'
    } else {
        // Create new node with default values.
        project.appendNode 'Encoding', [useUTFGuessing: true, native2AsciiForPropertiesFiles: true, defaultCharsetForPropertiesFiles: 'UTF-8']
    }
}

Continue reading →

To Roo or not to Roo...

Posted on by  
Emil van Galen

Recently I've been looking into Spring Roo to find ways to speed-up software development as well as reducing plumbing code. In this blog post I will highlight some of the advantages and disadvantages of Spring Roo which I stumbled upon. So don't expect a full featured introduction or tutorial; plenty of those already exist on the internet ;-)

Spring Roo takes on a different approach to code generation compared to other solutions. Instead of generating additional .java files (through the "Generation Gap Pattern") it generates so-called AspectJ inter-type declaration (ITD) .aj source files. Each generated inter-type declaration (ITD) type will "weave in" structural changes to its target .java file; for example to add new methods (i.e. getter/setter methods) or an "implements ..." clause. The big advantages of such inter-type declaration (ITD) are:

Continue reading →

Google Guava Goodness: Converting Between ASCII Case Conventions

Posted on by  
Hubert Klein Ikkink

The Google Guava libraries contains useful utility classes and methods. If we want to convert between ASCII case conventions we can use the CaseFormat class. The class defines constants for upper and lower case CamelCase, upper and lower case hyphenated and upper case underscore. This means we can convert UPPER_VALUE to upper-value with a simple line of code.

import static com.google.common.base.CaseFormat.*;

assert LOWER_CAMEL.to(UPPER_UNDERSCORE, "lowerCase").equals("LOWER_CASE");
assert LOWER_HYPHEN.to(LOWER_UNDERSCORE, "manual-index").equals("manual_index");
assert UPPER_CAMEL.to(LOWER_UNDERSCORE, "UpperCase").equals("upper_case")

Continue reading →

Google Guava Goodness: Joining Collection Elements

Posted on by  
Hubert Klein Ikkink

Sometimes I work on Java projects and then I miss the expressiveness of the Groovy language. For example to join elements in a list with a given separator to get a String value we only have to use the following code:

final List names = ['mrhaki', 'JDriven', 'Groovy Rocks!']

assert names.join(',') == 'mrhaki,JDriven,Groovy Rocks!'

Continue reading →

Gradle Goodness: Using Objects for Version

Posted on by  
Hubert Klein Ikkink

One of the great things of Gradle is that the build scripts are code. We can use all the features of the Groovy language, we can refactor our build scripts to make them more maintainable, we can use variables and properties to define values and much more, just like our application code. In this post we see how we can create a class to define a version in our build script. To set the version of a Gradle project we only have to assign a value to the version property. Normally we use a String value, but we can also assign an object. Gradle will use the toString() method of the object to get the String value for a version. In the following build script we define a new class Version in our build script. We create an instance of the class and assign it to the version property. With the task printVersion we can see the value of the version property:

version = new Version(major: 2, minor: 1, revision: 14)

task printVersion {
    doFirst {
        println "Project version is $version"
    }
}

defaultTasks 'printVersion'

class Version {
    int major, minor, revision

    String toString() {
        "$major.$minor.$revision"
    }
}

Continue reading →

Google Guava Goodness: Matching All Elements in a Collection

Posted on by  
Hubert Klein Ikkink

The Google Guava libraries has many useful classes and methods. Normally I write code in Groovy and I am used to working with collections in an intuitive way. But sometimes I need to work with Java on my project and then the Google Guava libraries are a great alternative. Suppose I want to check if all elements in a collection apply to a certain condition. In Groovy I would write this:

final List list = ['Groovy', 'Rocks']

assert list.every { it.contains('o') }

Continue reading →

shadow-left