hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Separate src folder for deprecated classes
Date Sat, 27 Jul 2013 19:35:19 GMT
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.

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.

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.

> Oleg
>
>> > Oleg
>> >
>> >> Gary
>> >>
>> >> On Jul 26, 2013, at 10:19, Oleg Kalnichevski <olegk@apache.org> 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: dev-unsubscribe@hc.apache.org
>> >> > For additional commands, e-mail: dev-help@hc.apache.org
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> >> For additional commands, e-mail: dev-help@hc.apache.org
>> >>
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> > For additional commands, e-mail: dev-help@hc.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

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


Mime
View raw message