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 - PR-57 need inputs
Date Fri, 28 Jul 2017 19:26:49 GMT
Sorry all, I misunderstood the problem, and thanks to Jaikiran and Stefan
for the discussion.

Third party implementations will be broken because they lack the method
with the new signature unless they extend the AbstractResolver. And the
AbstractResolver must work the other way around, provide a default
implementation that defines the method with new signature in terms of the
method with the old signature. The SearchEngine should work, though,
because the loops are refactored so that they take whatever iterable is
thrown at them. And AFAICS there are no other uses of listTokenValues()
implemented by resolvers (which are possible extensions of Ivy).

Gintas

2017-07-28 18:55 GMT+02:00 Stefan Bodewig <bodewig@apache.org>:

> On 2017-07-28, Jaikiran Pai wrote:
>
> > Ivy has a DependencyResolver interface which is the central piece of
> > contract/interface for extending Ivy (any external usage for that
> > matter).
>
> I'm not at all familiar with Ivy and the eco system that might exist
> around it. How likely is it that anybody has implemented this interface
> in a an extension? And how likely does such an extension not subclass
> AbstractResolver?
>
> Adding methods to an interface usually means a backwards incompatible
> change that requires a new major version when using semantic versioning
> (not sure whether Ivy uses semver, Ant itself doesn't).
>
> > Instead, what I think we could do is add that method to the
> > implementing class(es) internally (like the AbstractResolver - the PR
> > does that already). Of course at some places within our code, if we
> > want to use the newer generics based method, we will probably end up
> > doing a type check on the resolver instance to see if it's a
> > AbstractResolver which has that new method, but I think that should be
> > fine for now.
>
> Alternatively add a new interface with that method that extends
> DependencyResolver and is implemented by AbstractResolver and check for
> the new interface rather than AbstractResolver?
>
> Stefan
>
> ---------------------------------------------------------------------
> 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