7

I have your basic run of the mill Gradle web application project and it works ok but I noticed that Gradle's runtime classpath is being included in the jetty one which has the potential to conflict with the web applications.

Notice below that gradle is using a slightly older version of logback and that SL4J is warning that it found multiple bindings in the classpath. 

:jettyRun
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/dev/java/tools/gradle-1.0-milestone-5/lib/logback-classic-0.9.29.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/Users/kirk.rasmussen/.gradle/caches/artifacts-3/ch.qos.logback/logback-classic/fd9fe39e28f1bd54eee47f04ca040f2b/jars/logback-classic-0.9.30.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

Is there a way to exclude the gradle runtime classpath from being included when running jettyRun task? I'm using the latest 1.0 milestone 5 version of Gradle.

I'm looking for something along the lines of 'includeAntRuntime' in the javac task in Ant.

http://ant.apache.org/manual/Tasks/javac.html

includeAntRuntime Whether to include the Ant run-time libraries in the classpath; defaults to yes, unless build.sysclasspath is set. It is usually best to set this to false so the script's behavior is not sensitive to the environment in which it is run.

Stripped down build.gradle:

apply plugin: 'groovy'
apply plugin: 'war'
apply plugin: 'jetty'

jettyRun {
    contextPath = ''
}
David Pärsson
  • 6,038
  • 2
  • 37
  • 52
Kirk Rasmussen
  • 231
  • 4
  • 9

2 Answers2

2

As described in the manual for jettyRun task, it has a classpath property which is by default set to project.sourceSets.main.runtimeClasspath. You can just set this property to the classpath of your choice:

configurations{
  myJettyRuntime
}

dependencies{
  myJettyRuntime "group:name:version"
  ...
}

jettyRun{
  classpath = configurations.myJettyRuntime
}

alternatively you can add or subtract unneeded or conflicting dependencies from this classpath, using -= and += operators respectively.

jettyRun{
  classpath -= configurations.myExcludedConf
}
rodion
  • 14,729
  • 3
  • 53
  • 55
  • Thanks that's a good idea but it would be even better if this was built in functionality so I don't have to determine which things need to be excluded. I'm not convinced what you suggest would work because the documentation implies that it is additive. The Gradle classpath looks like it might come along for the ride. Is there a good reason why the Gradle classpath is needed by the jetty plugin to launch the container? – Kirk Rasmussen Mar 15 '12 at 18:29
  • I have successfully used `-=` on `sourceSet.main.compileClasspath` so it should work in the same way for jetty classpath. I don't know why and for what reason gradle is including its own classpath. The manual suggests that by default the classpath is set to `project.sourceSets.main.runtimeClasspath`, which should be the classpath of your application and not of gradle. If problem persists with the latest gradle version then I can only suggest your filing a bug report. – rodion Mar 17 '12 at 13:31
0

If you are just worried about the two SLF4j bindings, it would seem you can ignore the warning in this case. That is exactly what I'm doing.

James A Wilson
  • 14,611
  • 5
  • 29
  • 31