[
https://issues.apache.org/jira/browse/IVY-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885144#comment-17885144
]
Sodrul Bhuiyan edited comment on IVY-1485 at 9/27/24 1:46 AM:
--------------------------------------------------------------
I'm updating from 2.1.0-rc2 to 2.5.2 and getting this exact same issue. I'm
quite shocked to see that it's a 10 years old bug. The issue didn't exist in
2.1.0-rc2. For my scenario I have a *tests* configuration in my module A which
uses a transitive older version of the *aspectj* dependency but *ear*
configuration uses newer version of the same dependency as direct (not coming
from transitive) dependency. The module A seems to download the correct version
of the dependency in both ear and the tests configurations but when the
resolved ivy file is delivered it has the following information which is
incorrect. The ear configuration's direct dependency version is switched to
lower version which was coming from the transitive dependency of the cactus
module of the tests configuration.
<dependency org="eclipse" name="aspectj" rev="{*}1.2.1{*}"
revConstraint="{*}1.8.13{*}" conf="ear->runtime"/>
<dependency org="apache" name="cactus" rev="1.7.2" conf="{*}tests{*}->default">
<exclude conf="tests" module="junit"/>
</dependency>
This becomes an issue when my module A is being used by some other module,
while that module goes through resolve, it uses version 1.2.1 in the ear
configuration which is incorrect.
If we compare with Maven then all configuration (scope) would be using latest
version of the dependency but in my case the opposite is happening.
What are you all doing to bypass this issue? I saw one suggestion saying using
Gradle instead.
was (Author: JIRAUSER303553):
I'm updating from 2.1.0-rc2 to 2.5.2 and getting this exact same issue. I'm
quite shocked to see that it's a 10 years old bug. The issue didn't exist in
2.1.0-rc2. For my scenario I have a *tests* configuration in my module A which
uses a transitive older version of the *aspectj* dependency but *ear*
configuration uses newer version of the same dependency as direct (not coming
from transitive) dependency. The module A seems to download the correct version
of the dependency in both ear and the tests configurations but when the
resolved ivy file is delivered it has the following information which is
incorrect. The ear configuration's direct dependency version is switched to
lower version which was coming from the transitive dependency of the cactus
module of the tests configuration.
<dependency org="eclipse" name="aspectj" rev="{*}1.2.1{*}"
revConstraint="{*}1.8.13{*}" conf="ear->runtime"/>
<dependency org="apache" name="cactus" rev="1.7.2" conf="{*}tests{*}->default">
<exclude conf="tests" module="junit"/>
</dependency>
This becomes an issue when my module A is being used by some other module,
while that module goes throw resolve it uses version 1.2.1 in the ear
configuration which is incorrect.
If we compare with Maven then all configuration (scope) would be using latest
version of the dependency but in my case the opposite is happening.
What are you all doing to bypass this issue? I saw one suggestion saying using
Gradle instead.
> 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)
