On Sat, 2013-07-27 at 14:52 +0100, sebb wrote:
> On 27 July 2013 14:23, Oleg Kalnichevski <[email protected]> wrote:
> > 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.
> 
> I'm not quite sure how the references between classes in different
> build folders work.
> 
> In the case of test classes, these depend on main classes, but the
> main classes never depend on test classes, so it is easy to ensure
> that classes are built in the correct order.
> 
> Is that always true of deprecated classes? Are they built before or
> after the main classes?
> 

Now we have an option of moving injection of deprecated classes into a
separate Maven profile (for instance, doing that for release artifacts
only) or compiling sources in stages using a more flexible tool.

Oleg

> > 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]
> >
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to