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