On Fri, 2013-07-26 at 10:35 -0400, Gary Gregory wrote: > I only see the need for this extra complication if you also plan on > creating a jar for the deprecated code. This way you can have pure 4.3 > jar and a 4.2 compatibility jar. >
This is certainly a possibility and can help great deal should we decide to release a re-spin of HttpClient 4.3 for Android. More importantly though it helps reduce coupling between deprecated and non-deprecated classes. Accidental references to deprecated classes are now much easier to catch. Oleg > Gary > > On Jul 26, 2013, at 10:19, Oleg Kalnichevski <[email protected]> wrote: > > > Folks > > > > Both HttpCore and HttpClient trunks (especially the latter) have a > > significant number of deprecated classes that accumulated in the course > > of 3 feature releases. I would rather see them removed but we have to > > practical about it. As an alternative, I would like to move deprecated > > classes to a separate src folder ./src/deprecated/java > > or ./src/main/java-deprecated. This would enable us to apply different > > policies to those classes, exclude them from the test coverage reports, > > and simply not to have them in the way. This change will not affect > > binary compatibility, just packaging. > > > > I hope there will be no objections but if I am mistaken please make them > > known now before I start moving classes around. > > > > Oleg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
