[GRADLE-1766] A dependecy on sourceset.classes breaks GradleDependencies classpath container in Eclipse/STS Created: 25/Aug/11  Updated: 01/Sep/16  Resolved: 01/Sep/16

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-3
Fix Version/s: None

Type: Bug
Reporter: Kris De Volder Assignee: Unassigned
Resolution: Won't Fix Votes: 4

Issue Links:
Duplicated by GRADLE-1116 IDEA/Eclipse plugins should replace a... Resolved


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


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

Comment by Kris De Volder [ 25/Aug/11 ]

I can see two ways forward towards fixing this problem. The easiest is probably to aproximate dependencies like these as dependencies on the project that contains the respective source set.

Another possiblity is that Gradle tooling api provide information on output folders associated with source folders (currently no such information is provided, so I'm setting all output folder to the Eclipse default).

Then ensure that sourceSet.classes returns the same output folder as was associated with the sourcefolder.

I'm not so sure how well this will work in Eclipse, I don't think it is generally a good idea to have one project depend on binary class folder in another project. This tends to lead to problem with build mechanics/ordering and trouble associating source code with the class files.

So I think remapping it as a project dependency is probably best.

Comment by Kris De Volder [ 25/Aug/11 ]

Classified as minor issue because there is a relatively easy workaround.

Comment by Rob Winch [ 27/Aug/11 ]

I'm not sure I consider this minor because, unless I am missing something, the workaround will break the actual gradle build. I believe this issue may be related to GRADLE-1116

Comment by Adam Murdoch [ 04/Sep/11 ]

I think we should map this as a project dependency.

Comment by Stefan Oehme (Inactive) [ 01/Sep/16 ]

I'm closing this as projects should not reach into other project's sourceSets anyway. Instead, this should be modeled as a custom configuration in the provider project and a plain project dependency in the consumer project.

Comment by Rob Winch [ 01/Sep/16 ]

Thanks for your reply.

Can you provide an example of how you intend for this to be modeled? For your convenience, I have provided a minimal sample project https://github.com/rwinch/GRADLE-1766

Comment by Stefan Oehme (Inactive) [ 01/Sep/16 ]

I sent a PR for the example repo.

Comment by Rob Winch [ 01/Sep/16 ]

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".

Comment by Rob Winch [ 01/Sep/16 ]

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

Comment by Stefan Oehme (Inactive) [ 01/Sep/16 ]

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.

Comment by Stefan Oehme (Inactive) [ 01/Sep/16 ]

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.

Generated at Wed Jun 30 12:03:48 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.