Uploaded image for project: 'Gradle'
  1. Gradle
  2. GRADLE-1766

A dependecy on sourceset.classes breaks GradleDependencies classpath container in Eclipse/STS

    Details

    • Type: Bug
    • Status: Resolved
    • Resolution: Won't Fix
    • Affects Version/s: 1.0-milestone-3
    • Fix Version/s: None

      Description

      Problem manifests itself in this project http://static.springsource.org/spring-security/site/source.html

      When this project is imported into STS Gradle tooling, it produces an invalid classpath for some of the subprojects.
      The error is as follows:

      msg :The container 'Gradle Dependencies' references non existing library '.../spring-security/core/build/classes/test' project: spring-security-web

      This message seems to be caused by the following lines in the projects buid file:

      dependencies {
          ...
          testCompile project(':spring-security-core').sourceSets.test.classes,
                      ...
      }
      

      Workaround, replace the above with

      dependencies

      { ... testCompile project(':spring-security-core'), ... }

        Issue Links

          Activity

          Hide
          oehme Stefan Oehme added a comment -

          I sent a PR for the example repo.

          Show
          oehme Stefan Oehme added a comment - I sent a PR for the example repo.
          Hide
          rwinch Rob Winch added a comment -

          Thanks for the PR. This does indeed work, but it is a lot more verbose than the previous solution. From what I can tell this also adds additional work to ensure that "-tests" artifacts are not published.

          I'm curious in why the original solution is "wrong". How would a user know this is incorrect? The APIs allow for it to be configured this way. Adam even commented on this issue stating "I think we should map this as a project dependency".

          Show
          rwinch Rob Winch added a comment - Thanks for the PR. This does indeed work, but it is a lot more verbose than the previous solution. From what I can tell this also adds additional work to ensure that "-tests" artifacts are not published. I'm curious in why the original solution is "wrong". How would a user know this is incorrect? The APIs allow for it to be configured this way. Adam even commented on this issue stating "I think we should map this as a project dependency".
          Hide
          rwinch Rob Winch added a comment -

          I should add that this has since been fixed when using IntelliJ's Gradle Tooling.

          Show
          rwinch Rob Winch added a comment - I should add that this has since been fixed when using IntelliJ's Gradle Tooling.
          Hide
          oehme Stefan Oehme added a comment -

          There is no work needed to exclude that from publishing, as we defined a new configuation. Gradle only publishes the "artifacts" configuration by default.

          As for verbosity: This can easily be extracted into a tests-jar plugin if you have this pattern a lot. You might even want to create a separate sourceSet for test fixtures, because it's probably those that you want to share, not the actual test cases themselves.

          The original solution is bad practice just like any other "reaching over into another project's guts". It highly couples the configuration phase of those two projects. You can do it, but we highly discourage it. I don't see it as worthwhile to make the IDE plugins more complicated to support something that we actively discourage.

          Show
          oehme Stefan Oehme added a comment - There is no work needed to exclude that from publishing, as we defined a new configuation. Gradle only publishes the "artifacts" configuration by default. As for verbosity: This can easily be extracted into a tests-jar plugin if you have this pattern a lot. You might even want to create a separate sourceSet for test fixtures, because it's probably those that you want to share, not the actual test cases themselves. The original solution is bad practice just like any other "reaching over into another project's guts". It highly couples the configuration phase of those two projects. You can do it, but we highly discourage it. I don't see it as worthwhile to make the IDE plugins more complicated to support something that we actively discourage.
          Hide
          oehme Stefan Oehme added a comment -

          Another reason why the original solution is wrong is that it does not include transitive dependencies. You are just depending on a folder full of classes. So you are implicitly requiring that the consumer project has the same testCompile dependencies as the producer project.

          Using the configuration-based approach I showed in the PR, you get proper transitive dependency resolution.

          Show
          oehme Stefan Oehme added a comment - Another reason why the original solution is wrong is that it does not include transitive dependencies. You are just depending on a folder full of classes. So you are implicitly requiring that the consumer project has the same testCompile dependencies as the producer project. Using the configuration-based approach I showed in the PR, you get proper transitive dependency resolution.

            People

            • Assignee:
              Unassigned
              Reporter:
              kdvolder Kris De Volder
            • Votes:
              4 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development