Re: Opportunities for cohesion improvement and refatoring.
On 2017-07-23, João Paulo Lemes Machado wrote: > Thank you Stefan. > I did not know that the issue of break of build was so serious. > However, I still think that creating a class for the configuration methods > can help prevent these classes from growing even more. Absolutely. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Opportunities for cohesion improvement and refatoring.
Thank you Stefan. I did not know that the issue of break of build was so serious. However, I still think that creating a class for the configuration methods can help prevent these classes from growing even more. For example if someone wants to create a new get () or set () method for the Javadoc class, he might consider creating it directly in the JavadocConfig class, avoiding putting more methods into the Javadoc class. And perhaps this strategy can be adopted for the creation of new classes in the future. For example, if you are going to create a new class that has a considerable amount of gets () and sets () like Javadoc, you might consider creating a configuration class for these methods. I think if it is very difficult to correct what has already been done, maybe we can avoid these problems in the future by adopting new practices and strategies. What do you think? 2017-07-23 7:47 GMT-03:00 Stefan Bodewig : > On 2017-07-23, João Paulo Lemes Machado wrote: > > > Analyzing the points of our discussion, I have realized that the most > > critical problem is the dependence these classes may have on other > classes. > > > With that in mind I recommend a gradual refactoring that works as > follows: > > > First, we mark the methods we want to extract as depreciated. > > > Then, we copy those methods to a new class. > > > So we will keep the methods in the original class for some time so that > > developers who have some assumption about the class can adapt. > > > > For example, the Javadoc has 114 methods, of which 64 are get () and set > () > > methods. We could mark these methods as deprecated and copy them to a new > > class: JavadocConfig, but we would leave them in the Javadoc class, and > > they would be removed gradually. > > > > Those parameters and methods would be accessed by an instance variable > > in Javadoc. > > > > > However, when choosing the methods we could analyze their complexity. If > it > > is a simple set () or get () that only sets or returns a value it would > be > > prioritized. > > > > > Methods that have a greater complexity, or that make calls to other > methods > > would not be extracted at first. > > > > > What do you think about this strategy? > > This strategy is a sound strategy if you expect users of your API to > follow releases closely. Unfortunately this is not what we see with Ant. > > Right now we are fielding a bug reported by somebody who is migrating > from Ant 1.6.2 to 1.10.1 - 1.6.2 has been superseeded by 1.6.3 in > 2005. This is not uncommon. > > People are using additional libraries like ant-contrib. ant-contrib has > seen its last release in 2010 and it's development has stalled > completely. We cannot remove any method used by it at all without > breaking build files of people who rely on ant-contrib. Unfortunately > ant-contrib is not the only example. > > This has led to us never removing any methods at all, no matter how long > it has been deprecated. I'm not sure this is a good idea and not saying > it has to stay that way, but the above has been the rationale for it. > > To be honest, I am one of the people who've upheld the "backwards > compatible at all cost" mantra. Part of this may be due to the pain of > "every release of Ant breaks my builds" threads around the release of > Ant 1.2 (almost 17 years and I still recall it like yesterday, strange). > > If others feel it is time to revisit our extremely strong and at the > same time limiting stance on backwards compatibility, I'll be listening > to them. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: Opportunities for cohesion improvement and refatoring.
On 2017-07-23, João Paulo Lemes Machado wrote: > Analyzing the points of our discussion, I have realized that the most > critical problem is the dependence these classes may have on other classes. > With that in mind I recommend a gradual refactoring that works as follows: > First, we mark the methods we want to extract as depreciated. > Then, we copy those methods to a new class. > So we will keep the methods in the original class for some time so that > developers who have some assumption about the class can adapt. > For example, the Javadoc has 114 methods, of which 64 are get () and set () > methods. We could mark these methods as deprecated and copy them to a new > class: JavadocConfig, but we would leave them in the Javadoc class, and > they would be removed gradually. > Those parameters and methods would be accessed by an instance variable > in Javadoc. > However, when choosing the methods we could analyze their complexity. If it > is a simple set () or get () that only sets or returns a value it would be > prioritized. > Methods that have a greater complexity, or that make calls to other methods > would not be extracted at first. > What do you think about this strategy? This strategy is a sound strategy if you expect users of your API to follow releases closely. Unfortunately this is not what we see with Ant. Right now we are fielding a bug reported by somebody who is migrating from Ant 1.6.2 to 1.10.1 - 1.6.2 has been superseeded by 1.6.3 in 2005. This is not uncommon. People are using additional libraries like ant-contrib. ant-contrib has seen its last release in 2010 and it's development has stalled completely. We cannot remove any method used by it at all without breaking build files of people who rely on ant-contrib. Unfortunately ant-contrib is not the only example. This has led to us never removing any methods at all, no matter how long it has been deprecated. I'm not sure this is a good idea and not saying it has to stay that way, but the above has been the rationale for it. To be honest, I am one of the people who've upheld the "backwards compatible at all cost" mantra. Part of this may be due to the pain of "every release of Ant breaks my builds" threads around the release of Ant 1.2 (almost 17 years and I still recall it like yesterday, strange). If others feel it is time to revisit our extremely strong and at the same time limiting stance on backwards compatibility, I'll be listening to them. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Opportunities for cohesion improvement and refatoring.
Hello everyone. Analyzing the points of our discussion, I have realized that the most critical problem is the dependence these classes may have on other classes. With that in mind I recommend a gradual refactoring that works as follows: First, we mark the methods we want to extract as depreciated. Then, we copy those methods to a new class. So we will keep the methods in the original class for some time so that developers who have some assumption about the class can adapt. For example, the Javadoc has 114 methods, of which 64 are get () and set () methods. We could mark these methods as deprecated and copy them to a new class: JavadocConfig, but we would leave them in the Javadoc class, and they would be removed gradually. Those parameters and methods would be accessed by an instance variable in Javadoc. However, when choosing the methods we could analyze their complexity. If it is a simple set () or get () that only sets or returns a value it would be prioritized. Methods that have a greater complexity, or that make calls to other methods would not be extracted at first. What do you think about this strategy? 2017-07-22 8:13 GMT-03:00 Stefan Bodewig : > On 2017-07-21, João Paulo Lemes Machado wrote: > > > Hi everyone. I will prepare the suggestions for changes. Regarding the > > discussion above, the following classes are the best choices: > > > Javadoc, > > FTPTask, > > FileUtils > > > ok? > > sounds right. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: Opportunities for cohesion improvement and refatoring.
On 2017-07-21, João Paulo Lemes Machado wrote: > Hi everyone. I will prepare the suggestions for changes. Regarding the > discussion above, the following classes are the best choices: > Javadoc, > FTPTask, > FileUtils > ok? sounds right. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Opportunities for cohesion improvement and refatoring.
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 :
> 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 :
>
> >> 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 :
>
> 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
>
>
>
> >> --
Re: Opportunities for cohesion improvement and refatoring.
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 :
>> 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 :
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
Re: Opportunities for cohesion improvement and refatoring.
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 :
> 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 :
>
> >> 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
>
>
Re: Opportunities for cohesion improvement and refatoring.
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 :
>> 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
Re: Opportunities for cohesion improvement and refatoring.
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 : > 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 > >
Re: Opportunities for cohesion improvement and refatoring.
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
Re: Opportunities for cohesion improvement and refatoring.
Hi João Paulo, please open a pull request on GitHub or at least provide a description of your suggested improvements. Thanks, Gintas 2017-07-20 1:56 GMT+02:00 João Paulo Lemes Machado : > Hello everyone. > > My name is João Paulo, I am a graduate student the Federal University of > Uberlandia, Brazil. > > 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 > TarEntry > > > Could you please take a look and tell me if it's viable? > > Maybe some of these classes could benefit from some kind of refactoring > that we can discuss. >
