> Le 29 mai 2017 à 11:46, Jan Matèrne (jhm) <apa...@materne.de> a écrit : > > Sounds like I would do ;) > I'll merge the PR locally and insert the delegates. > > Open is > "src/java/org/apache/ivy/osgi/util/Version.java: > the constructor removes the (IMO unneccessary) ParseException. > But because it is a checked Exception we break BC." > > https://wiki.eclipse.org/Evolving_Java-based_APIs_2 defines the removal of a > checked exception: > "Breaks compatibility" > "Adding and deleting checked exceptions declared as thrown by an API method > does not break binary compatibility; however, > it breaks contract compatibility (and source code compatibility)." > > What do we want?
Thanks for the link, I’ll bookmark it. Then I am OK with that. The Ivy jar can still be a upgraded without worries, and if somebody compile against it, then he has the source so he can modify them. I am OK with that also because having stricter compatibility rules will be painful considering the wide API Ivy is exposing. Nicolas > > > > Jan > >> -----Ursprüngliche Nachricht----- >> Von: J Pai [mailto:jai.forums2...@gmail.com] >> Gesendet: Montag, 29. Mai 2017 10:26 >> An: Ant Developers List >> Betreff: Re: PR-33: problems >> >> IMO, for each of these public classes/methods/fields that we are fixing >> for typos, we should mark them @Deprecated (and add a @deprecated >> javadoc too and point to the new field/method/class) and introduce the >> rightly named class/method/field. For methods it’s straightforward, the >> deprecated method internally calls the new method. For fields too it’s >> straightforward. The deprecated field uses the value of the new field. >> For classes, I think we can copy over the existing class into the new >> one and leave around the existing one just for possible external >> references (that we can’t control off) and migrate all internal >> references to the new one. >> >> At some point, in some future version of Ivy, we remove/delete these >> deprecated method/field/class. >> >> >> -Jaikiran >> >> >> On 29-May-2017, at 1:43 PM, Jan Matèrne <j...@materne.de> wrote: >> >> I did a review of <https://github.com/apache/ant-ivy/pull/33> >> https://github.com/apache/ant-ivy/pull/33 >> >> Here are the points I have problems with, so I want to discuss them >> here. >> >> Basically it's about breaking BC. So how to deal with that? >> >> >> >> >> >> Jan >> >> >> >> >> >> Fixing the spell error in DelegateHandler$ChildElementHandler >> (s/childHanlded/childHandled/) means breaking beakward compatiblity. >> >> We could introduce a delegetate for that: >> >> /** for BC */ >> >> @Deprecated >> >> public void childHanlded(DH child) throws SAXParseException { >> >> childHandled(DH child); >> >> } >> >> While refactoring you have renamed all occurences in the Ivy codebase. >> >> On the other hand I don't know the impact (maybe outside of Ivy). I'll >> bring that to the dev-list. >> >> >> >> >> >> src/java/org/apache/ivy/osgi/repo/FSManifestIterable.java: renaming the >> public constant DEFAULT_BUNLDE_FILTER also means breaking BC. >> >> >> >> >> >> src/java/org/apache/ivy/osgi/util/Version.java: the constructor removes >> the (IMO unneccessary) ParseException. But because it is a checked >> Exception we break BC. >> >> >> >> >> >> renaming EncrytedProperties to EncryptedProperties means breaking BC. >> If required we could introduce a delegating class or a subclass. >> >> >> >> >> >> ArtifactOrigin: renaming unkwnown() to unknown() means breaking BC. If >> required we could introduce a delegating method. >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional >> commands, e-mail: dev-h...@ant.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
