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.grigelio...@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 <bode...@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-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> >
