hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [Request for comments] HttpClient re-spin for Android
Date Tue, 28 Jan 2014 08:35:57 GMT
On Tue, 2014-01-28 at 00:20 +0000, sebb wrote:
> 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.


_Nothing_, absolutely _nothing_ can be compatible with standard HC4 in
Android or any library compiled against it. This is like being very much
concerned about dental hygiene of a corpse.

We can either provide a half-way house or do nothing.


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

So, you are suggesting that the best course of action is to do nothing?

Oleg



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


Mime
View raw message