ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <g.grigelio...@gmail.com>
Subject Re: Ivy-2.5.0
Date Tue, 09 Jan 2018 14:40:19 GMT
You can use PR-61 for that 😉

Gintas

Den 9 jan. 2018 14:53 skrev "Jaikiran Pai" <jai.forums2013@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.grigelionis@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) <apache@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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

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