Dependency jar "part" extension is never renamed due to an internal exception

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use gradle 0.9.1 and ivysvn resolver in build.gradle against a subversion 
repository
2. During the build, a dependency jar is downloaded from the repository into 
gradle cache with a "part" extension.
3. The jar is never renamed due to an internal exception.

What is the expected output? 
Jar dependency successfully downloaded to cache.

What do you see instead?
Instead, the dependency is never renamed due to an internal error (i.e. 
.gradle\cache\axis\axis-1_3\jaxrpc\jars\jaxrpc.jar.part).

What version of the product are you using? On what operating system?
2.2.0

Please provide any additional information below.

This issue was touched on in https://issues.apache.org/jira/browse/IVY-615.
However, I've discovered that
org.gradle.api.internal.artifacts.ivyservice.DefaultSettingsConverter$ProgressLo
ggingTransferListener.transferProgress(TransferEvent evt) is throwing a 
NullPointerException for the case evt.getEventType() == 
TransferEvent.TRANSFER_COMPLETED. This appears to happen in 
fm.last.ivy.plugins.svnresolver.get(String source, File destination) where 
fireTransferInitiated(getResource(source), TransferEvent.REQUEST_GET) is 
invoked twice. 

However, there is no case in transferProgress() for event type of 
TransferEvent.TRANSFER_INITIATED. Because of this, the logger variable never 
gets populated in transferProgress() and is null when 
fm.last.ivy.plugins.svnresolver.get(String source, File destination) invokes 
fireTransferCompleted(destination.length()) before exiting. To address this, I 
changed the second invocation of fireTransferInitiated() to 
fireTransferStarted() so that the logger var would be populated and all is 
well. I'd like to know if there is some other problem I've missed here.

Original issue reported on code.google.com by bay...@tampabay.rr.com on 12 Jan 2011 at 3:47

[GoogleCodeExporter]

I've never had any problems with this so it sounds like you know more about it 
than I do. Can you please attach the output of this occurring when running ant 
with the -d flag so I can see the full stack trace and line numbers?

It also sounds like you might have coded up a fix for this, if that's the case 
could you please attach a patch file which I can review for inclusion in the 
main branch?

Original comment by massdosage on 12 Jan 2011 at 6:27

[GoogleCodeExporter]

Unfortunately, the -d flag produced very little information. I've attached a 
snippet of logging where I added code to catch and print the exception. The 
stacktrace should be of interest. I had to modify Ivy, Gradle, and IvySvn code 
in order to produce debug output. I've attached an additional log where I added 
debug info (**** notation). If you ignore the **** lines, that's close to the 
original error - as you can see, not much help. As for the patch, I simply 
changed the second invocation of fireTransferInitiated(getResource(source), 
TransferEvent.REQUEST_GET) to fireTransferStarted() in 
fm.last.ivy.plugins.svnresolver.get(String source, File destination). If you 
review that method, you will see what I'm referring to. I'm not sure if what I 
did is appropriate for release. The reasons behind invoking 
fireTransferInitiated() twice and then fireTransferCompleted() need to be 
reviewed as I'm not sure what the intent was in that area.

Original comment by bay...@tampabay.rr.com on 12 Jan 2011 at 7:34

Attachments:

• errorSnippet.txt
• errorSnippet2.txt