redhat-developer / redhat-developer/vscode-java

Extension holds locks on JAR files referenced in POM.xml

オープン
#3,512 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
TypeScript
スター
2.3k
フォーク
546
平均マージ
20時間 1分
マージ済み PR(30日)
11

説明

I use bazel to compile/package my java project, but I have some bazel rules to build a pom.xml so eclipse can work with the project. I've been trying to switch to vscode-java, and one of the problems I'm having is that the language server seems to be holding a lock on my dependent JAR files, so that I can no longer rebuild with bazel. Eclipse does not have this problem.

Environment
  • Operating System: Win11
  • JDK version: 19
  • Visual Studio Code version: Codium 1.85.1
  • Java extension version: 1.28.1
Steps To Reproduce
  • My bazel project references a dependent project named 're-eval', which produces a jar file named 'libre-eval.jar'. I run my bazel build command to build the dependent jars.
  • I then generate a POM file that references that jar file in my bazel bin directory, using the system scope so that I can reference the direct path:
<dependency>
	<groupId>com.bazel.dependency</groupId>
	<artifactId>re-eval</artifactId>
	<version>1.0.0-bazel</version>
	<systemPath>D:\MyProj\.bazel/out/x64_windows-fastbuild/bin/external/re/re-eval/libre-eval.jar</systemPath>
	<scope>system</scope>
</dependency>
  • Next I open VSCode to this project. The language server opens the project, everything loads fine.
  • Finally I try to run my build again. Bazel can't rebuild that jar file because:
> bazel build //:project
INFO: Analyzed target //:project (81 packages loaded, 6098 targets configured).
INFO: Found 1 target...
ERROR: D:/bazel/y4yaxzuk/external/re/re-eval/BUILD:9:13: Building external/re/re-eval/libre-eval.jar (2 source files) failed: failed to delete output files before executing action: D:/bazel/y4yaxzuk/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/external/re/re-eval/libre-eval.jar (Permission denied)
Target //:project failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 12.805s, Critical Path: 4.09s
INFO: 24 processes: 13 internal, 10 local, 1 worker.
FAILED: Build did NOT complete successfully
  • The process that has a lock on this file is:
C:\apps\Java\jdk-19.0.1\bin\java --add-modules=ALL-SYSTEM --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/sun.nio.fs=ALL-UNNAMED -Declipse.application=org.eclipse.jdt.ls.core.id1 -Dosgi.bundles.defaultStartLevel=4 -Declipse.product=org.eclipse.jdt.ls.core.product -Djava.import.generatesMetadataFilesAtProjectRoot=false -DDetectVMInstallationsJob.disabled=true -Dfile.encoding=utf8 -XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx1G -Xms100m -Xlog:disable -javaagent:c:\apps\Scoop\apps\vscodium\1.85.1.23348\data\extensions\redhat.java-1.28.1-win32-x64\lombok\lombok-1.18.31.jar -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=c:\apps\Scoop\apps\vscodium\1.85.1.23348\data\user-data\User\workspaceStorage\752d67d371268c29632f9f8dea706e20\redhat.java -Daether.dependencyCollector.impl=bf -jar C:\apps\Scoop\persist\vscodium\data\extensions\redhat.java-1.28.1-win32-x64\server\plugins\org.eclipse.equinox.launcher_1.6.700.v20231214-2017.jar -configuration c:\apps\Scoop\apps\vscodium\1.85.1.23348\data\user-data\User\globalStorage\redhat.java\1.28.1\config_win -data c:\apps\Scoop\apps\vscodium\1.85.1.23348\data\user-data\User\workspaceStorage\752d67d371268c29632f9f8dea706e20\redhat.java\jdt_ws --stdio

It seems that this process has a lock on all of the Jars defined in the pom.xml file according to Process Explorer. I've disabled the "Maven for Java" and "Project Manager for Java" extensions, and only have the "Language Support for Java" extension enabled.

Eclipse opens the same project with the same pom file and I can rebuild my project through bazel without having file locks - I do need to do a project refresh in Eclipse sometimes to get it to pick up API changes from those builds, so maybe this is just a fundamental difference between Eclipse (a bit more manual) and VSCode (a bit more automated). Are there any workarounds to this issue?

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

libre-eval.jar への POM 依存関係を設定した状態で VSCode で Bazel プロジェクトを開き、Win11 のワークフローを再現します。次に、報告された bazel build コマンドを実行し、ファイルロックの有無を Java language-server プロセスで調査します。VSCode を開いたまま依存する JAR を再ビルドでき、Eclipse スタイルの手動リフレッシュ回避策を必要としなければ完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
java
領域
build-system, devtools
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。