ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <>
Subject Re: Ivy-2.5.0
Date Sat, 03 Feb 2018 13:54:31 GMT
Interesting, japicmp does not mark URLHandler as backwards incompatible,
even though it has a bunch of new methods :-S

On the other hand, IvyDEA has some old components: Commons VFS 1.0, JSch
0.1.31... BTW, JSch is a part of IntelliJ distribution?


2018-01-09 15:40 GMT+01:00 Gintautas Grigelionis <>:

> You can use PR-61 for that 😉
> Gintas
> Den 9 jan. 2018 14:53 skrev "Jaikiran Pai" <>:
> Thanks Maarten, I'll look this.
> -Jaikiran
> 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:

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