I recent ran into a interesting situation, for which I thought it would be worth sharing. I have a new project with the following build needs: Java, Spring MVC and
Spock Testing. The problem is simple... The WAR build in gradle was building a WAR file that included the Groovy libraries. This project has no need for groovy at runtime.
Groovy is needed because I'm using Spock for my testing.
Gradle and providedCompile
In older versions of Gradle it was commonly necessary to manage the jars in the lib directory. In the maven world, there is a dependency scope of "provided". This scope basically means that the dependency will be provided on the server classpath, however for the purposes of compiling the code in the project it is necessary. From a WAR perspective it means use this dependency for compile, but do not include it in the lib directory of the WAR. Gradle within the last year has added the same feature as providedCompile or providedRuntime. In my project I have this very need with the servlet-api, shown below.
dependencies {
compile "org.springframework:spring-webmvc:$springVersion"
compile 'javax.servlet:jstl:1.2'
providedCompile 'javax.servlet:servlet-api:2.5'
}
Spock dependencies and Gradle
As Spock is a groovy testing tool, it is no surprise that Spock requires groovy. This requires a couple of well documented configurations in your gradle file. First, you'll have to add the groovy plugin. Second you have to set as a dependency the groovy version. But wait!!! The dependency for groovy doesn't have a scoping ability. This is area where the "model" of gradle breaks down a little bit IMO. Ideally you would be interested in expressing in the model that there are "testing" needs... and those testing needs require groovy and spock dependencies.
apply plugin: 'groovy'
def spockVersion = '0.5-groovy-1.8'
def springVersion = '3.1.0.RELEASE'
dependencies {
groovy 'org.codehaus.groovy:groovy-all:1.8.3'
testCompile 'junit:junit:4.8.1'
testCompile "org.spockframework:spock-core:$spockVersion"
testCompile "org.spockframework:spock-spring:$spockVersion"
}
With this groovy dependency any build of WAR will result in a the groovy-all-?.?.?.jar file being added to the the WEB-INF/lib directory. The problem is I have no current interest in having groovy in production for this project. What to do? What to do?
Gradle Doc to the Rescue
I find that a large number of people (usually new to gradle) struggle with discovering how to resolve such a problem. The best starting point for getting to know gradle is the gradle
user guide documentation, but the best starting point to use as a reference is the gradle
dsl documentation (
http://gradle.org/docs/current/dsl). Hopefully it is obvious that what we want to change is the build of the WAR. So lets look at the War task. Here we see all of it's properties... which includes the classpath property. The documentation for this property clearly states that this property affects the WEB-INF/classes and the WEB-INF/lib. Diving deeper into that property we see the default behavior which is:
project.configurations.runtime - project.configurations.providedRuntime
So our logical solution would be to include a war task configuration for the building of the classpath like this:
war {
classpath = classpath - project.configurations.groovy
}
Happy Coding! and may your builds never fail!
