hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Apache HttpClient 4.1.3 re-spin for Android
Date Mon, 16 Apr 2012 08:49:42 GMT
On Mon, Apr 16, 2012 at 02:57:43AM +0100, sebb wrote:
> On 15 April 2012 18:26, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Sun, 2012-04-15 at 18:09 +0100, sebb wrote:
> >> 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.
> >>
> >
> > It will not happen automatically but at least one can still create an
> > instance of DefaultHttpClient from the
> > 'org.apache.hc.android.impl.client' package instead of
> > 'org.apache.http.impl.client' and pass it as a dependency to any
> > external library that expects an instance of
> > 'org.apache.http.client.HttpClient'.
> 
> OK, I see now. I thought you were trying for a drop-in replacement.
> 

My apologies for having used a misleading term. Drop-in in a sense of being fully compatible,
parallel-deployable replacement for the outdated version shipped with Android. The users would
still need to re-wire their applications to use the newer implementation, though.

Oleg


> > This may sound like a small thing but this is actually impossible when
> > HttpClient code is 'shaded' to a new namespace wholesale along with all
> > API interfaces.
> 
> Yes.
> 
> > Oleg
> >
> >> >
> >> >> > 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
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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