Commit 6133b3f
authored
fix: sync javaExtensions to the actual JUnit jar versions in server/ (#1869)
* fix: sync javaExtensions to the actual JUnit jar versions in server/
scripts/buildJdtlsExt.js rebuilds contributes.javaExtensions from the
files that the Maven build dropped into server/, but main was last
committed before a 5.14.3 -> 5.14.4 / 1.14.3 -> 1.14.4 bump landed in
the java-extension POMs. As a result, the published extension declares
six jars that the build no longer produces:
junit-jupiter-api_5.14.3.jar (actual: 5.14.4)
junit-jupiter-engine_5.14.3.jar (actual: 5.14.4)
junit-jupiter-params_5.14.3.jar (actual: 5.14.4)
junit-platform-commons_1.14.3.jar (actual: 1.14.4)
junit-platform-engine_1.14.3.jar (actual: 1.14.4)
junit-platform-launcher_1.14.3.jar (actual: 1.14.4)
At runtime the JDT-LS bundle loader fails on each missing file with:
Cannot extract bundle symbolicName or version
.../server/junit-jupiter-api_5.14.3.jar
java.nio.file.NoSuchFileException: ...
leaving the test plugin partially or fully unloaded depending on what
else fails first. The user-visible symptom is "Enable Java Tests" doing
nothing on a clean install, no test discovery, and JDT-LS surfacing
"N uncaught errors" in the status bar.
This commit just brings the javaExtensions entries in line with what
server/ actually contains today. Re-running `npm run build-plugin`
produces the same diff, so there is no risk of further drift from this
change. A follow-up should consider failing the build (or at least
emitting a warning) when scripts/buildJdtlsExt.js detects a mismatch
between the regenerated list and the committed one, so this kind of
drift can't slip into another release unnoticed.
* ci: fail CI when buildJdtlsExt.js would rewrite package.json
The Build OSGi bundle step runs scripts/buildJdtlsExt.js, which
unconditionally regenerates contributes.javaExtensions from the jars
the Maven build actually drops into server/. If the committed array is
stale (e.g. someone bumped a Maven dependency in java-extension/
without re-running the build), the regenerated array silently goes out
of sync and the published extension declares jar paths that no longer
exist on disk - exactly the failure mode this PR is fixing.
Add a one-line guard after build-plugin on each OS job:
git diff --exit-code --ignore-cr-at-eol -- package.json
When the script rewrites the file, git reports a non-zero diff and the
job fails with the exact list of stale entries, so the fix is just
"copy the diff into the commit, push again". --ignore-cr-at-eol keeps
Windows runners from tripping on LF/CRLF round-trips that don't change
the underlying list.1 parent 04d1702 commit 6133b3f
2 files changed
Lines changed: 21 additions & 6 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
41 | 41 | | |
42 | 42 | | |
43 | 43 | | |
| 44 | + | |
| 45 | + | |
| 46 | + | |
| 47 | + | |
| 48 | + | |
| 49 | + | |
| 50 | + | |
| 51 | + | |
| 52 | + | |
44 | 53 | | |
45 | 54 | | |
46 | 55 | | |
| |||
78 | 87 | | |
79 | 88 | | |
80 | 89 | | |
| 90 | + | |
| 91 | + | |
| 92 | + | |
81 | 93 | | |
82 | 94 | | |
83 | 95 | | |
| |||
115 | 127 | | |
116 | 128 | | |
117 | 129 | | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
118 | 133 | | |
119 | 134 | | |
120 | 135 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
56 | 56 | | |
57 | 57 | | |
58 | 58 | | |
59 | | - | |
| 59 | + | |
60 | 60 | | |
61 | | - | |
| 61 | + | |
62 | 62 | | |
63 | 63 | | |
64 | | - | |
| 64 | + | |
65 | 65 | | |
66 | | - | |
| 66 | + | |
67 | 67 | | |
68 | | - | |
| 68 | + | |
69 | 69 | | |
70 | | - | |
| 70 | + | |
71 | 71 | | |
72 | 72 | | |
73 | 73 | | |
| |||
0 commit comments