ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Schlegel (JIRA)" <>
Subject [jira] [Commented] (IVY-1485) Incorrect revision of dependencies put in to delivered Ivy files
Date Mon, 24 Apr 2017 15:23:04 GMT


Markus Schlegel commented on IVY-1485:

I gave up with IVY since there is no maintenance anymore and the bugs are too restricting.
Actually, we need to still use it, but we have planned to replace it with gradle (but that
requires a huge change in our build chain). First prototype tests showed that the resolution
of the dependencies works as expected with gradle. Hope this helps others finding a decision.

> Incorrect revision of dependencies put in to delivered Ivy files
> ----------------------------------------------------------------
>                 Key: IVY-1485
>                 URL:
>             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 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

View raw message