You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2013/07/26 16:18:33 UTC
Separate src folder for deprecated classes
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
Re: Separate src folder for deprecated classes
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2013-07-26 at 15:30 +0100, sebb wrote:
> On 26 July 2013 15:18, Oleg Kalnichevski <ol...@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.
>
> No objection, but this will require quite a few changes to poms, as
> one can no longer rely on the default Maven configuration.
>
> There are only about 5 deprecation warnings in httpcore, so I suggest
> leaving that.
>
Supposedly this thing can be used to inject additional sources to the
Maven's generate-sources phase, which should cause only minimal changes
to the pom metdata. Remains to be seen if that is indeed the case.
http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Separate src folder for deprecated classes
Posted by sebb <se...@gmail.com>.
On 26 July 2013 15:18, Oleg Kalnichevski <ol...@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.
No objection, but this will require quite a few changes to poms, as
one can no longer rely on the default Maven configuration.
There are only about 5 deprecation warnings in httpcore, so I suggest
leaving that.
> 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
Re: Separate src folder for deprecated classes
Posted by Jon Moore <jo...@apache.org>.
Sounds reasonable to me. I'd suggest we also document this on our wiki
somewhere as a policy to move deprecated classes over here at the time we
mark them deprecated in the source [or whatever we want the policy to be].
Jon
On Fri, Jul 26, 2013 at 10:18 AM, Oleg Kalnichevski <ol...@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
>
>
Re: Separate src folder for deprecated classes
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2013-07-27 at 20:35 +0100, sebb wrote:
> On 27 July 2013 16:46, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Sat, 2013-07-27 at 14:52 +0100, sebb wrote:
> >> On 27 July 2013 14:23, Oleg Kalnichevski <ol...@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
Re: Separate src folder for deprecated classes
Posted by sebb <se...@gmail.com>.
On 27 July 2013 16:46, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sat, 2013-07-27 at 14:52 +0100, sebb wrote:
>> On 27 July 2013 14:23, Oleg Kalnichevski <ol...@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 <ol...@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
Re: Separate src folder for deprecated classes
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2013-07-27 at 14:52 +0100, sebb wrote:
> On 27 July 2013 14:23, Oleg Kalnichevski <ol...@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.
Oleg
> > Oleg
> >
> >> Gary
> >>
> >> On Jul 26, 2013, at 10:19, Oleg Kalnichevski <ol...@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
Re: Separate src folder for deprecated classes
Posted by sebb <se...@gmail.com>.
On 27 July 2013 14:23, Oleg Kalnichevski <ol...@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?
> Oleg
>
>> Gary
>>
>> On Jul 26, 2013, at 10:19, Oleg Kalnichevski <ol...@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
Re: Separate src folder for deprecated classes
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@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
Re: Separate src folder for deprecated classes
Posted by Gary Gregory <ga...@gmail.com>.
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.
Gary
On Jul 26, 2013, at 10:19, Oleg Kalnichevski <ol...@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