Maarten, I just pushed a change to Ivy upstream to not force existing
implementations of this URLHandler to understand timeout constraints and
yet have the feature available for other implementations. When you get a
chance, can you please try the IvyIdea plugin build/test with the latest
Ivy and see if it solves the issue?
-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
