Gradle and providedCompileIn 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.
Spock dependencies and GradleAs 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'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?
def spockVersion = '0.5-groovy-1.8'
def springVersion = '3.1.0.RELEASE'
Gradle Doc to the RescueI 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.providedRuntimeSo our logical solution would be to include a war task configuration for the building of the classpath like this:
classpath = classpath - project.configurations.groovy
Happy Coding! and may your builds never fail!