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