omega09
December 16, 2023, 12:53am
1
As has been reported by posts such as
opened 08:21PM - 03 Sep 22 UTC
closed 08:42AM - 08 Sep 22 UTC
closed:invalid
Classes from `src/main/java` in projects containing text fixtures can no longer … be resolved in Eclipse (i.e. `Xyz cannot be resolved to a type`). It works with 7.4.2, but does not work with 7.5 or 7.5.1.
### Expected Behavior
Eclipse should be able to resolve the classes, as it previously did.
### Current Behavior
The classes from `src/main/java` cannot be resolved in Eclipse.
### Context
### Steps to Reproduce
1. Clone https://github.com/mweber03/gradle-test
2. Import into Eclipse
4. In Eclipse, `Gradle > Refresh Gradle Project` (note the clean build, no red Xs on classes)
5. Upgrade project to Gradle 7.5.1 (`./gradlew wrapper --gradle-version 7.5.1`)
6. In Eclipse, `Gradle > Refresh Gradle Project` (note classes can no longer be resolved)
### Your Environment
Build scan URL: https://gradle.com/s/lpfpi33q6j54o
opened 08:52AM - 20 Sep 22 UTC
a:bug
### Expected Behavior
Eclipse compiles if I use testImplementation testFixtures… and implementation of the same project as it does with `Gradle 7.4.2`!
### Current Behavior
As soon as I need the above listed configurations, Eclipse doesn't compile successful.
### Context
A minimal setup to reproduce is present here: https://github.com/BisonSchweizAG/gradleproblem/tree/main
### Steps to Reproduce
Clone above project, import into Eclipse --> will not compile!
Build on command line will work.
Remove needed line `testImplementation testFixtures(project(':projectA'))` from `build.gradle` --> Eclipse compiles, command line build won't!
### Your Environment
```
Eclipse:
Version: 2022-06 (4.24.0)
Build id: 20220609-1112
Gradle: 7.5.1
Buildship: 3.1.6.v20220511-1359
```
opened 04:29PM - 06 Nov 22 UTC
Gradle
compile
Hi, I have a multi-modules gradle/java project in which I'm trying to centralize… some test fixtures (aka test helper classes to help build test data etc) in some kind of library module, so that those java test fixtures classes can then be shared in multiple dependant modules (I'm referring precisely to this [gradle test fixtures feature](https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures)).
The problem I'm having in VS Code (with the Java extension) is that once I've defined my test fixtures in the lib module (see steps to reproduce below), as soon as I try to "consume" them by adding the dependency in a gradle dependant module build file ([as explained here in gradle doc](https://docs.gradle.org/current/userguide/java_testing.html#consuming_test_fixtures_of_another_project)), something like:
```
dependencies {
implementation(project(":lib-module"))
testImplementation(testFixtures(project(":lib-module")))
}
```
it will create compile errors under the vs code Problems tab that the dependant module can no longer see any dependency imports made by the basic `implementation(project(":lib-module"))`.
However, if I build everything with gradle, it will work just fine. The reported compile errors are only visual, within the Problems tab of the vscode editor.
Then, if I comment out the gradle testFixtures dependency import as follow:
```
dependencies {
implementation(project(":lib-module"))
//testImplementation(testFixtures(project(":lib-module")))
}
```
all compile errors will be gone from the vs code Problems tab, BUT, then if I try to run a gradle build task, it will fail saying that my tests no longer have access to the test fixtures imports from the lib module.
This seems to me like an issue with the vscode-java extension (or upstream?) not supporting properly the gradle testFixtures feature, preventing us from sharing in a very simple way test fixtures among multiple modules.
##### Environment
Operating System: macOS big sur (11.6.5)
JDK version: openjdk version "17.0.4.1" 2022-08-12
Visual Studio Code version: 1.71.0
Java extension version: 1.12.0
##### Steps To Reproduce
1. Create a multi-modules gradle java project (2 modules should be enough, the lib exposing both normal lib utility/service classes and also test fixtures)
2. Create one normal utility class in the lib module, can be just a simple pojo... (`<lib-module>/src/main/java/com/...`)
3. Create one test fixture class also under the lib module, can be just a simple pojo... (`<lib-module>/src/testFixture/java/com/...`)
4. Add the gradle test Fixtures plugin under your lib gradle build file (`<lib-module>/build.gradle`)
```
plugins {
// A Java Library
id 'java-library'
// which produces test fixtures
id 'java-test-fixtures'
}
```
5. In the second dependant module, create one normal class that will consume/import the utility class from the lib module created in step 2 (`<dependant-module>/src/main/java/com/...`)
6. In the second dependant module, create a test class that will consume/import the test fixture class from the lib module created in step 3 (`<dependant-module>/src/test/java/com/...`), the test class can just be a simple pojo, no need to import any test framework for this, we're just testing dependencies between gradle modules...
7. Add the dependencies under the dependant module's gradle build file, so that it sees both the utility class AND the test fixture class from the lib module (`<dependant-module>/build.gradle`):
```
dependencies {
implementation(project(":lib-module"))
testImplementation(testFixtures(project(":lib-module")))
}
```
8. Save everything, and you should expect to see compile errors in the vs code Problems tab, complaining about the fact that your dependant module's normal pojo class created in step 5 is unable to import the utility class from the lib module (that's right, the error might not even be inside your test class, but it could, it all depends where you've imported the lib utility class in this example, whether it's within the normal class in step 5, but it could have been under your test class of step 6 too; bottom line is, the compile error will be related to the normal lib classes that can no longer be imported in the dependant module(s); the test fixtures classes 'are' being imported properly.. So it really seems like if importing the 'test fixtures' will PREVENT the normal lib classes from being imported).
### Sample project
I've created this basic sample project which reproduces the error:
https://github.com/Frank-D/multi-modules-root
##### Current Result
Compile errors showing under vs code Problems tab (e.g., using gradle test fixtures lib dependency hides the basic lib module dependency).
##### Expected Result
No compile errors showing under vs code Problems tab (e.g. using gradle test fixtures works without any issue within vs code using the vscode-java extension).
##### Additional Informations
Here's a screenshot of the vs code Problems, when reproducing the described error with the previous 'Sample project':
declaring
dependencies {
implementation project(':my-project')
testImplementation testFixtures(project(':my-project'))
}
Causes compilation errors in Eclipse, while things work well from Gradle and in other IDEs. The above dependency configuration is not only valid, but also recommended in such cases. For example, here at 4:50:
I read about the changes in Gradle 7.5 and the 2 classpaths in Eclipse (The Eclipse Plugins ). Note that 7.5+ - Eclipse cannot resolve types from projects with text fixtures · Issue #21853 · gradle/gradle · GitHub is still active, requesting a fix, and like the last comment there by effad, I also have to wonder about the choice that was made when both test=false and test=true are present. The above configuration means “I need the main source set of the dependency for my main source set and the testFixtures source set for my tests source set”.
This configuration should be made valid in Eclipse out of the box since it’s valid in Gradle and we shouldn’t need to choose one or the other. It seems that this is something Buildship should do (or is it the responsibility of the eclipse plugin?).
@donat Can you have a look?
