Thanks, Stefan. You're right about the semantics; I did not mean the API compatibility analysis to give a complete answer, rather a hint about the amount of (potential) breakage. Based on that, a decision can be taken whether it can be accepted, mitigated or a completely new version is a must. If the latter is the case, then one may decide it's not worth the while because of the cost of adoption.
Gintas 2017-07-21 11:40 GMT+02:00 Stefan Bodewig <bode...@apache.org>: > Hi > > thank you, Gintautas. > > Yes, using a tool to verify the API hasn't changed will probably > help. Over in Commons we run this as a regular part of the release > process - it is even more important for things that are meant to be > re-usable components, of course. > > I'm afraid that won't be enough, though. > > Let me pick a silly example > > in Project we currently have > > public Project createSubProject() { > Project subProject = null; > try { > subProject = (getClass().newInstance()); > } catch (final Exception e) { > subProject = new Project(); > } > initSubProject(subProject); > return subProject; > } > > and initSubProject is public as well. > > A subclass may override initSubProject and rely on the method being > called by createSubProject. If you refactor createSubProject in a way > that it no longer calls initSubProject you are going to break the > subclass. And I don't think the tools are going to tell you as long as > you keep all existing methods. > > This is what I meant with "have to ensure you keep the existing who > calls which method semantics". > > Cheers > > Stefan > > > On 2017-07-20, Gintautas Grigelionis wrote: > > > I looked at Project proposal [1]. > > I would suggest running the refactored Ant through japicmp [2] or revapi > > [3] and examining the binary incompatibilities. > > > Gintas > > > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=61305 > > [2] http://siom79.github.io/japicmp/ > > [3] http://revapi.org/ > > > 2017-07-20 16:41 GMT+02:00 Stefan Bodewig <bode...@apache.org>: > > >> Welcome João Paulo > > >> On 2017-07-20, João Paulo Lemes Machado wrote: > > >>> I was analyzing the modularization of some classes of Ant, and I > >>> identified some opportunities for cohesion improvement in the following > >>> classes: > > >>> Javac > >>> Javadoc > >>> FTPTask > >>> FileUtils > >>> AbstractFileSet > > >> Similar to what I said about Project in the bugzilla issue you created > >> all these classes are part of Ant's public API and need to be treated > >> with care. > > >> Ant has been around for more than fifteen years and an eco system of > >> extensions has ground around it. This is something that forces us to > >> be extra careful with refactoring. > > >> Of the classes listed above Javadoc and FTPTask are unlikely to have > >> seen subclasses, Javac may have. FileUtils is unlikely to have seen > >> subclasses as a lot of its code is inside static methods or is > >> accessed via a quasi-singleton. > > >> Still, when refactoring non-static public/protected methods you really > >> have to ensure you keep the existing who calls which method semantics > >> that subclasses may rely on. AbstractFileSet is an extremely dangerous > >> one, as it has certainly seen a lot of extensions outside of our > >> control. > > >>> TarEntry > > >> Is a special case to me. Ant's tar, zip and bzip2 packages have seeded > >> Commons Compress and from time to time I try to backport changes from > >> Compress to Ant - usually only the bugfixes. This may become more > >> difficult when the code bases start to deviate. > > >> I'd be interested in hearing what kind of changes you'd like to make, > >> but please take a look at > >> https://git-wip-us.apache.org/repos/asf?p=commons-compress. > >> git;a=blob;f=src/main/java/org/apache/commons/compress/ > >> archivers/tar/TarArchiveEntry.java > >> ? > > >> The class has undergone several changes that haven't been reflected > >> back, maybe it is mostly an issue of backporting those changes? > > >> Cheers > > >> Stefan > > >> --------------------------------------------------------------------- > >> 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 > >