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
