On Mon, Apr 16, 2012 at 02:57:43AM +0100, sebb wrote: > On 15 April 2012 18:26, Oleg Kalnichevski <[email protected]> wrote: > > On Sun, 2012-04-15 at 18:09 +0100, sebb wrote: > >> On 15 April 2012 17:55, Oleg Kalnichevski <[email protected]> wrote: > >> > On Sun, 2012-04-15 at 16:38 +0100, sebb wrote: > >> >> On 15 April 2012 13:29, Oleg Kalnichevski <[email protected]> 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: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
