Since a few versions ago, grails includes the possibility of packaging your plugin as an old good JAR file. This can be done by using the –binary option:

grails-timestamped $ grails package-plugin --binary
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 -Xmx2048m -Xms256m -XX:PermSize=512M -XX:MaxPermSize=2048M
| Packaging Grails application.....
| Plugin packaged grails-plugin-timestamped-0.3.jar
grails-timestamped $ ls target/*.jar
target/grails-plugin-timestamped-0.3.jar

This allows a developer to publish closed plugins (as with the traditional packaging, installing a plugin means that you’ll get the source code in your $HOME/.grails) and to gain some speed in compiling / deployment operations, since the plugin doesn’t need to be compiled. Another benefit that I’ve not seen mentioned anywhere is that this allows a plugin to provide AST transforms that can be used by other plugins (as, for example, the timestamped plugin does). The reason is that an AST transform needs to be available at compile time, so if you compile it in the same “compilation execution” as the classes where it’s been applied, it won’t be able to do its work, and all plugins are compiled in the same “compilation execution” (but not in the same “compilation execution” as the main project, being that the reason why the AST transform will work in the project).

There is a problem with the binary packaging though, and is that right now the grails plugins official portal doesn’t support it. You have then to publish it to a maven repo and add it as a maven dependency. Too much work? Not really!

Grails Plugin Maven Deployer

I created a small scripting tool that can create a maven repo structure from a grails plugin. You can just put that structure in any webserver (or even Github or Github pages), and you are ready to go. The Grails Plugin Maven Deployer can be found in Github, and this is an example of using it to publish the timestamped grails plugin:

Prepare a temp directory with the plugin and the deployer for a demo:

$ mkdir grails-plugin-maven-deployer-demo && cd grails-plugin-maven-deployer-demo
$ mkdir -p  maven/releases/
$ git clone https://github.com/deigote/grails-timestamped
$ git clone https://github.com/deigote/grails-plugin-maven-deployer

Using the deployer:

$ grails-plugin-maven-deployer/deploy.sh grails-timestamped/ com.deigote.grails-plugins timestamped maven/releases/
$ ls -R maven/releases/

If everything goes well (if not, open an issue and I’ll try to help :-D), you’ll see a maven repo in the maven/releases (the destination directory passed as the fourth) for the artifact timestamped (the plugin name, passed as third argument to the script) and the group id com.deigote.grails-plugins (passed as second argument to the script). The first argument is, of course, the path to the plugin to publish .

Then you just can publish the destination directory in any webserver and include it as a dependency. For example, I published the maven/releases/ in Github Pages, which allows me to reach it by including the following in the project’s BuildConfig.groovy:

dependencies {
   ...
   compile 'com.deigote.grails-plugins:timestamped:0.3'
}

repositories {
   inherits true
   mavenRepo 'http://deigote.github.io/grails-timestamped/maven/releases/'
   ...
}

I recently created a small Grails plugin to use it as part of my work at tadoº, the awesome company I’m currently working for .

The plugin aims to provide a more declarative way of making a domain class auto timestamped. Right now, for making a domain class auto timestamped, you need to declare two properties with the proper type, which is a bit of a DRY violation. Also, these properties aren’t part of the domain class logic, so I prefer them to be declared elsewhere.

With these things in mind, the plugin provides an annotation which, when used in a domain class, triggers an AST transform that inject the auto timestamping properties in that domain class. The most simple example would be as following:

package timestampeddemo
import com.tado.timestamped.transform.Timestamped
@Timestamped
class FullTimestamped {
}

Since the most common option is to inject both properties, the default is to do so, but you can configure which events you want to consider:

package timestampeddemo
import com.tado.timestamped.transform.Timestamped
@Timestamped(create=false)
class UpdateTimestamped {
}

package timestampeddemo
import com.tado.timestamped.transform.Timestamped
@Timestamped(update=false)
class CreationTimestamped { }

The plugin is prepared to work with the joda-time plugin, so if present, the generated timestamping properties will be typed as org.joda.time.Instant instead of the old, not-so-good java.util.Date. But if you happen to prefer any other class, you can specify it as a part of the Timestamped annotation:

package timestampeddemo
import com.tado.timestamped.transform.Timestamped
@Timestamped(clazz='java.lang.Long')
class CustomClassTimestamped {}

This, of course, only make sense if you provide the proper persistence auto timestamping support for the specified class, as happens for example with the joda-time plugin.

Last, but not least, the plugin can be included as a tradicional plugin or as a maven dependency. The later allows the plugin to be used by other plugins, as it will be precompiled and the AST transform will be then available in plugin compile time as well. More info on this subject can be found in the installation chapter of the guide.

import grails.converters.JSON
class JSONUtils {
	protected static buildJSON(objectsToBuild, properties) {
		objectsToBuild.inject([], {
			objects, object -> objects << (properties.inject([:], {
				objectMap, property -> objectMap << [(property): object[property]]
			}))
		}) as JSON
	}
}

You could use it in a controller as following:

import static JSONUtils.buildJSON
class PersonController {
	def personService	
	static personJSONProperties = [ 'name', 'gender', 'age']

	def peopleByAge(Integer age) {
		buildJSON(personService.findByAge(age), personJSONProperties)
	}
}

I'm thinking that this could be a small but usefull AST transformation...

find . -type f -size +100M

But that won’t work with directories. After all, I guess they don’t take much spaces themselves – the files contained by them are the ones that does . So what I usually end up doing is finding directories with a certain depth, and then calculate their sizes and filter with grep. This would be an example:

find $HOME -type d -mindepth 1 -maxdepth 3 -exec du -hs {} \; | grep -E "[0-9]{1}(\.[0-9]{1,2})?G" | sort -n

This would list the directories contained in the user’s home, recursing til a max depth of 3 levels, and them calculate all their sizes. After that, it would filter by the sizes whose size is 1 gigabyte or more. Last, the sizes are sorted with a numeric criteria. You can change the last letter to filter by megabytes (M), and the count of the first regular expression so it takes only numbers of a given lenght. For example, to get sizes in the range [100M-1G), you would use the following regular expression: "[0-9]{3}(\.[0-9]{1,2})?M”. And to find directories with a size of at least 10 gigabytes, you would use: “[0-9]{2}(\.[0-9]{1,2})?G”. You can also change the mindepth and maxdepth params in order to filter how deep you want the recursion. And if you don’t provide a maxdepth param and set the base directory as /, the whole filesystem will be analized :).

I’ve seen tons of duplicated code (Tolkien fans would refer to it as “The Programmers Bane”) in the projects I’ve worked for hashCode and equals methods, even in the ones that use the Apache Commons helpers (EqualsBuilder and HashCodeBuilder), so I decided to post a pair of methods that I usually use to work out this problem:

import org.apache.commons.lang.builder.EqualsBuilder
import org.apache.commons.lang.builder.HashCodeBuilder
class DomainClassUtils {
	...
	static boolean equals(Object one, Object another) {
		one != null && another != null && 
		((obj.respondsTo('instanceOf') && obj.instanceOf(this.getClass())) || 
		 this.getClass().isInstance(obj)) && 
		(one.is(another) || 
		 one.getClass().equalsProperties.inject(new EqualsBuilder()) {
			builder, property ->
			builder.append(one[property], another[property])
		}.isEquals())
	}
	
	static int hashCode(Object one) {
		one.getClass().equalsProperties.inject(new HashCodeBuilder()) {
			builder, property ->
			builder.append(this[property])
		}.toHashCode()
	}
}

This methods will calculate equals and hashcode for domain class objects (note the use of the instanceOf method if available) that declares a static property named equalsProperties. For example:

import DomainClassUtils

class SomeDomainClass {
	Integer someProperty
	String anotherProperty
	AnotherDomainClass andAnotherProperty

	static equalsProperties = ['someProperty', 'andAnotherProperty']

	boolean equals(Object obj) {
		DomainClassUtils.equals(this, obj)
	}

	int hashCode() {
		DomainClassUtils.hashCode(this)
	}
}

This still involves duplicating the DomainClassUtils method invokations code, but this can be easily avoided injecting the methods using your prefered mechanism (in increasing order of preference, I could list the following ones: inheritance, composition, metaprogramming, category/mixin transformation, your custom AST transformation).

Assigning a variable value

I usually have in my functions.sh file something like the following:

[22:57] $ cat functions.sh 
function execute_and_log {
	echo "Executing '$1' ..."
	export ${2}="$(eval $1)"
}
[22:57] ~ $ source functions.sh 
[22:57] ~ $ execute_and_log "ls /usr" LS_RESULT 
[22:57] ~ $ echo $LS_RESULT
Executing 'ls /usr' ...
X11/ X11R6@ bin/ include/ lib/ libexec/ llvm-gcc-4.2/ local/ sbin/ share/ standalone/ texbin@

As you can see, I pass the variable name where I want to store my result as a parameter to the function. The trick is to wrap the variable that contains the variable name with braces. Note that if you don’t use export (that in most cases is not needed), it won’t work, I’m not sure why. Another possibility is to use the allmighty eval, which gives you an unglier sintax, but allows you to avoid the export:

[22:59] $ cat functions.sh 
function execute_and_log {
	echo "Executing '$1' ..."
	eval "$2=\"$(eval $1)\""
}
[22:59] ~ $ source functions.sh 
[22:59] ~ $ execute_and_log "ls /usr" LS_RESULT 
[22:57] ~ $ echo $LS_RESULT
Executing 'ls /usr' ...
X11/ X11R6@ bin/ include/ lib/ libexec/ llvm-gcc-4.2/ local/ sbin/ share/ standalone/ texbin@

Evaluating a variable value

Imagine that in the previous example you don’t want to log only the command to execute, but also the result. You then need to evaluate the value of a variable whose name is contained in another variable (the function second param in this case). In this case, I only know how to do it using eval, which would give you the following:

[11:11] ~ $ cat functions.sh 
function execute_and_log {
	echo "Executing '$1' ..."
	eval "$2=\"$(eval $1)\""
	eval echo "Result is \$$2"
}
[11:11] ~ $ source functions.sh ; execute_and_log "ls /usr" LS_RESULT 
Executing 'ls /usr' ...
Result is X11/ X11R6@ bin/ include/ lib/ libexec/ llvm-gcc-4.2/ local/ sbin/ share/ standalone/ texbin@

As you can see, we can use eval both to assign and evaluate, in this second case just by escaping the dollar sign. Really powerful .

Todo el album me parece buenísimo, pero la canción que consiguió que me enganchase a él de primeras fue Gone, un pedazo de tema que me tuvo obsesionado unos días, como siempre me pasa, y cuya letra me parece espectacular. Aquí os dejo la versión de estudio del mismo, aunque una vez que la tengáis escuchada, merece la pena darle una orejada a la fantástica versión que hicieron para AOL con Eddie Vedder a guitarra y voz.

A continuación la letra original y mi traducción, que como siempre tendrá errores varios cuyas correcciones serán más que bienvenidas :

Me quedo con los últimos versos. Si nada lo es todo, siempre se puede volver a empezar .

def updateContractAddress(contract, newAddress) 
{
   // Method configuration
   def client = contract.client
   def country =  CountryService.findByPostalCode(newAddress.postalCode)
   def currentAddress = client.address

   // Method body
   client.previousAddresses << currentAddress
   client.address = new Address
   client.save()
}

As you can see, the method has two different parts:

• In the first one, we just configure some variables that we will use in order to clean up our code, or may to not calling the same method twice (as would happen, for example, with the implicit method Contract.getClient(), that would be called three times in the variable client was inlined).
• In the second one, the actual method business logic is performed.

This is actually the method implementation, the previous stuff is just boiler plate code. In fact, in Java I have seen a lot the pattern of separating the previous code in multiple methods, in order to separate this two parts:

def updateContractAddress(contract, newAddress) 
{
   def client = contract.client
   def country =  CountryService.findByPostalCode(newAddress.postalCode)
   def currentAddress = client.address
   updateContractAddress(contract, newAddress, client, country, currentAddress)
}

private updateContractAddress(contract, newAddress, client, country, currentAddress) 
{
   client.previousAddresses << currentAddress
   client.address = new Address
   client.save()
}

Not bad. As I always say when joking, almost every life problem can be solved by applying an extract to method refactoring (yes, I am a funny guy ). But in Groovy we have another alternative that I find to be more elegant and easy to read.

As you know (and if don't, you should read this ), Groovy supports default values for a method arguments. So, you can do the following:

def method(a, b = 3, c = []) { ... } 

That is the same as doing:

def method(a) { method(a, 3, [] }
def method(a,b) { method(a, b, [] }
def method(a,b,c) { ... }

In fact, I think this is what the compiler actually do, making the feature a simple code generator that takes place in preprocessing time (but that is just me guessing ). Anyway, what you may not know is that the optional parameters can be assigned with method calls, and that this method calls can use the rest of the parameteres. So, the original code can be as following:

def updateContractAddress(contract, newAddress, client = contract.client, 
      currentAddress = client.address, country =  CountryService.findByPostalCode(newAddress.postalCode))
{
   client.previousAddresses << currentAddress
   client.address = new Address
   client.save()
}

Now we can focus on the method body without being distracted by all this boilerplate code, but if we want to take a look at it, is just a few lines above, and we don't need to navigate the class as the previous solution. And for free, we obtain a parametrized method: in we need to pass the client as a parameter in the future, we can do it without modifying a single line .

What I love about this trick is that it can aslo be used with Closures, so you can do stuff like the following:

[ name: 'diego', lastName: 'toharia', country: 'spain' ].each { 
   factName, factValue, capitalizedFactValue = factValue.capitalize() ->
   person[factName] = capitalizedFactValue
}

Ha . Love it.

Bonus track

When using this last trick, be careful: if the method that receives your closure checks the number of arguments it receives in order to invoke it with the proper number of arguments, you can see how your method initialization is replaced by an unexpected value! An example of this would be the closure passed to a Grails validator:

class SomeDomainClass {
   String prop
   static constraints = {
      prop(nullable: true, validator: { prop, domainClass, propIsEmpty = prop.trim() != "" -> 
         propIsEmpty || validateProp(prop)
      }
   }
}

In this example, the custom validator for the property prop init the propIsEmpty parameter in the closure signature, but Grails is smarter: if you pass a closure with one argument, it invokes it with the property. If it can receives two arguments, it passes the property and the object. But if the closure declare three arguments, it passes the current validation errors as well, so you will find that propIsEmpty won't have what you expected . So use it carefully .

• Me obsesione con esa canción, escuchándola muchas veces, berreándola en el coche, intentando tocarla con la acústica, y a veces, Dios no lo quiera, grabándola con el Garage Band a ver qué suena.
• Me dedique a ponérsela a mis allegados, o a compartirla compulsivamente en las distintas redes sociales de las que hago uso.

Normalmente, el segundo fenómeno implica enviarle una traducción de la letra a mi mujer, de esa manera sé que las posibilidades de que ella también se enganche crecen exponencialmente . Así que a partir de ahora, cuando eso ocurra, intentaré aprovechar para compartir el tema y la traducción con España y el mundo (apagar modo reality :lol ).

La canción que hoy traigo es de un grupo llamado Middle Brother (Hermano del medio, vaya, como yo ), una banda de folk rock estadounidense que representa la palabra americanada, pero en el buen sentido . El tema en cuestión es el que cierra su único álbum a día de hoy, de mismo nombre, y se llama Million Dollar Bill. La escuché gracias a mi dealer musical habitual, mi hermano (bajista de los archifantásticos Les Vivo), y me tiene absolutamente enganchado. Aquí os dejo una versión hecha en la calle tras conducir por la noche después de un concierto (o eso dicen, por sus pintas me lo creo):

Aunque también podéis escuchar la preciosa versión de estudio, que aunque suena mucho mejor, es menos divertida de ver . Y a continuación, mi traducción, que seguramente tenga fallos (y por supuesto, agradeceré correcciones ).

About the module

The next Puppet module I wanted to talk about is the Grails puppet module. Same as the other modules for Puppet, is published on OSOCO’s Github account, and is one of the most simple, but one of the most used in our infrastructures, for obvious reasons .

This module allows you to install multiple versions of Grails in a puppet node. The usage couldn’t be simpler, as you can see in the following code:

class jenkins {
    ...
    grails { "grails-1.3.5":
        version => '1.3.5',
        destination => '/opt'
    }

    grails { "grails-1.3.9":
        version => '1.3.9',
        destination => '/opt'
    }

    grails { "grails-2.0.0":
        version => '2.0.0',
        destination => '/opt'
    }

    grails { "grails-2.0.1":
        version => '2.0.1',
        destination => '/opt'
    }
    ...
}

In this example, a class jenkins declare multiple Grails installations (in order to launch the tests battery for each project with the proper Grails version) by adding various grails resources that is parametriced by the Grails version and the destination directory. The Grails module will resolve the download URL (that since 1.3.6 version must point to Amazon S3 instead of being self-hosted as in previous versions), and retrieve and unpack the ZIP only if necessary (i.e if the given Grails version is not already installed in the specified destination directory).

Dependencies

The module depends on OSOCO’s Puppet Wget module, so you should checkout both modules into your modules directory. Or, if you are using puppet-librarian, you can add the following to your Puppetfile file:

mod "wget",
   :git => "git://github.com/osoco/puppet-wget.git"
mod "grails",
   :git => "git://github.com/osoco/puppet-grails.git"