ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject IVY-1485, resolve report and resolved versions
Date Fri, 26 May 2017 08:50:19 GMT
After some digging, I found out that the resolved revisions property file is very old (git
is awesome, even better within sourcetree). It is so old that at that time the xml resolve
report didn’t exist. And this property file seems to have been created just in order to
make the deliver task work [1]. And a comment still state this too [2]. And the purpose of
the lines from 248 to 326 are about to compute these versions and write them down, it can
be extracted in a function without side effect.

So most probably this property file is redundant with the xml resolve report. But the thing
is the resolve may not be produced, it is an option [3], defaulting to true [4].

Two options:
- continue to support the property file and correctly produce it to fix IVY-1485 [5].
- drop this property file, make the xml report always produced, and make the deliver read
the report rather than the property file.

Makes sense ?


[1] <>
[5] <>
> Le 25 mai 2017 à 12:11, Nicolas Lalevée <> a écrit
> Thank you very much Jaikiran for your detailed explanation.
> I have to admit that I don’t know the answer to which is the source of truth about
the resolution report. I have also wondered why the resolve report should have to be always
wrote and then read from file. I’ll try to get an answer myself too while reading the code.
> Nicolas
>> Le 22 mai 2017 à 07:37, J Pai <> a écrit :
>> One other thing about this issue - this is reproducible (as shown in the test case)
with static revisions too and isn’t specific to any dynamic revision resolution.
>> -Jaikiran
>> On 22-May-2017, at 11:02 AM, J Pai <> wrote:
>> 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
>> 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]
>> [2]
>> -Jaikiran
>> On 21-May-2017, at 10:49 PM, Nicolas Lalevée <>
>> One thing though.
>> This revival of the community has been triggered by the comments on this issue:
>> <>
>> 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 <>
a écrit :
>>>> Le 21 mai 2017 à 16:28, J Pai <> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message