[
https://issues.apache.org/jira/browse/MCLEAN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15687712#comment-15687712
]
Gili commented on MCLEAN-78:
----------------------------
When I run:
{{mvn --batch-mode -V -U -e clean install release:prepare release:perform
-Pwindows-i386 -Dsurefire.useFile=false -DreleaseVersion=3.7.0-b1
-DdevelopmentVersion=3.7.0-b2-SNAPSHOT -DdryRun=true}} the "clean install"
phases pass fine. "release:prepare" invokes:
{{cmd.exe /X /C ""C:\Program Files\apache-maven-3.3.9\bin\..\bin\mvn" -s
C:\Users\Gili\AppData\Local\Temp\release-settings8305726027763569172.xml clean
verify --no-plugin-updates --batch-mode -Psonatype-oss-release -P
always-active,windows-i386"}}
And this fails with:
{code}
Failed to execute goal org.apache.maven.plugins:maven-clean-plugin:3.0.0:clean
(default-clean) on project cmake-binaries-plugin: Failed to clean project:
Failed to delete C:\Users\Gili\Documents\cmake-maven-project-github -
Copy\cmake-binaries-plugin\target\cmake-binaries-plugin-3.7.0-b1-SNAPSHOT.jar
-> [Help 1]
{code}
> Ability to retry longer if clean fails
> --------------------------------------
>
> Key: MCLEAN-78
> URL: https://issues.apache.org/jira/browse/MCLEAN-78
> Project: Maven Clean Plugin
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Environment: Windows 10, 64-bit, build 10.0.14393
> Reporter: Gili
>
> Following up on MCLEAN-45, I am running into a problem where a build fails to
> clean 100% of the time. The existing retry mechanism sleeps roughly 1 second,
> which makes it impossible to investigate what is actually holding the lock. I
> already went through the obvious culprits by disabling Windows Indexing and
> anti-virus, to no avail. I can reproduce the problem on two separate machines
> as well. I am afraid that Maven itself might be holding the lock.
> I order to aid troubleshooting of this scenario, can you please add or
> enhance the existing configuration options so that the clean plugin can retry
> longer (e.g. up to 30 seconds)?
> Worse-case scenario, the lock will eventually get released and my build will
> work. Best-case scenario, the lock won't get released but I will finally have
> enough time to run SysInternals ProcessMonitor to figure out who is holding
> the lock. When I try doing this after the JVM shuts down, I don't find anyone
> holding the lock so I strongly suspect the JVM itself is at fault.
> Proposal: let users specify a max retry time and generate the intermediate
> sleep intervals on their behalf. I would happily use retry intervals of up to
> a minute if it meant that my automated builds would be more stable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
