Maven Shade isn't compatible with maven-android-plugin: https://code.google.com/p/maven-android-plugin/issues/detail?id=170 Perhaps when that is resolved, Shade will be a solution for Maven users. But what about Ant users (which I think are what most of the Android apps are built with)?
Not to mention that the permanently crippled HttpClient situation in Android is incredibly frustrating, unfortunate, and sad for both Android and HttpClient - it's a rude awakening for developers who happen to run across this problem (I bet many will over the upcoming years!). ~Craig sebb-2-2 wrote: > > On 8 November 2011 20:14, candrews <[email protected]> wrote: >> >> There are a number of issues with Java's HttpUrlConnection that make it a >> less than ideal option compared to HttpClient. For example, >> HttpUrlConnection has no way to set default connection/socket timeouts - >> you >> have to call >> http://developer.android.com/reference/java/net/URLConnection.html#setConnectTimeout%28int%29 >> and >> http://developer.android.com/reference/java/net/URLConnection.html#setReadTimeout%28int%29 >> for every connection. This particular issue is a killer for me - and I >> only >> just started evaluating switching my apps to HttpUrlConnection. >> >> There is precedent for Android "breaking" apps with upgrades - for >> example, >> https://code.google.com/p/android/issues/detail?id=15022 broke quite a >> few >> apps and annoyed more than a couple developers. >> >> In any case, I don't want to hijack this thread into a request for >> Android >> to upgrade HttpClient - I really just want to use HttpClient (and >> HttpClient-Cache) on Android. >> >> Since the org.apache.httpclient namespace is (probably) permanently taken >> with an outdated implementation, what can be done to allow Android >> developers to use HttpClient? >> >> Could there be releases, concurrent with the "normal" releases, of the >> org.apache.httpclient.* projects renamed to an alternative namespace? Of >> course, that means that non-httpclient projects would be broken, as they >> wouldn't change to use that alternative namespace, so developers wouldn't >> simply be able to drop in dependencies originally developed for >> non-Android >> targets. And if they did, they'd be in for a surprise when the dependency >> doesn't work due to VerifyError's or simply encountering runtime bugs >> that >> they "know" were fixed as they included a newer HttpClient dependency, >> but >> it's not actually used. >> >> IMHO, it seems that the Android decision to never change their bundled >> httpclient torpedos httpclient on Android forever - at least until Apache >> releases HttpClient 5 that uses a new namespace. Are there any other >> ideas >> on what can be done to remedy this situation? > > Have you considered the Maven Shade plugin? > > AIUI, that allows one to rename packages within a jar. > So you could change HC to use a different package name and thus use HC > 4.1 on Android without clashing with the native classes. > > I've only used it to allow Clirr to be used across a package rename, > but I think it is quite flexible. > > I think you can develop everything using standard package names, then > use Shade to rename whatever packages would clash with Android. > > Certainly worth trying if you have access to an Android development > system. > >> Thanks, >> ~Craig >> >> >> Jesse Wilson-4 wrote: >>> >>> Apache HTTP folks, >>> >>>> I have no problem with making httpclient-cache compatible with Android >>>> but at the same time I think users we should be encouraging Android >>>> users to migrate to the latest release of HttpClient nonetheless. >>> >>> I'm the >>> maintainer<http://android-developers.blogspot.com/2011/09/androids-http-clients.html>of >>> Android's HTTP clients. Android's non-adoption of new versions of >>> Apache >>> HTTP client is my decision, but it hasn't been an easy one. >>> >>> We made a mistake early on by exposing the full Apache HTTP client >>> API—including >>> impl<http://developer.android.com/reference/org/apache/http/impl/cookie/package-summary.html>packages >>> —in Android's API. This makes upgrading Apache HTTP client risky as I >>> have >>> to avoid breaking applications. It also adds a burden on application >>> developers who would need to test their applications against multiple >>> releases of Apache HTTP client to support multiple releases of Android. >>> The >>> rich API means there's many moving parts to test. >>> >>> If I could put the genie back in the bottle I would not have exposed >>> Apache >>> HTTP as a public API in Android. It's a great API, but our including it >>> the >>> platform locks everyone into an old build that we grabbed back in 2008. >>> It's much simpler for developers to pick a single release, test it, and >>> bundle it. For this reason I recommend that developers looking for new >>> Apache HTTP features follow Oleg's advice and repackage Apache HTTP in >>> their application. >>> >>> Or use HttpURLConnection, which I've spent a lot of time on lately. >>> There's >>> even an HTTP response cache in Ice Cream Sandwich. >>> >>> Thanks Oleg & Apache HTTP client contributors. It's powerful software >>> that >>> gets lots of exercise on Android. >>> >>> Thanks, >>> Jesse >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/HttpClient-Cache-release-that-works-against-HttpClient-4.0--tp32775131p32805637.html >> Sent from the HttpClient-User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> 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] > > > -- View this message in context: http://old.nabble.com/HttpClient-Cache-release-that-works-against-HttpClient-4.0--tp32775131p32808593.html Sent from the HttpClient-User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
