You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Koen Aalders (Jira)" <ji...@apache.org> on 2021/06/06 13:43:00 UTC

[jira] [Commented] (MSHARED-882) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

    [ https://issues.apache.org/jira/browse/MSHARED-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17358113#comment-17358113 ] 

Koen Aalders commented on MSHARED-882:
--------------------------------------

First of all please label the item correctly. This item is related to the release plugin. Its not located in the maven repo, instead its located in https://gitbox.apache.org/repos/asf/maven-release.git.

 

Running the checkout version of the release plugin (git clone --branch maven-release-3.0.0-M4 https://gitbox.apache.org/repos/asf/maven-release.git) works correctly, but NOT with the dependency:

<dependency>
 <groupId>org.codehaus.plexus</groupId>
 <artifactId>plexus-utils</artifactId>
 <version>3.3.0</version>
</dependency>

 

 

 

The bug itself comes from an filehandler that isnt closed (\maven-release\maven-release-manager\src\test\java\org\apache\maven\shared\release\phase\AbstractBackupPomsPhaseTest.java):

Note the xmlReader :)

 

private MavenProject createMavenProject( File pomFile )
 throws Exception
{
 MavenXpp3Reader reader = new MavenXpp3Reader();

 Reader xmlReader = ReaderFactory.newXmlReader( pomFile );
 Model model = reader.read(xmlReader);

 MavenProject project = new MavenProject( model );

 project.setFile( pomFile );
 xmlReader.close();
 return project;
}

 

 

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> -------------------------------------------------------------------
>
>                 Key: MSHARED-882
>                 URL: https://issues.apache.org/jira/browse/MSHARED-882
>             Project: Maven Shared Components
>          Issue Type: Bug
>          Components: maven-shared-utils
>         Environment: Windows
>            Reporter: Elliotte Rusty Harold
>            Priority: Major
>              Labels: up-for-grabs
>
> This bug is shared (likely because of code copied from one place to another) between the similar methods in 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 system 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.
> Some history is here where I noticed it:
> https://github.com/apache/maven-release/pull/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.
> Also see https://issues.apache.org/jira/browse/IO-663?filter=-2



--
This message was sent by Atlassian Jira
(v8.3.4#803005)