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 <bode...@apache.org>: > 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 > >
