ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Matèrne (jhm) <>
Subject AW: Ivy-2.5.0
Date Tue, 09 Jan 2018 07:12:14 GMT
> 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?

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

> 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
  (could be 'inlined' in later Ivy version).

I followed the mail thread 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message