You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This method worked in 3.1.0 and fails in 3.3.0 as I found by trying to upgrade maven-release from 3.10 to 3.3.0
This bug is shared (likely because of code copied from one place to another) between the similar methods in Apache commons IO, codehaus-plexus-utils, and maven-shared-utils.
I don't have an isolated test case because this bug is platform specific and I've only seen it in Travis CI builds on Windows using JDK 7 through 15. I don't have a Windows box handy to test it. However it is reproducible.
Typical code that triggers it is in RestoreBackupPomsPhaseTest in maven-release:
// copy poms so tests are valid without clean
File sourceDir = getTestFile( "src/test/resources" + projectPath );
File testDir = getTestFile( "target/test-classes" + projectPath );
FileUtils.copyDirectoryStructure( sourceDir, testDir );
I don't know whether there might be something weird in the setup of those two directories that's involved.
Typical error message is:
Caused by: java.nio.file.FileSystemException:
F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml: The process cannot access the file because it is being used by another process
"The process cannot access the file because it is being used by another process" I think points to the root of the bug. This is a Windows file system error message.
In this case, I started with plexus-utils 3.1.0 which worked, upgraded t plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory from both maven-shared-utils and commons-io, all of which failed in the same way.
I think this is caused by the use of NIO, which doesn't work quite the same when copying files on Windows as on Linux and Mac OS X.
It probably is, though the way it manifests in the Maven test suite has been worked around. It seems to happen when a file is left open, possibly in the source directory. When the test was updated to properly close the file, the problem disappeared. So arguably it is a bug in client code and yet:
Only on Windows. Linux can copy open files just fine.
Non-NIO based solutions were more robust against open files.
This method worked in 3.1.0 and fails in 3.3.0 as I found by trying to upgrade maven-release from 3.10 to 3.3.0
This bug is shared (likely because of code copied from one place to another) between the similar methods in Apache commons IO, codehaus-plexus-utils, and maven-shared-utils.
I don't have an isolated test case because this bug is platform specific and I've only seen it in Travis CI builds on Windows using JDK 7 through 15. I don't have a Windows box handy to test it. However it is reproducible.
Typical code that triggers it is in RestoreBackupPomsPhaseTest in maven-release:
I don't know whether there might be something weird in the setup of those two directories that's involved.
Typical error message is:
Caused by: java.nio.file.FileSystemException:
F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml: The process cannot access the file because it is being used by another process
"The process cannot access the file because it is being used by another process" I think points to the root of the bug. This is a Windows file system error message.
Some history is here where I noticed it:
apache/maven-release#42
In this case, I started with plexus-utils 3.1.0 which worked, upgraded t plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory from both maven-shared-utils and commons-io, all of which failed in the same way.
I think this is caused by the use of NIO, which doesn't work quite the same when copying files on Windows as on Linux and Mac OS X.
see https://issues.apache.org/jira/browse/IO-663 and https://issues.apache.org/jira/browse/MSHARED-882
The text was updated successfully, but these errors were encountered: