maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gili (JIRA)" <>
Subject [jira] [Commented] (MCLEAN-78) Ability to retry longer if clean fails
Date Tue, 22 Nov 2016 19:53:59 GMT


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:

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

> Ability to retry longer if clean fails
> --------------------------------------
>                 Key: MCLEAN-78
>                 URL:
>             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
> 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

View raw message