1.58.0 is missing linux-x64 and win32-arm64 builds on Open VSX
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 48/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- github-actions, java, typescript
研究方向
Start by reading .github/workflows/release.yml and the ovsx publish loop described in the issue, then compare its behavior with the successful Marketplace publishing step and the listed pre-releases. Confirm why Open VSX omitted the linux-x64 and win32-arm64 targets and identify a safe way to publish them; done means 1.58.0 exposes all seven expected targets or the issue documents why that release cannot be repaired.
由索引模型根據 Issue 內容生成。
描述
On Open VSX, release 1.58.0 is published without the linux-x64 and
win32-arm64 target platforms. The same release has all seven targets on the
VS Code Marketplace.
Since the platform-specific builds are the ones that embed a JRE, a linux-x64
client falls back to the universal build, which embeds nothing. Combined with
the JDK 25 minimum introduced in 1.57.0, any Open VSX-based editor on linux-x64
without a system JDK 25+ now fails to start the language server:
Java 25 or more recent is required to run the Java extension. Please download
and install a recent JDK. You can still compile your projects with older JDKs
by configuring ['java.configuration.runtimes']
To Reproduce
- On a linux-x64 machine with only a JDK older than 25 installed, install
redhat.javafrom Open VSX (VSCodium, Theia, or any Open VSX-based editor)
on the stable channel. - The gallery resolves 1.58.0 and installs the
universaltarget, because no
linux-x64target is published for that version. - Open any Java file. The language server does not start and the Java 25
notification appears.
Target platforms published per version, from
https://open-vsx.org/api/redhat/java/<version> compared against the
Marketplace extensionquery API:
version Open VSX MS Marketplace
----------------------- -------------------------- --------------------------
1.55.0 7 targets, incl linux-x64 7 targets, incl linux-x64
1.56.0 7 targets, incl linux-x64 7 targets, incl linux-x64
1.57.0 7 targets, incl linux-x64 7 targets, incl linux-x64
1.58.0 5 targets, NO linux-x64 7 targets, incl linux-x64
1.58.2026101608 (pre) 7 targets, incl linux-x64 7 targets, incl linux-x64
1.59.2026102008 (pre) 7 targets, incl linux-x64 7 targets, incl linux-x64
Missing from Open VSX for 1.58.0: linux-x64 and win32-arm64.
Expected behavior
1.58.0 on Open VSX carries the same seven targets as the Marketplace, so
linux-x64 clients receive the platform build with its embedded JRE 25.
Environment
- Operating System: Amazon Linux 2023 (x86_64) under WSL2
- JDK version: Corretto 21.0.12.1 (the distro's repo snapshot carries no JDK 25)
- Visual Studio Code version: Open VSX-based editor, remote/WSL server
- Java extension version: 1.58.0,
universaltarget, installed from Open VSX
Additional Information
The artifacts were built correctly -- the same release published all seven
targets to the Marketplace -- so this looks like the Open VSX upload of those
two not landing, rather than a packaging problem.
The publish step in .github/workflows/release.yml loops one ovsx publish
per artifact:
for platformVsix in java-*-*-${GITHUB_RUN_NUMBER}.vsix; do
ovsx publish --skip-duplicate -p ${{ secrets.OVSX_MARKETPLACE_TOKEN }} --packagePath ${platformVsix}
done
In glob order the outcome was: darwin-arm64 ok, darwin-x64 ok,
linux-arm64 ok, linux-x64 missing, win32-arm64 missing,
win32-x64 ok. Because run: blocks execute as bash -e, a non-zero exit
would have aborted the step before win32-x64 succeeded -- so ovsx publish
appears to have exited 0 without persisting those two uploads.
Worth noting that --skip-duplicate means a re-run will not re-upload a
version Open VSX already records, so 1.58.0 probably cannot self-heal. Either a
manual upload of the two missing targets, or a republish under a new version,
would be needed.
The pre-releases immediately before (1.58.2026101608, 16-Oct) and after
(1.59.2026102008, 20-Oct) both published all seven targets from the same
workflow, which points at a single transient failure rather than a config
change.
- 主要語言
- TypeScript
- 星號
- 2.3k
- 分支
- 550
- 平均合併
- 4 天 5 小時
- 30 天內合併 PR
- 14
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
redhat-developer/vscode-java 的其他 Issue
-
enhancement
難度 4/5 3-5 天 新手友好度 48/100
redhat-developer/vscode-java#4552 ·
維護者通常 1 天內回覆
-
bug
難度 3/5 1-2 天 新手友好度 55/100
redhat-developer/vscode-java#4550 · 1 則留言 · 1 個 reaction ·
維護者通常 1 天內回覆
-
bug
難度 4/5 3-5 天 新手友好度 48/100
redhat-developer/vscode-java#4537 ·
維護者通常 1 天內回覆
-
bug need info
難度 4/5 3-5 天 新手友好度 35/100
redhat-developer/vscode-java#4520 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 25/100
redhat-developer/vscode-java#4517 · 1 則留言 ·
維護者通常 1 天內回覆
查看 redhat-developer/vscode-java 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 68/100
maniator/verticopolis#1303 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 73/100
components-web-app/docs#297 ·
-
難度 2/5 1-3 小時 新手友好度 68/100
appwrite/mcp-for-docs#23 · 1 則留言 ·
-
`@vanilla-extract/turbopack-plugin`: "getImageSize is not a function" with Next.js 16.4.x when a `.css.ts` file imports an image可能已有人在做 @aevarOrigo 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 78/100
vanilla-extract-css/vanilla-extract#1799 · 1 則留言 ·
-
native
難度 2/5 1-3 小時 新手友好度 72/100
prime-radiant-inc/evener#4839 ·
維護者通常 1 天內回覆