hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Apache HttpClient 4.1.3 re-spin for Android
Date Sun, 15 Apr 2012 17:09:26 GMT
On 15 April 2012 17:55, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Sun, 2012-04-15 at 16:38 +0100, sebb wrote:
>> On 15 April 2012 13:29, Oleg Kalnichevski <olegk@apache.org> wrote:
>> > Folks
>> >
>> > It is not a big secret that Google decided to continue shipping the
>> > extremely outdated pre-BETA version of HttpClient instead of upgrading
>> > to a newer version and to steer Android users toward HttpUrlConnection
>> > API. I understand they must have their good reasons. At the same, those
>> > people who may not share Google's enthusiasm about having to migrate to
>> > HttpUrlConnection are left with no viable upgrade options as stock
>> > versions of HttpClient cannot be used in Android. A very common
>> > work-around to this problem is to move HttpClient code to a different
>> > namespace in order to avoid classloader conflicts with Android code.
>> > This can be done either using Maven Shade plugin or a script such as one
>> > developed by Dirk Boye [1]. The downside of this work-around is that the
>> > shaded HttpClient cannot be used with 3rd party libraries such as Spring
>> > compiled against the standard API.
>> >
>> > A better approach might be to 'shade' only implementation classes only
>> > and compile them against the API interfaces and classes shipped with
>> > Android. This could produce a reasonably up to date version of
>> > HttpClient which at the same time can be used as a drop-in replacement
>> > for the outdated Android version.
>>
>> I'm not clear what exactly you are proposing to release.
>>
>
> HttpClient 4.1.3 code sans API interfaces and classes moved to
> 'org.apache.hc.android' namespace or similar.

So the jar would only contain classes in its own package namespace?
That would certainly avoid classpath issues and Maven coords.

But I don't see how applications would pick up the different implementation.

>
>> > What I would like to do is to take HttpClient 4.1.3 release tag and
>> > create an Android compatible re-spin with a distinct Maven artifact from
>> > that tag.
>>
>> Maven relies on the artifactId (and groupId, i.e. the coordinates) to
>> know how to build the dependency path.
>> So it's important to know what packages the proposed jars will contain.
>> And it's important not to mislead Maven by supplying incorrect coordinates.
>>
>> Otherwise, Maven could combine incompatible jars on the same classpath
>> - with all the problems that can bring.
>>
>
> I am thinking about creating a copy of HttpClient 4.1.3 in SVN rather
> than trying to repackage existing binary artifacts in some clever way.
> This would enable us to selectively apply changes made by Google to
> their version of HttpClient for better compatibility.
>
>> > If you think this is not a good idea please raise your concerns now. If
>> > I hear no objections, I'll proceed with the development of HttpClient
>> > version for Android and will call a release vote when ready.
>>
>> Luckily it should be quite easy to test the behaviour on Android.
>> I've been playing with Eclipse and the ADT recently, so can provide
>> some feedback on that aspect.
>>
>
> That'd be awesome.
>
> 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


Mime
View raw message