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
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
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
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
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
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
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
>
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
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,
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
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
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
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
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
14 matches
Mail list logo