Extension holds locks on JAR files referenced in POM.xml

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?

通过在 VSCode 中打开带有指向 libre-eval.jar 的 POM 依赖的 Bazel 项目，复现 Win11 工作流，然后运行报告中的 bazel build 命令，并检查 Java language-server 进程是否存在文件锁。完成的标准是：在 VSCode 保持打开的情况下，可以重新构建依赖的 JAR，而不需要 Eclipse 风格的手动刷新变通方案。