Skip to content

Fix Scala Gradle classpath pollution#3776

Closed
wenytang-ms wants to merge 21 commits into
eclipse-jdtls:mainfrom
wenytang-ms:fix-gradle-scala-classpath-regression
Closed

Fix Scala Gradle classpath pollution#3776
wenytang-ms wants to merge 21 commits into
eclipse-jdtls:mainfrom
wenytang-ms:fix-gradle-scala-classpath-regression

Conversation

@wenytang-ms

@wenytang-ms wenytang-ms commented May 8, 2026

Copy link
Copy Markdown
Contributor

Limit Scala Gradle classpath augmentation to projects that actually apply the Scala plugin and ignore artifacts produced by Gradle project dependencies. This prevents local project dependencies from being written as raw build/libs library entries.

Stop emitting source/resource markers from the Scala Gradle init script and remove the Java-side resource exclusion rewrite so src/main/resources remains visible on the classpath.

Add a multi-project Scala Gradle fixture covering project dependencies and resources.

relative issue:
redhat-developer/vscode-java#4399
redhat-developer/vscode-java#4398
redhat-developer/vscode-java#4393

@wenytang-ms

Copy link
Copy Markdown
Contributor Author

@jjohnstn
the build pipeline failed, do you know how to resolve the CI failure?

@jjohnstn

jjohnstn commented May 8, 2026

Copy link
Copy Markdown
Contributor

@jjohnstn the build pipeline failed, do you know how to resolve the CI failure?

Jenkins access rules just changed so the javac repo needs to move. The javac folks are looking into it.

@jjohnstn jjohnstn force-pushed the fix-gradle-scala-classpath-regression branch from e0b89cc to 2ee161d Compare May 11, 2026 19:31
@jjohnstn

Copy link
Copy Markdown
Contributor

@wenytang-ms Rebased your patch so the target is updated with the new javac repo location.

@wenytang-ms

Copy link
Copy Markdown
Contributor Author

@jjohnstn the jenkins build still failed, I don't have account to sign into eclipse Jenkins pipeline to see the root cause, can you tell me what should I do?

@jjohnstn

Copy link
Copy Markdown
Contributor

@jjohnstn the jenkins build still failed, I don't have account to sign into eclipse Jenkins pipeline to see the root cause, can you tell me what should I do?

The build itself is not failing any more - there are test failures after applying your patch.

You should be able to click on the Jenkins Build link above that shows the failures. There are 2 new test failures that you need to address:

org.eclipse.jdt.ls.core.internal.managers.GradleProjectImporterTest.testScalaSupportEnabled
org.eclipse.jdt.ls.core.internal.managers.GradleProjectImporterTest.testScalaSupportTaskNoopsForNonScalaProject

@wenytang-ms

wenytang-ms commented May 20, 2026

Copy link
Copy Markdown
Contributor Author

@jjohnstn all the link or CI pipeline need to sign in with username + password. the error msg is still lost. can you paste the error msg here? thanks!

@jjohnstn

Copy link
Copy Markdown
Contributor

Stack Trace

org.opentest4j.AssertionFailedError:
app has errors:
Type=org.eclipse.jdt.core.problem:Message=The import org.example.App cannot be resolved:LineNumber=4, Type=org.eclipse.jdt.core.problem:Message=App cannot be resolved:LineNumber=8, Type=org.eclipse.jdt.core.problem:Message=org.example.App$ cannot be resolved:LineNumber=9 ==> expected: <0> but was: <3>
at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:563)
at org.eclipse.jdt.ls.core.internal.managers.AbstractProjectsManagerBasedTest.assertNoErrors(AbstractProjectsManagerBasedTest.java:401)
at org.eclipse.jdt.ls.core.internal.managers.GradleProjectImporterTest.testScalaSupportEnabled(GradleProjectImporterTest.java:867)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)

@datho7561

Copy link
Copy Markdown
Contributor

@jjohnstn I noticed this PR has been sitting in review for a while. Do you want to take another look at it when you have a chance? Otherwise, I could try and get to reviewing it sometime.

@datho7561

Copy link
Copy Markdown
Contributor

Going to rebase to after I've added a GitHub Actions-based CI so test results are easier to see

Limit Scala Gradle classpath augmentation to projects that actually apply the Scala plugin and ignore artifacts produced by Gradle project dependencies. This prevents local project dependencies from being written as raw build/libs library entries.

Stop emitting source/resource markers from the Scala Gradle init script and remove the Java-side resource exclusion rewrite so src/main/resources remains visible on the classpath.

Add a multi-project Scala Gradle fixture covering project dependencies and resources.
Always register the javalsCheckProject init-script task so Java-only Gradle projects do not fail with task-not-found when Scala support probes them. The task now no-ops unless the project applies the Scala plugin.

Remove obsolete SRC and RES parser branches and make artifact source lookup tolerant of artifacts without moduleVersion metadata.

Add coverage for running the Scala support init-script task against a non-Scala subproject.
The testScalaSupportTaskNoopsForNonScalaProject test connected the Gradle
Tooling API directly to the 'common' subdirectory, which has no settings.gradle,
gradlew, or wrapper. Behavior in that case is environment-dependent. Connect
to the multi-project root and reference the task by its qualified path
(:common:javalsCheckProject), and assert the absence of the javals protocol
markers (JAVALS_START / LIB|) instead of strict empty-stdout, which is
brittle against incidental Gradle/Tooling output.
…ported

GradleBuildSupport.compile(null) was only triggering compile tasks when a
workspace project's location matched the Gradle root project directory. In
multi-project builds where only the subprojects are imported as Eclipse
projects (e.g. a root with only settings.gradle and several include(...)
subprojects), no workspace project matched the root and the compile loop
silently did nothing - so compileScala/compileGroovy/compileKotlin/compileAj
never ran, leaving Java types that reference those languages unresolved.

Group workspace projects by their Gradle root and pick any one of them per
root to use as a connection point, then run the build from the root
directory itself. Also refresh any workspace gradle project located under
the gradle root so that JDT picks up class files written by the build,
even when the root directory is not imported as a workspace project.
@datho7561 datho7561 force-pushed the fix-gradle-scala-classpath-regression branch from 59e64ee to e83330a Compare June 17, 2026 16:18
@datho7561

Copy link
Copy Markdown
Contributor

@wenytang-ms seems like there's relevant test failures

@wenytang-ms wenytang-ms marked this pull request as draft June 18, 2026 08:54
@wenytang-ms wenytang-ms force-pushed the fix-gradle-scala-classpath-regression branch 3 times, most recently from 7f5421c to 7acf281 Compare June 18, 2026 14:26
@wenytang-ms wenytang-ms force-pushed the fix-gradle-scala-classpath-regression branch from 7acf281 to 6f64d62 Compare June 18, 2026 14:26
@wenytang-ms

Copy link
Copy Markdown
Contributor Author

Superseded by #3815 with a clean branch and focused commit history.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants