Buildscript transitive dependencies end up in generated Eclipse .classpath file

Old Forum Archive
1

Say I have the following build.gradle for a single project build:

buildscript {
 repositories {
  maven { url "http://host/artifactory/repo" }
 }
 dependencies {
  classpath group: "com.orbitz.gradle.cobertura", name: "gradle_cobertura", version: "1.0", classifier: "rc4"
 }
}
  repositories {
 maven { url "http://host/artifactory/repo" }
}
  apply plugin: "java"
apply plugin: "eclipse-wtp"
  apply plugin: com.orbitz.gradle.cobertura.CoberturaPlugin //from buildscript dependency
  cobertura {
 description = "Performs code coverage and creates a report"
 coverageFormat = 'xml'
}

When I run “gradle eclipse” for this project, all transitive dependencies of the buildscript dependency (but not the buildscript dependency itself) end up in the project’s generated .classpath file.

For this particular example, the buildscript dependency has the following POM:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.orbitz.gradle.cobertura</groupId>
  <artifactId>gradle_cobertura</artifactId>
  <version>1.0</version>
  <description>calculates the percentage of code accessed by tests</description>
 <dependencies>
    <dependency>
      <groupId>org.testng</groupId>
      <artifactId>testng</artifactId>
      <version>5.8</version>
      <classifier>jdk15</classifier>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>net.sourceforge.cobertura</groupId>
      <artifactId>cobertura</artifactId>
      <version>1.9.4.1</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.2</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

So I end up with the following transitive dependencies as project dependencies in Eclipse config: a. cobertura-1.9.4.1.jar b. oro-2.0.8.jar c. asm-3.0.jar d. asm-tree-3.0.jar e. log4j-1.2.9.jar f. ant-launcher-1.7.0.jar g. ant-1.7.0.jar But this is undesired. These are dependencies of the build script only, not project dependencies.

So I have 2 questions: 1. Is this expected behavior? 2. How can I prevent this outcome without explicitly excluding each transitive dependency?

2

BTW, I should mention I’m currently using 1.0-milestone-7.

3

Have you also tried without the Cobertura plugin, just adding some dependency to the build script? My guess is that the Cobertura plugin is adding these dependencies to the project itself (possibly to the testRuntime configuration). The DSL reference shows how you can tweak the Eclipse class path.

4

You’re right, Peter. In the source code for this particular plugin, I see it adding Cobertura as a testRuntime project dependency when the plugin is applied.

Since I don’t necessarily want to exclude all testRuntime dependencies from the Eclipse classpath, my solution is to explicitly add Cobertura to a custom configuration and then “minus” that configuration from the Eclipse classpath. Something like:

configurations {
 noEclipseClasspath
}
dependencies {
 //-- exclude dependency added implicitly by CoberturaPlugin from eclipse classpath
 noEclipseClasspath group: "net.sourceforge.cobertura", name: "cobertura", version: "1.9.4.1"
}
eclipse {
 classpath {
  minusConfigurations += configurations.noEclipseClasspath
 }
}

I should have known this problem was specific to this plugin. Thanks for the clue!