Re: Ivy-2.5.0

[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 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 

Re: Ivy-2.5.0

[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 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

Re: Ivy-2.5.0

[Maarten Coene]

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 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

   

Re: Ivy-2.5.0

[Gintautas Grigelionis]

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 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