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?
Gintas
2018-01-09 15:40 GMT+01:00 Gintautas Grigelionis <g.grigelio...@gmail.com>:
> You can use PR-61 for that 😉
>
> Gintas
>
>
> Den 9 jan. 2018 14:53 skrev "Jaikiran Pai" <jai.forums2...@gmail.com>:
>
> 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 <g.grigelio...@gmail.com>
>> Aan: Ant Developers List <dev@ant.apache.org>
>> 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) <apa...@materne.de>:
>>
>> 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 https://www.mail-archive.com/
>>> dev@ant.apache.org/msg46002.html 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: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
>
