Well, yes. I apologize for the “wordiness” but I needed to set the proper context in one place. Yes, in a way, you could look at it as that the problem is that “naughty” code compiles in Eclipse. It is not the problem that it fails in Gradle - it should.
The problem is the entire model of (lack of) mapping between Gradle classpaths and Eclipse ones, while maintaining separation. I am looking for a complete solution, not a partial one. This means:
-
The main code should not have visibility into test code. The test code should have visibility into main code. [For a single project].
-
The main code should only be able to directly reference “compile” dependencies, not those that are “runtime only” (in runtime config but not compile).
-
Analogous to (2), the test code should only be able to directly references “testCompile” dependencies (and main code)… Generally speaking “testCompile” configurations extends the “compile” one.
-
Since (2) and (3) do not contain (test)Runtime dependencies, these need to be put somewhere so that we have the chance of running the main code and tests from Eclipse. Generally speaking “runtime” configuration extends “compile” and “testRuntime” extends BOTH “runtime” and “testCompile”.
-
When we want to refresh dependencies (e.g. gradle --refresh-dependencies eclipseClasspath) this should update compile, testCompile, runtime and testRuntime classpaths in Eclipse, wherever they are, so that Eclipse launch configurations (continue to) work. This is for both main code and test launch configurations.
We are struggling to achieve the above and are looking for a whole solution for this.