-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Second "clean" build in fails on Windows due to locked files #115
Comments
With
|
The daemon caches the class loaders for plugins. I think the daemon should get rid of those. This is done automatically if the plugin has been recompiled when it's about to be used, but we definitely need to remove those from the cache when a clean operation occurs. |
We should test this scenario, unless we do it already. |
We actually have a test that runs I wonder what is the difference against running |
Maybe a Quarkus component is leaking file handles? I tried attaching https://file-leak-detector.kohsuke.org/ but the build died in some groovy related plugin and I haven't had time yet to investigate. Update: I've just tried |
I am also suspecting |
Well, this is what I just tried. We have > 100 modules but only in one single module (called |
A heapdump of the daemon JVM after the first build might help too. I assume there will be some instances of sun.misc.URLClassPath pointing at the locked files. One should check then how they are linked to GC roots. |
@ppalaga I'm investigating a fix, but do you recall why you added the following switch https://github.com/mvndaemon/mvnd/blob/master/daemon/src/main/java/org/jboss/fuse/mvnd/plugin/CliPluginRealmCache.java#L477-L479 ? |
FS watcher behaves differently on Mac compared to Linux and Windows #34 (comment) |
Yeah, the question was more if we could only keep the one based on the |
hello, I have the same issue on my project on Windows with First build :
Second build with same command without any changes :
When i execute :
The build is ok :
|
@fhassak Some of the Maven plugins you have in your build does not close filesystem resources properly. In the original report, the main suspect was |
Hi, On our projet, first build ok but next one fails on locked files. Also, when trying to mvnd clean or mvn clean or even trying manually, the target folder on some sub projects could not be deleted. Windows keeps complaining that I need administrator authorisation (which I do have). I will try finding which files are causing this using the file leak detector. |
no, i don't have quarkus on my project |
Beware that you'll need to build the detector yourself based on jenkinsci/lib-file-leak-detector#51 to get it working on JDK 10+. |
So in case of the problems building Quarkus (the main repo) it seems the
Or a bit different trace:
|
I think this is related to the Kotlin problem: https://youtrack.jetbrains.com/issue/KT-35394 |
Good work, @famod. It would be interesting to find out whether the Gradle workaround with "Disabling Kotlin compiler context reuse" could somehow also be made to work for Maven. It looks like the kolinc option is called |
Hm, I tried passing AFAICS, |
Oh, sorry, I probably misread something. How about this?
Based on https://kotlinlang.org/docs/reference/using-maven.html#specifying-compiler-options |
Already tried that but got: I think only the arguments from this class can be used (or a subclass of it): https://github.com/JetBrains/kotlin/blob/master/compiler/cli/cli-common/src/org/jetbrains/kotlin/cli/common/arguments/CommonCompilerArguments.kt |
Hm, this is interesting: But then again I'm asking myself whether just purging the cache is enough, better would be to |
Did you find a way to set the env variable @famod? I'm running into the same issue. Can you also confirm that this only happens, when building a maven multi module project? I tried building a single maven project which uses the kotlin maven plugin and that worked fine. However as soon as I build a multi module project the build modules artifacts remain locked by the kotlin maven plugin. |
I was taking a look at using mvnd in our multi-module java project but we seem to be running into the same issue: the first build passes successfully, but any subsequent "clean" builds fail. |
had the same issue with in my case this was caused by a |
IIRC, I built the detector from this branch: jenkinsci/lib-file-leak-detector#51 |
In Quarkus, first
mvnd -Dquickly
is ok, but any subsequent run yields:The text was updated successfully, but these errors were encountered: