-
Notifications
You must be signed in to change notification settings - Fork 754
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make the dependency on Apache HTTP optional #2
Comments
In my humble opinion, doing a major version bump worth it. Also I think that this change is really important, since HttpClient has been deprecated 2 APIs ago and in some future it may become unavailable at all. |
I'd need more details on what you're suggesting with the above, but it looks like the above code just changes the signature of HttpStack#performRequest, which is the problem noted in 1 (an API-breaking change). Doing that is the extreme option which will break every caller of Volley so like I said, I'd like to explore a more gentle approach before taking such a hard line. |
@jpd236 sorry for my bad English, can you explain more about "API-breaking change"? In the code i mentioned, not only the signatures changed, and you can see dependency removed. |
Sure - what I mean is that there are existing apps which depend on Volley with their own subclasses of HttpStack and/or Request. If we change those classes in an incompatible way, e.g. by changing the return type of HttpStack#performRequest from HttpResponse to URLConnection, those apps will no longer compile when they upgrade. This is painful to developers, so it's something we generally like to avoid if at all possible. At the very least, we like to provide a transition period for apps to move off the broken APIs before we remove them. So I'm hoping that instead of just changing the library's public method signatures, we can keep the old ones, but deprecate them and add new ones to replace them. |
@jpd236 I got it, many thanks :) |
I think this is a right time to have 2.0 version released, which will drop HttpClient suppport and break API. It's already 17th month passed since official HttpClient deprecation. I don't think it's necessary to wait longer... |
This change makes it feasible for Volley clients to remove their dependency on the legacy Apache HTTP library; if HurlStack is used, or if their existing HttpStack implementation is refactored atop the new BaseHttpStack (which should be trivial), then Volley will never depend on classes in org.apache at runtime. However, legacy clients built atop HttpStack (including HttpClientStack) should continue to work without modifications for now. Fixes #2
The above commit should make it possible to depend on Volley without having to declare a dependency on the Apache HTTP client via the approach I outlined above as long as you're using HurlStack or another stack which doesn't depend on the Apache HTTP library (in which case you'll need to make a small tweak to extend from BaseHttpStack instead of implementing HttpStack). In my testing, the Android build tools seem to call proguard with the Apache JAR in the classpath even though the app never asked for it, so we may not have to do any proguard hacks at this point. That being said, it'd be very helpful for other app developers to try this approach to see if it meets their needs and works with their build. If you'd like to test this, you can either patch in this change and build from source, or try this compiled aar library by unzipping the .aar file inside, putting it in your tree (say aar/) and adding this to build.gradle in place of any existing Volley dependency:
If this works well for folks, I'll move forward with getting this merged and released. |
Good to know that the dependency on Apache HttpClient is going to go. |
I have editted HurlStack class , you just need to paste it to your project and you will give totally new perspective to your users:I just added between of
|
@NewTimeBox I don't really know how your class is related to the issue discussed here. You are just offering to add Pre and Post hooks to connection. What are you offering to do in those and how this may solve issue of Apache HttpClient dependency? |
This change makes it feasible for Volley clients to remove their dependency on the legacy Apache HTTP library; if HurlStack is used, or if their existing HttpStack implementation is refactored atop the new BaseHttpStack (which should be trivial), then Volley will never depend on classes in org.apache at runtime. However, legacy clients built atop HttpStack (including HttpClientStack) should continue to work without modifications for now. Fixes #2
* Deprecate Volley's use of Apache HTTP. This change makes it feasible for Volley clients to remove their dependency on the legacy Apache HTTP library; if HurlStack is used, or if their existing HttpStack implementation is refactored atop the new BaseHttpStack (which should be trivial), then Volley will never depend on classes in org.apache at runtime. However, legacy clients built atop HttpStack (including HttpClientStack) should continue to work without modifications for now. Fixes #2 * Unit tests and bug fixes for Apache HTTP deprecation. -Block large (>MAX_INT) responses in AdaptedHttpStack -Fix copying headers in BaseHttpStack * Address review comments.
Initial migration guide is here: https://github.com/google/volley/wiki/Migrating-from-Apache-HTTP This should become available in an official SNAPSHOT build shortly, though the interface is subject to change until the next official release. |
Volley currently depends on Apache HTTP. We can mostly remove the dependency except that HttpStack#performRequest returns an org.apache.http.HttpResponse, which means it'd be an API-breaking change to remove.
It might be worth biting the bullet and just doing a major version bump that breaks the API. There are other known issues that we could potentially address alongside this. However, one avenue worth exploring would be to see if we could treat Apache HTTP as a "provided" dependency - that is, one which is available at compile time, but not runtime - and then deprecate the old performRequest and add a new one that is implemented by all built-in clients (except HttpClientStack, which should be deprecated as well).
I think the result would compile and let apps build against Volley without pulling in the Apache HTTP dependency, but existing users could continue to use the Apache stack as long as they pulled in the dependency at runtime (and it should be there on an actual Android device).
Apart from the ugliness, my main concern is how proguard would respond to the missing reference - we could add a consumer proguard rule to not warn on org.apache stuff though that might be a bit overbearing.
The text was updated successfully, but these errors were encountered: