Hi everyone. I will prepare the suggestions for changes. Regarding the
discussion above, the following classes are the best choices:
Javadoc,
FTPTask,
FileUtils
ok?
2017-07-21 12:10 GMT-03:00 Stefan Bodewig <bode...@apache.org>:
> Yes, using the tool might be a good first indicator.
>
> I didn't mean to imply you called the tools a complete answer, just
> wanted to clarify my own words :-)
>
> Stefan
>
> On 2017-07-21, Gintautas Grigelionis wrote:
>
> > 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
