Gradle pollutes jettyRun / jettyRunWar tasks' classpath with its own jars

(This is a copy of the task that I created directly in jira and which landed in a wrong subproject. Sorry for that! Link:

I can attach a sample project or you can download it from the issue linked above. It uses gradle 1.6 with wrapper (but not using the wrapper makes no difference), slf4j and logback, and during startup I can see this:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/wujek/.gradle/wrapper/dists/gradle-1.6-bin/72srdo3a5eb3bic159kar72vok/gradle-1.6/lib/logback-classic-1.0.9.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/wujek/.gradle/caches/artifacts-24/filestore/ch.qos.logback/logback-classic/1.0.7/jar/7c56c1e6000fa1c2e71b88b09435d9a5710b8d66/logback-classic-1.0.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]

I also see these warnings when starting with jettyRun.daemon = true. This is the first pointer that there is something wrong with the classpath, and that gradle internal jars are being pulled along. Now, while the jettyRun tasks is still on, go to http://localhost:8080/test/test which is a simple servlet, and you will see that I can successfully load a class that is only in gradle libs. I load ReplaceTokens filter with Class.forName and print its PtotectionDomains’ location, and get this: class loaded from file:/home/wujek/.gradle/wrapper/dists/gradle-1.6-bin/72srdo3a5eb3bic159kar72vok/gradle-1.6/lib/ant-1.8.4.jar

In my build I iterate over jettyRun.classpath and print everything out - and it contains only the entries I expect it to - but it lies. When I debug the application, the ClassLoader has a hierarchy of parents, and somewhere, some parent contains the gradle jars. This seems completely broken.

Expected behavior: Gradle doesn’t include it’s libraries in the task’s classpath.