Skip to content

fix(test-plans): use self-contained Maven fixture for resolve-unknown-type plan#1617

Merged
wenytang-ms merged 1 commit intomainfrom
fix/maven-resolve-type-fixture
May 7, 2026
Merged

fix(test-plans): use self-contained Maven fixture for resolve-unknown-type plan#1617
wenytang-ms merged 1 commit intomainfrom
fix/maven-resolve-type-fixture

Conversation

@wenytang-ms
Copy link
Copy Markdown
Contributor

What & Why

The java-maven-resolve-type E2E plan has been failing in scheduled runs (e.g. actions/runs/25419116469). Investigation showed:

  • Old fixture: redhat-developer/vscode-java's salut Maven project, which sets <source>1.7</source> / <target>1.7</target>.
  • CI runners only install JDK 21.
  • Under that mismatch JDT reports the pom compliance warnings ("compiler compliance 1.7 but JRE 11 is used") and shows Java: Ready, but never publishes semantic diagnostics for Foo.java. So Gson gson; does not produce a Gson cannot be resolved to a type error and navigateToError / applyCodeAction "Resolve unknown type" cannot proceed.
  • Older @vscjava/vscode-autotest masked this with a silent-fallback in applyCodeAction (Enter on whatever the first action happened to be). Once that fallback was removed upstream, the plan started consistently failing on [check-code-action] applyCodeAction "Resolve unknown type" with Available actions: Extract interface..., Source Actions....

Verified locally: bumping the pom to <release>11</release> makes JDT publish the unresolved-type diagnostic in ~8 s and the full plan goes from 4/6 → 6/6 passed.

Change

Add a small, self-contained Maven fixture under test-fixtures/maven-resolve-type/ that targets JDK 11 explicitly, and re-point the test plan at it:

  • test-fixtures/maven-resolve-type/pom.xmlmaven-compiler-plugin 3.8.0, <release>11</release>, no extra deps.
  • test-fixtures/maven-resolve-type/src/main/java/com/example/App.java — minimal class.
  • test-fixtures/maven-resolve-type/README.md — explains why the fixture lives here and the JDK-compliance pitfall.
  • test-plans/java-maven-resolve-type.yamlworkspace repointed; opens App.java; inserts Gson gson; at line 4 (inside the class body); rest of the steps unchanged.

Why a local fixture rather than reusing salut-java11

Owning the fixture in this repo decouples this plan from upstream vscode-java test-resource changes and removes the implicit ordering dependency of git clone vscode-java finishing before this plan can run.

Verification

Local run with @vscjava/vscode-autotest (with the upcoming navigateToError fix that fails fast instead of falling through to warnings):

✅ [ls-ready] waitForLanguageServer (55088ms)
✅ [open-app] open file App.java (1299ms)
✅ [insert-unknown-type] insertLineInFile ... (3974ms)
✅ [navigate-to-error] navigateToError 1 (8083ms)
✅ [check-code-action] applyCodeAction Resolve unknown type (2559ms)
✅ [save-after-resolve] saveFile (970ms)
📊 Results: 6/6 passed

Problems panel screenshot confirms Gson cannot be resolved to a type Java(16777218) is published on App.java:4, which is the diagnostic code the vscode-maven Resolve unknown type Code Action keys on.

…-type plan

The plan previously pointed at redhat-developer/vscode-java's salut Maven fixture, which configures maven-compiler-plugin with <source>1.7</source>/<target>1.7</target>. On the CI runners (which install only JDK 21) this puts the workspace in a state where JDT reports compliance warnings on the pom but skips full semantic analysis on the Java source -- the inserted `Gson gson;` field never produces a `Gson cannot be resolved to a type` diagnostic, so navigateToError can never find the error and applyCodeAction `Resolve unknown type` is unreachable.

Older versions of @vscjava/vscode-autotest masked this failure mode by silently pressing Enter on whatever the first Code Action happened to be; once that fallback was removed upstream the plan started reliably failing in scheduled runs (e.g. actions/runs/25419116469).

Add a minimal self-owned Maven fixture under test-fixtures/maven-resolve-type that explicitly targets JDK 11 (<release>11</release>), matching the JDK installed by the workflow. Locally this brings navigateToError from a 30s timeout to ~8s and the full plan to 6/6 passing.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@wenytang-ms wenytang-ms merged commit ce1b9bc into main May 7, 2026
2 checks passed
@wenytang-ms wenytang-ms deleted the fix/maven-resolve-type-fixture branch May 7, 2026 02:18
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.

2 participants