[
https://issues.apache.org/jira/browse/IVY-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887618#comment-17887618
]
Jaikiran Pai commented on IVY-1485:
-----------------------------------
> [~jaikiran] I couldn't view the link, says I don't have permission to view.
Looks like there was an additional period at the end of that link which was
causing an issue. I've updated that link in my previous comment and you should
be able to view it. That link points to the mailing list discussion where it
has been noted that development of Ivy project has practically stalled and we
are considering retiring it.
> Incorrect revision of dependencies put in to delivered Ivy files
> ----------------------------------------------------------------
>
> Key: IVY-1485
> URL: https://issues.apache.org/jira/browse/IVY-1485
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.3.0, 2.4.0-RC1
> Reporter: Perrin Morrow
> Priority: Critical
> Attachments: 0001-Add-test-cases-for-IVY-1485.patch,
> 0002-Ensure-dependency-is-applicable-to-all-confs-of-matc.patch,
> ivy-1485-test-cases.patch
>
>
> Ivy deliver incorrectly replaces top-level dependency revision with one from
> a transitive dependency in a different conf.
> When writing the resolved Ivy properties into the cache, the Ivy
> ResolveEngine does not take into account the top-level confs. If it finds the
> same dependency on any transitive path it will prefer the resolved revision
> of the transitive dependency over that of the top-level dependency even when
> that transitive dependency is being resolved into a completely different
> top-level conf. This results in a delivered Ivy file, that when resolved
> again will pull in the wrong version of that top-level dependency.
> Consider the following Ivy dependency chain:
> {noformat}
> top-level
> [conf1]
> - modA#1
> [conf2]
> - modB#1
> - modA#2
> {noformat}
> Ivy resolve and retrieve will pull modA#1 into conf1 and modA#2 into conf2,
> as expected.
> Ivy deliver, however, will replace modA#1 with modA#2 in the delivered ivy
> descriptor. When that delivered ivy file is resolved again (by some other
> module depending on it) it will pull in modA#2 into both conf1 and conf2.
> This appears to be a regression in Ivy 2.3.0. It did not happen with Ivy
> 2.2.0. (Maybe related to IVY-1300?)
> We have written some test cases that demonstrate the problem (a diff against
> the Git repository master) which I will attach.
> We're also working on a patch to fix this but so far it has proved elusive.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
