[GRADLE-2499] Cannot copy archives in compareGradleBuilds Created: 26/Sep/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.2
Fix Version/s: None

Type: Bug
Reporter: Björn Kautler Assignee: Unassigned
Resolution: Won't Fix Votes: 0


 Description   

I added some Jar tasks as artifacts to the archives configuration and run a compareGradleBuilds to see the difference between building with 1.0 and 1.2.

Unfortunately after the targetBuild was run, I got the following error:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compareGradleBuilds'.
> Failed to move file 'censored\qs\build\libs\qs-shared-5.0.RC0.jar' into filestore at 'censored\master\tmp-filestorage-compareGradleBuilds-1348658101088\target\_qs_sharedJar\qs_shared_5.0.RC0.jar'

[...]

Caused by: java.io.IOException: Failed to delete original file 'censored\qs\build\libs\qs-shared-5.0.RC0.jar' after copy to 'censored\master\tmp-filestorage-compareGradleBuilds-1348658101088\target\_qs_sharedJar\qs_shared_5.0.RC0.jar'
        at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:1821)
        at org.gradle.api.internal.filestore.PathKeyFileStore.saveIntoFileStore(PathKeyFileStore.java:103)
        ... 80 more

Though it says "after copy to", the file 'master\tmp-filestorage-compareGradleBuilds-1348658101088\target_qs_sharedJar\qs_shared_5.0.RC0.jar' is not present.

 Comments   
Comment by Björn Kautler [ 26/Sep/12 ]

debug logging also doesn't add more information

Comment by Peter Niederwieser [ 16/Oct/12 ]

Could be a file locking problem, especially since it occurs on Windows. FileUtils deletes the target file if the source file can't be removed. That's why you don't see the target file.

Comment by Björn Kautler [ 30/Nov/12 ]

Hm, maybe the "improved cleaning strategy for windows" introduced at http://issues.gradle.org/browse/GRADLE-2244 should also be used for this feature.
Maybe that would improve the situation?

Comment by Björn Kautler [ 21/Apr/14 ]

Actually it wouldn't have improved the situation in my particular case.
After a long time I now finally got the time to upgrade our Gradle from 1.0 to 1.11, so I tried to get the buildcomparsion running again and had the same problem.
Well, the "improved cleaning strategy for windows" would not help in this case, because the JAR file reference was not held by the host build JVM, but by the target build Daemon JVM.
And there it also was not a hanging phantom reference, but the JAR was in the classpath of an AntBuilder, from a taskdef call where some of our JARs were added for the wsimport task to be able to compile the generated files.
As a fix for me, I configured the wsimport task to only generate but not compile the classes and thus it didn't need our JARs with the custom classes.
But I guess it cannot be guaranteed that the target- or source-build-daemon still has file references open to the produced JARs.
So maybe between running one of the builds and moving away the built artifacts, the Daemon should be stopped maybe?

And probably the "improved cleaning strategy for windows" would still make sense to be implemented here?

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:23:37 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.