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

https://github.com/fdrueke/ivyp4
https://github.com/massdosage/ivysvn
https://github.com/ohnosequences/ivy-s3-resolver
https://github.com/rajeshja/atg-ivy-resolver
https://github.com/angrycamel/ivydav

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

Gintas

2017-07-28 21:26 GMT+02:00 Gintautas Grigelionis <g.grigelionis@gmail.com>:

> 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