As of Maven 2.0.9 a new feature was added to Maven called dependency mediation. Dependency mediation is the technique used by Maven to resolve your project dependencies in the specific case when a dependency occurs multiple times in your dependency tree. Usually this occurs on transitive dependencies linked through the dependencies of your project. In these cases mediation will be performed using the nearest win-strategy. In short this strategy means that Maven will use the version declared in the pom.xml that is closest to your project pom.xml. Hence, no in-depth intelligence is used to resolve the dependency conflict. Actually, I can't really think of a conflict resolve strategy that would really solve this problem. Any strategy I can think of has the hazard of linking incompatible dependencies in to your project. Using Maven version ranges can ofcourse resolve compatibility between artifacts, but this also requires you to establish a compatibility matrix of your dependencies. A pretty tedious task if you ask me. Now this whole mediation feature might sound like a very undesirable feature, but it's not! With this feature you can now at least be made aware of any dependency conflicts in your project dependencies. When you build your project using the -X switch, Maven will output all mediations (and a lot more) that have been performed. Now, wouldn't it be cool if there was a maven-plugin to detect mediation? JDriven took the liberty of extending Apache's dependency plugin with such a feature and share it with you. The goal used to detect mediation is mvn dependency:mediation. Additionally two interesting parameters can be added: 1) -DdisallowMediation=false 2) -DinspectArtifactId={some artifactId} As the name already implies, disallowMediation determines whether or not mediation is allowed. When allowed, the plugin will only warn about mediation being performed on dependencies. Very usefull when combined with for instance Jenkins' ${IS_M2RELEASEBUILD} variable to disallow mediation for release builds, yet allowing it for snapshot builds. The inspectArtifactId parameter is much like goal dependency:tree -Dverbose=true, it will check mediation and print dependency information regarding the artifact having id {some artifactId}. In your pom.xml your can add additional configuration to filter which dependencies must be checked on mediation:

com.jdriven.maven.plugins
maven-dependency-plugin
2.8.1
 com.jdriven:\* 

Continue reading →

When we mock or stub methods we can use the method arguments passed to the method in the response for the mocked or stubbed method. We must write a closure after the rightShift operator (>>) and the closure arguments will resemble the arguments of the mocked or stubbed method. Alternatively we can use a single non-typed argument in the closure and this will contains the method argument list.

Let's create a specification where we use this feature. In the following sample we use a mock for the AgeService used in the class under test. The method allowedMaxTime() is invoked by the class under test and basically should return the maximum hour of the day a show can be broadcasted. In our specification we use the name of the show to return different values during the test.

Continue reading →

NOTE: This blog post is originally written for AngularJS 1.2.x; in 1.3.x the "input not showing invalid model values" has been fixed.
Although 1.3.x still has the "inconsistencies in how AngularJS parses data entry" the solution from this blog post isn't working for 1.3.x but I will try to find a fix for this within the next few weeks.

A while ago I noticed that AngularJS doesn't show invalid model values bound to an <input/> There is also an open bug report about this: issue #1412 - input not showing invalid model values The bug can be easily illustrated through the following example:

Continue reading →

In a previous blog post we learned how we can unit test a template or view independently. But what if we want to unit test a controller that uses the render() method and a template with the template key instead of a view? Normally the view and model are stored in the modelAndView property of the response. We can even use shortcuts in our test code like view and model to check the result. But a render() method invocation with a template key will simply execute the template (also in test code) and the result is put in the response. With the text property of the response we can check the result.

In the following sample controller we use the header template and pass a username model property to render output.

Continue reading →

Since Grails 2 we can render binary output with the render() method and the file attribute. The file attribute can be assigned a byte[], File, InputStream or String value. Grails will try to determine the content type for files, but we can also use the contentType attribute to set the content type.

In the following controller we find an image in our application using grailsResourceLocator. Then we use the render() method and the file and contenType attributes to render the image in a browser:

Continue reading →

Grails uses Spring and we can piggyback on the Spring support for resource loading to find for examples files in the classpath of our application. We can use the Spring org.springframework.core.io.Resource or org.springframework.core.io.ResourceLoader interface to find resources in our application.

And since Grails 2.0 we can also use the org.codehaus.groovy.grails.core.io.ResourceLocator interface. In our code we can use the grailsResourceLocator service which implements the ResourceLocator interface. We must inject the grailsResourceLocator service into our code and we use the method findResourceForURI(String) to find a resource. The advantage of the grailsResourceLocator service is that it knows about a Grails application. For example resources in plugins can also be accessed.

Continue reading →

Spock has some great features to write specifications or tests that are short and compact. One of them is the old() method. The old() method can only be used in a then: block. With this method we get the value a statement had before the when: block is executed.

Let's see this with a simple example. In the following specification we create a StringBuilder with an initial value. In the then: block we use the same initial value for the assertion:

Continue reading →

There is really no excuse to not write unit tests in Grails. The support for writing tests is excellent, also for testing code that has to deal with the locale set in a user's request. For example we could have a controller or taglib that needs to access the locale. In a unit test we can invoke the addPreferredLocale() method on the mocked request object and assign a locale. The code under test uses the custom locale we set via this method.

In the following controller we create a NumberFormat object based on the locale in the request.

Continue reading →

Grails adds a couple of methods and properties to our controller classes automatically. One of the methods is the header() method. With this method we can set a response header with a name and value. The methods accepts two arguments: the first argument is the header name and the second argument is the header value.

In the following controller we invoke the header() method to set the header X-Powered-By with the Grails and Groovy version.

Continue reading →

NOTE: this blog post was written for version 0.8 of the Karma test runner. An updated blog post for the new Karma 0.10 can be found here.

For my current project we are using Maven to build our AngularJS application. Furthermore we use Sonar (recently renamed to SonarCube) to monitor our code standards / best practices and unit test coverage. In this blog post we describe how to integrate the Karma (Testacular) test runner with Maven and how to add your AngularJS (or any JavaScript) application to SonarQube.

Continue reading →