ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Opportunities for cohesion improvement and refatoring.
Date Sun, 23 Jul 2017 10:47:03 GMT
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message