[GRADLE-1109] Dependencies within multiple configurations, containing classifiers, fail to resolve and fail to show an error when attempting to copy the files Created: 11/Aug/10 Updated: 04/Jan/13 Resolved: 08/Sep/11
|Reporter:||Russ Rollins||Assignee:||Daz DeBoer|
This problem didn't occur in 0.9-preview-3 but is present in 0.9-rc1. The problem is trying to copy dependencies that have multiple configurations. My specific example has a classifier and was a zip file but I've also reproduced it with jars. The file wouldn't copy but the task finished without error. However, closer examination of the debugging log indicated that it couldn't resolve the file. I'm attaching a testcase that illustrates the issue (task is copyFail).
Note that in the log below the filename doesn't include the classifier and thus doesn't properly resolve (which is obvious when looking at the log, but again, it doesn't indicate to the end user that there was an error in retrieving the file):
|Comment by Hans Dockter [ 15/Aug/10 ]|
I can reproduce this problem. The following snippet exposes this as well:
The show task will show the correct transitive dependencies but does not resolve the actual testng artifact for the deptester configuration. If you choose a different testng version in deptester (e.g. 5.7) everything works as expected. As soon as I have time (I'm on holidays right now) I will look into this.
An ugly workaround that might work for you is:
This only copies the artifacts of the dependencies you have declared into the temp directory. Transitive dependencies are ignored. The from is only executed at execution time to avoid unnecessary resolving (e.g. when doing a clean). Even resolving from cache takes some time with Ivy (0.x secs). Having configuration statement in actions is something we usually try to avoid. It hides configurations information from other task that might be interested in that information at configuration time.
|Comment by Luke Daley [ 30/Aug/11 ]|
Daz, assigning to you in case this relates to the classifier work you are doing. If not, just unassign it again.