Here's a japicmp report on binary incompatibilities between Ivy 2.4.0 and
the snapshot build from the PR branch (which is rebased on latest master):
none of them break binary compatibility. Would anybody comment the rest of
incompatibilities? I am guilty of breaking ModuleRules, but that was for
the same reason: arrays of generics do not work in Java.
Gintas
***! MODIFIED CLASS: PUBLIC org.apache.ivy.core.module.id.ModuleRules (not
serializable)
***! MODIFIED METHOD: PUBLIC java.util.List (<-java.lang.Object[])
getRules(org.apache.ivy.core.module.id.ModuleId)
***! MODIFIED METHOD: PUBLIC java.util.List (<-java.lang.Object[])
getRules(org.apache.ivy.core.module.id.ModuleRevisionId,
org.apache.ivy.util.filter.Filter)
***! MODIFIED CLASS: PUBLIC
org.apache.ivy.osgi.updatesite.UpdateSiteLoader (not serializable)
---! REMOVED CONSTRUCTOR: PUBLIC(-)
UpdateSiteLoader(org.apache.ivy.core.cache.RepositoryCacheManager,
org.apache.ivy.core.event.EventManager,
org.apache.ivy.core.cache.CacheResourceOptions)
***! MODIFIED CLASS: PUBLIC FINAL
org.apache.ivy.plugins.circular.CircularDependencyHelper (not serializable)
---! REMOVED METHOD: PUBLIC(-) STATIC(-)
org.apache.ivy.core.module.id.ModuleRevisionId[]
toMrids(org.apache.ivy.core.module.descriptor.ModuleDescriptor[])
***! MODIFIED CLASS: PUBLIC FINAL org.apache.ivy.util.FileUtil (not
serializable)
---! REMOVED METHOD: PUBLIC(-) STATIC(-) void copy(java.net.URL,
java.io.File, org.apache.ivy.util.CopyProgressListener)
--- REMOVED EXCEPTION: java.io.IOException
---! REMOVED METHOD: PUBLIC(-) STATIC(-) void copy(java.io.File,
java.net.URL, org.apache.ivy.util.CopyProgressListener)
--- REMOVED EXCEPTION: java.io.IOException
---! REMOVED METHOD: PUBLIC(-) STATIC(-) void symlink(java.io.File,
java.io.File, org.apache.ivy.util.CopyProgressListener, boolean)
--- REMOVED EXCEPTION: java.io.IOException
---! REMOVED METHOD: PUBLIC(-) STATIC(-) void
symlinkInMass(java.util.Map, boolean)
--- REMOVED EXCEPTION: java.io.IOException
***! MODIFIED CLASS: PACKAGE_PROTECTED (<- PUBLIC)
org.apache.ivy.util.url.HttpClientHandler (not serializable)
***! MODIFIED CONSTRUCTOR: PACKAGE_PROTECTED (<- PUBLIC)
HttpClientHandler()
---! REMOVED METHOD: PUBLIC(-) int getHttpClientMajorVersion()
---! REMOVED INTERFACE: PUBLIC(-) ABSTRACT(-) STATIC(-)
org.apache.ivy.util.url.HttpClientHandler$HttpClientHelper (not
serializable)
---! REMOVED METHOD: PUBLIC(-) ABSTRACT(-) int
getHttpClientMajorVersion()
---! REMOVED METHOD: PUBLIC(-) ABSTRACT(-) long
getResponseContentLength(org.apache.commons.httpclient.HttpMethodBase)
2017-07-28 20:34 GMT+02:00 Gintautas Grigelionis <g.grigelio...@gmail.com>:
> It's not a new method, it's a change of signature. The old method is still
> there. If an implementation disregards the abstract class, which contains
> the replacement, it would still work, right?
>
> 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
>>
>>
>
