I have had a look at that issue, this last week and I have been able to
reproduce it in a simple test case[1]. I kind of understand what the issue is
in there, but given my lack of knowledge of the Ivy codebase, I haven’t been
able to figure how to fix this correctly. In fact, this issue is what prompted
me to ask this question [2] in the dev list a day or so back, since basically
comes down to those files. Here’s my understanding of the problem (backed by
that test case[1] which reproduces it).
Imagine you have a module org:hello-world and imagine it has 2 configurations
conf1 and conf2. Now consider the case where this hello-world module depends on
org:module1:1.0 in conf1 (a direct dependency) and on org:module2:1.0 in conf2
(a direct dependency). That translates to a module descriptor like:
<ivy-module version="2.0">
<info organisation="org"
module="hello-world"
revision="1.2.3"
/>
<configurations>
<conf name="conf1"/>
<conf name="conf2"/>
</configurations>
<dependencies>
<dependency org="org" name="module1" rev="1.0" conf="conf1->default"/>
<dependency org="org" name="module2" rev="1.0" conf="conf2->default"/>
</dependencies>
</ivy-module>
Now take this one step further and consider that org:module2:1.0 (that
hello-world depends on, in conf2) has a dependency of its own on
org:module1:2.0. So module2’s module descriptor looks like:
<ivy-module version="1.0">
<info organisation="org"
module="module2"
revision="1.0"
/>
<publications>
<artifact/>
</publications>
<dependencies>
<dependency org="org" name="module1" rev="2.0"/>
</dependencies>
</ivy-module>
So ultimately, when you resolve the hello-world module, you expect it to have
org:module1:1.0 as an dependency in conf1 and org:module1:2.0 as an dependency
in conf2 (transitively via org:module2:1.0).
Does the resolve work as expected for this use case? Yes it does and the
resolution pulls in the right set of dependencies in the right configurations.
Internally it creates resolution report (as an xml) plus a resolution
properties file for this resolution. No (obvious/apparent) issues at this
point.
Now, let’s say a “deliver” is triggered against this resolution, for conf1.
What I would expect is, that it would deliver a file for hello-world which then
has a dependency on org:module1:1.0 in conf1 (because that’s what it was
correctly resolved to previously). However, the delivered file instead has a
dependency on org:module1:2.0 in conf1 and I believe that’s the issue being
reported in that JIRA.
So is this a bug in the deliver task itself? I don’t think so. So far what I
have narrowed it down to is that the resolve task that happened previously
creates more than one representation of that resolution (one a resolution
report xml and one a resolution properties file). The resolution report XML has
all the necessary and correct information about which dependency (either direct
or transitive) belongs to which configuration. However, the resolution
properties file contains the “wrong” dependency for module1 - it stores the
dependency as org:module1:2.0. I am not even sure if the properties file is
capable enough of supporting/understanding dependencies per configuration. The
deliver task then uses this properties file (instead of the resolution report
XML) to decide what dependencies to write out. I’m guessing some other
(post-resolve) tasks too use this properties file for their decision making, so
this really boils down to a potential bug in what gets written out to this
resolution properties file, during resolve.
Unfortunately, my reading of the code so far hasn’t given me answers on what
role this file plays and why can’t it be just skipped and the resolution report
XML instead be considered the single source of truth. Hence that question [2]
in the dev list. I can’t really think of a solution/fix for this issue, without
reading more of the current Ivy code to understand what role these files play.
[1]
https://github.com/jaikiran/ant-ivy/commit/529a3fa05ed5dd115bdf8046d0cf0ffe034905e0#diff-6ed8218b6bb9460014cf3558ff227172R571
[2] https://www.mail-archive.com/dev@ant.apache.org/msg45402.html
-Jaikiran
On 21-May-2017, at 10:49 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:
One thing though.
This revival of the community has been triggered by the comments on this issue:
https://issues.apache.org/jira/browse/IVY-1485
<https://issues.apache.org/jira/browse/IVY-1485>
It would be a shame if it is not fixed within the next release.
The issue and the fix are not easy to understand. Any review will be welcomed.
Nicolas
> Le 21 mai 2017 à 18:46, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit :
>
>
>> Le 21 mai 2017 à 16:28, J Pai <jai.forums2...@gmail.com> a écrit :
>>
>> The past few days I’ve sent some PRs for bug fixes and some enhancements in
>> preparation for the proposed release of Ivy. Thanks Nicolas for reviewing
>> them and merging those that were good enough.
>>
>> I’ve been using this JIRA filter [1] to narrow down on the issues to look
>> into. That filter essentially is of “open issues that affect 2.1.0, 2.2.0,
>> 2.3.0 or 2.4.0 and have been updated/created since Jan 1st 2014”. So it
>> should cover most of the issues that we probably should look into (doesn’t
>> necessarily mean fix all of them, but just to check if any of them are big
>> enough to focus on).
>>
>> I’ve also sent one PR for upgrading our internal library dependencies and
>> plan to send a couple more for similar upgrades. My intention is to use the
>> latest released versions of these dependencies instead of sticking with
>> dependencies that are years old. My intention _isn’t_ to upgrade to a
>> version that isn’t API backward compatible, so these upgrades are mostly bug
>> fixes and should be “drop-in upgrades”.
>>
>> I would be really glad to hear any thoughts about these changes or any
>> other/different plans, that can get us to a releasable state in the near
>> future, especially from members/users who have been involved with Ant/Ivy
>> project in the past or present. Ultimately, I think if we can agree on a
>> goal for the upcoming release, it will help release something that will set
>> the right expectation with the end users when it comes to using it. My
>> opinion is that we consider this release to push out some bug fixes and
>> internal upgrades and _not_ introduce any major features unless those are
>> reasonably quick to implement. Once this release is done and (hopefully some
>> of the) community gets back behind the Ivy project, we can always introduce
>> major features in subsequent releases.
>
> Sounds like a good plan.
>
> Nicolas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
