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?

Reproduisez le workflow Win11 en ouvrant le projet Bazel dans VSCode avec la dépendance POM vers libre-eval.jar, puis exécutez la commande bazel build signalée et inspectez le processus Java language-server pour détecter le verrouillage du fichier. Le travail est considéré comme terminé lorsque le JAR dépendant peut être reconstruit alors que VSCode reste ouvert, sans nécessiter le workaround d’actualisation manuelle de type Eclipse.