[ 
https://jira.codehaus.org/browse/MDEP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated MDEP-442:
--------------------------------

    Description: 
My multi-module POM contains of ten modules. Each of that modules does the 
same: Invoke the 'copy' goal of the dependency plugin. The idea is to have ten 
copies of the identical source, which then will end up in ten different targets 
by getting furthere processed.

As long as I do not use more than one Maven worker thread, everything works 
well always. But when using -T 5 to have five worker threads, rather often the 
reactor fails because the source file (!) is locked:
{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (copy) on project 
MYARTIFACT: Unable to resolve artifact. Could not transfer artifact 
mygroup:myartifact:dll:4.36.1-20140415.143537-37 from/to nexus 
(http://nexus/nexus/content/groups/public): 
C:\Users\jenkins.QUIPSY\.m2\repository\mygroup\myartifact\4.36.1-SNAPSHOT\myartifact-4.36.1-20140415.143537-37.dll
 (The process cannot access the file, because it is in use by another process)
{noformat}
So it seems that the 'copy' task actually is locking the source file, which is 
not multi-threading-compatible. Hence, either that is a bug and should get 
fixed, or it is on purpose, then this goal has to be marked as 
non-multithreading-able.

  was:
My multi-module POM contains of ten modules. Each of that modules does the 
same: Invoke the 'copy' goal of the dependency plugin. The idea is to have ten 
copies of the identical source, which then will end up in ten different targets 
by getting furthere processed.

As long as I do not use more than one Maven worker thread, everything works 
well always. But when using -T 5 to have five worker threads, rather often the 
reactor fails because the source file (!) is locked:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (copy) on project 
MYARTIFACT: Unable to resolve artifact. Could not transfer artifact 
mygroup:myartifact:dll:4.36.1-20140415.143537-37 from/to nexus 
(http://nexus/nexus/content/groups/public): 
C:\Users\jenkins.QUIPSY\.m2\repository\mygroup\myartifact\4.36.1-SNAPSHOT\myartifact-4.36.1-20140415.143537-37.dll
 (The process cannot access the file, because it is in use by another process)

So it seems that the 'copy' task actually is locking the source file, which is 
not multi-threading-compatible. Hence, either that is a bug and should get 
fixed, or it is on purpose, then this goal has to be marked as 
non-multithreading-able.


> Failed to access file due to locked access when using more than one Maven 
> worker thread
> ---------------------------------------------------------------------------------------
>
>                 Key: MDEP-442
>                 URL: https://jira.codehaus.org/browse/MDEP-442
>             Project: Maven Dependency Plugin
>          Issue Type: Bug
>          Components: copy
>    Affects Versions: 2.8
>         Environment: MVN 3.0.4, JDK 1.7, Win 7 Pro SP1 64 Bit
>            Reporter: Markus KARG
>            Priority: Critical
>
> My multi-module POM contains of ten modules. Each of that modules does the 
> same: Invoke the 'copy' goal of the dependency plugin. The idea is to have 
> ten copies of the identical source, which then will end up in ten different 
> targets by getting furthere processed.
> As long as I do not use more than one Maven worker thread, everything works 
> well always. But when using -T 5 to have five worker threads, rather often 
> the reactor fails because the source file (!) is locked:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (copy) on project 
> MYARTIFACT: Unable to resolve artifact. Could not transfer artifact 
> mygroup:myartifact:dll:4.36.1-20140415.143537-37 from/to nexus 
> (http://nexus/nexus/content/groups/public): 
> C:\Users\jenkins.QUIPSY\.m2\repository\mygroup\myartifact\4.36.1-SNAPSHOT\myartifact-4.36.1-20140415.143537-37.dll
>  (The process cannot access the file, because it is in use by another process)
> {noformat}
> So it seems that the 'copy' task actually is locking the source file, which 
> is not multi-threading-compatible. Hence, either that is a bug and should get 
> fixed, or it is on purpose, then this goal has to be marked as 
> non-multithreading-able.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

Reply via email to