Fix Scala Gradle classpath pollution#3776
Conversation
|
@jjohnstn |
Jenkins access rules just changed so the javac repo needs to move. The javac folks are looking into it. |
e0b89cc to
2ee161d
Compare
|
@wenytang-ms Rebased your patch so the target is updated with the new javac repo location. |
|
@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 |
|
@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! |
|
Stack Trace org.opentest4j.AssertionFailedError: |
|
@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. |
|
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.
59e64ee to
e83330a
Compare
|
@wenytang-ms seems like there's relevant test failures |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
7f5421c to
7acf281
Compare
7acf281 to
6f64d62
Compare
|
Superseded by #3815 with a clean branch and focused commit history. |
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