ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaikiran Pai <>
Subject Re: Ivy-2.5.0
Date Tue, 09 Jan 2018 13:53:08 GMT
Thanks Maarten, I'll look this.


On 09/01/18 5:53 PM, Maarten Coene wrote:
> The change to the URLHandler class (TimoutConstraint) is also backwards incompatible.The
IvyIdea plugin (IntelliJ) breaks on this which contains an extension of AbstractURLHandler.
> I didn't look into it yet, maybe it can be changed to be more backwards compatible?
> kind regards,Maarten
>        Van: Gintautas Grigelionis <>
>   Aan: Ant Developers List <>
>   Verzonden: dinsdag 9 januari 9:45 2018
>   Onderwerp: Re: Ivy-2.5.0
> 2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <>:
>>> What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
>>> PR-55/PR-60)? If you fine with merging (eventually adjusting the
>>> contents of SVG), let's do it.
>> I added a comment on the PR.
>> For short:
>> - license header is missed on two files
>> - improve two JavaDocs
>> - test: does the fresh built Ivy use the SVG graphics?
> I hope I addressed all points now.
>>> Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
>>> evaluated by reporters, but nobody responded because the issues are so
>>> old.
>>> I would rather close the issues and a open a new issue if needed. I
>> No. It's just a matter of prioritization by us.
>>> added test cases for every issue highlighting the specific parts of the
>>> problem and I can write up separately on the design problem with
>>> permitting the same attributes on different elements with recursive
>>> inheritance or using the same attribute name with different semantics
>>> depending on the element (perhaps in Confluence? or Github wiki?).
>> Can't understand the problem (haven't that knowledge of Ivy).
>> IVY-1315 "is related to" IVY-1420, which is resolved.
>> Is IVY-1315 also resolved? Then just close that issue.
> The problem is that the same set of attributes is allowed on both
> configurations and dependencies. However, it is the attrubte values for
> last element (dependencies) that are definitive -- unless they're absent.
> Both configurations and dependencies can be inherited ("extended"); on top
> of that, configurations allow for includes, which I guess predates
> extension, and includes can have the attributes, too.
> So the problem is: while ivy.xml is updated, the values of attributes may
> change. Because ivy.xml is written in chunks, configurations (processed
> early) may end up with different attribute values than dependencies (which
> are definitive). That makes no difference when processed ivy.xml is
> resolved, but might mess up subsequent extends.
> Because the whole mechanism is underspecified, I tend to leave it as is
> (put the final values of attributes on dependencies) rather than cache
> configurations and publications until attributes on dependencies are
> processed in order to guarantee that attributes have identical values for
> both configurations and dependencies (or that configurations get the final
> values if no attributes were present on dependencies).
> I will close all issues pertaining to the attributes. When we agree on
> specification, we can open a new one if needed.
>>> My opinion on PR-57 is that it addresses another design problem in a
>>> similarly good-enough fashion. We can handle this like Ant and have a
>>> Java
>>> 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
>>> The question is, whether that makes 2.5.x more interesting and is worth
>>> the extra work?
>> I wouldn't create an extra branch just for that.
>> I am more a fan of moving to a newer Java version after that release.
>> I recap the PR-57:
>> - multiple changes array->collection
>> - all are fine expect one
>> - one central public interface added one new method
>>    -- no changes in semantics, but only in method declaration
>> (array->collection, generics)
>>    -- technically one new method and deprecating the old
>> - this means breaking backwards compatibility
>> - proposal is adding a 2nd interface extending the original interface and
>> adding that new method
>>    (could be 'inlined' in later Ivy version).
>> I followed the mail thread
>> and found another problem
>> - ModuleRules breaks BWC due the same reason (as you pointed it out).
>> Maybe we should not include this PR into an Ivy-2.5.0 release but instead
>> move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
>> backwards incompatible way.
> PR-57 is narrowed down specificaly to the method addition in
> DependencyResolver. That affects every resolver implementation; however, a
> default method implementation is provided in AbstractResolver and all known
> third party implementations use it.
> We can kick the can down the road, but the important point is that Java
> permits no arrays of generics and we must fix that.
> Gintas

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message