ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <>
Subject Re: Ivy - PR-57 need inputs
Date Sat, 29 Jul 2017 21:26:26 GMT
Having mistaken binary compatibility for backwards compatibility, I tried
to look at the ecosystem. Sure enough, there is a bunch of custom resolvers
around, but most extend at least RepositoryResolver; here's a list of those
that do it (might be useful for Ivy documentation as well)

There are others that extend URLResover or IBiblioResolver; only SBT
appears to dig deeper, but apparently only because of the lack of proper
typing. In a nutshell, the mitigation I proposed looks adequate (the check
in ChainResolver looks like almost an overkill).


2017-07-28 21:26 GMT+02:00 Gintautas Grigelionis <>:

> 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 <>:
>> 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:
>> For additional commands, e-mail:

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