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 08:44:52 GMT
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

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