[
https://issues.apache.org/jira/browse/IVY-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577178#action_12577178
]
Xavier Hanin commented on IVY-732:
----------------------------------
I've added new unit tests to try to reproduce your problem, but I didn't
succeed in reproducing the error. Could you have a look at what I've done, and
see if you have an idea of how to reproduce the problem with a unit test? The
most interesting added test is IvyInstallTest#testInstallDummyDefault. You can
view the change log introducing this test in the subversion commits attached to
this issue.
> install task dependent on defaultResolver instead of from attribute
> -------------------------------------------------------------------
>
> Key: IVY-732
> URL: https://issues.apache.org/jira/browse/IVY-732
> Project: Ivy
> Issue Type: Bug
> Reporter: Shawn Castrianni
> Fix For: 2.0
>
>
> I am using the install task to copy builds of my modules from one resolver to
> another, which is what it was designed to do. However, I have noticed that
> it appears to be dependent on the defaultResolver in the settings file. I
> think this is a bug since the install task takes as attributes the from and
> to resolver. The from resolver should be used to find the module instance to
> copy from (not the defaultResolver) and the to resolver should be used to
> locate the destination of where to copy the module instance to. Therefore,
> if I specify the revision of "latest.testing" in my install task and a from
> resolver of "testing", it should find the latest revision of my testing
> modules in the testing resolver. However, it is not finding the latest one.
> I changed my defaultResolver in my settings file to be "testing" and then it
> started to work properly. I changed it back and it failed again. That tells
> me that the install task is using the value of defaultResolver somehow. Am I
> understanding things correctly? By the way, if I change my revision spec in
> the install task to be a specific revision number in the "latest" resolver,
> it works fine. The bug is only when I use the latest.XXXX method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
