hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Request for comments] HttpClient re-spin for Android
Date Tue, 28 Jan 2014 00:20:22 GMT
On 27 January 2014 22:46, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Mon, 2014-01-27 at 15:32 -0500, Gary Gregory wrote:
>> The first thing I'd like to suggest is avoiding the term 're-spin' in the
>> name of the component. To me re-spin means to retry a release. For example,
>> I cut an RC1, problems are found, so we need a re-spin to an RC2. Since
>> this is a different component, I'd just call it 'HttpClient for Android',
>> nice and simple. But this may not matter in the end because... it sounds
>> like 4.0 and 4.3 are not binary compatible (BC).
>> So let's start with that, is that so? I'm looking at our site and I cannot
>> find reports like Clirr and on so. Granted in the case of HttpClient I
>> would expect a Clirr of 4.3.2 vs. 4.3.1, which would not tell me anything
>> vs 4.0. Looking at the release notes, it looks like there have been of API
>> changes that break BC, for example from 4.1 to 4.2.
> All releases of HttpClient 4.x are backward compatible with 4.0
>> Over in the Apache Commons project, the general guideline is that when you
>> break BC, you use a new package name and new Maven coordinates. See lang ->
>> lang3 and pool -> pool2 for example. If the BC break is
>> If you do not do this, you are creating jar hell.
> Jar hell on Android has already been created for us.

Indeed - the bundled version should either have been given a new
package name, or it should be possible to upgrade it.

>> A classic jar problem is if I depend on a third party jar that depends on
>> HC 4.0, then I cannot write my app to anything else but 4.0. If HC 5 is in
>> a new package, then I can happily use HC5 and the guts of the third party
>> jar can happily use HC4. Yes, they would not be re-using the same caches
>> for example but at least there would be no surprises.
> This is a completely different situation. This is not a new version of
> HttpClient. It is a port. Its main goal is to provide a version of
> HttpClient compatible with Android.

One way to be compatible is to use completely new package names.
However that has some costs for existing apps.

On the other hand, there are also costs for using any half-way house
that is not compatible with standard HC4.

>> Adding copies of a bunch of classes with an HC4 postfix seems worse (to me)
>> than another copy of HC in a new package.
> By moving classes to a different package we would end up creating a
> pointless fork _both_ incompatible with the version shipped with Android
> and the stock 4.3 version. It just makes no sense.

If you take an existing application running on the current HC4, it
cannot currently run on Android because of clashes with the HC4
classes that are included in the Android OS. However, if the HC4
classes were shaded, then the app would surely work OK on Android - it
would effectively be a different HTTP library.

But that can be done by the app developer easily enough - there is no
need for the ASF to produce a shaded jar.

> 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

View raw message