hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Separate src folder for deprecated classes
Date Sun, 28 Jul 2013 10:59:44 GMT
On Sat, 2013-07-27 at 20:35 +0100, sebb wrote:
> On 27 July 2013 16:46, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Sat, 2013-07-27 at 14:52 +0100, sebb wrote:
> >> On 27 July 2013 14:23, Oleg Kalnichevski <olegk@apache.org> 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.
> 
> I guess what I was asking was: do the main classes have any
> dependencies on the deprecated classes?
> If so, then at least those deprecated classes must be available to main builds.
> 

Certainly, those deprecated interfaces and classes that non-deprecated
code still depends upon need to remain in the main source tree

> The only thing I can think of that would be difficult (impossible?) to
> code around is a deprecated interface.
> I suspect deprecated interfaces will need to be compiled always.
> 

Yes, that is the case. 

> The rest of the deprecated code may well depend on some main code so
> must be compiled after the main code (if it is compiled at all).
> 
> If Maven adds the deprecated source tree to the main source, then it
> should be able to compile it all at once.
> I don't think a different tool is needed here, but the deprecated code
> may need to be split if it is intended to make it (mostly) optional.
> 

The idea is to move out only those bits that have become completely
redundant. 

Oleg 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message