Just committed the removal of this. https://issues.apache.org/jira/browse/CB-6630 https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=c6b171b
Note that there is *no* API change to org.apache.cordova.* classes, but it still could be considered a breaking change since any plugin that assumed the OkHttp classes are included would be wrong (though, I'm not aware of any such plugins). I've created a plugin in labs that shows how to re-add OkHttp via gradle: https://github.com/apache/cordova-plugins/tree/master/android-okhttp On Tue, Sep 30, 2014 at 4:43 PM, Andrew Grieve <[email protected]> wrote: > > > On Tue, Sep 30, 2014 at 12:08 PM, Joe Bowser <[email protected]> wrote: > >> On Tue, Sep 30, 2014 at 8:52 AM, Andrew Grieve <[email protected]> >> wrote: >> >> > +1 unbundle. The reason we added it in was that it fixes issues with >> > Android's built-in networking stack. It was added pre-plugin-breakout, >> and >> > was never broken out into its own plugin. >> > >> > >> Because CordovaResourceApi is a core API. >> > Sorry, I was referring to OkHttp here, not CordovaResourceApi. > > > >> >> >> > The good news is that I think it'll be quite straight-forward to >> extract it >> > out. We don't expose OkHttp interfaces anywhere, and instead exposed it >> > through CordovaResourceApi via createHttpConnection() (which returns a >> > HttpURLConnection, not an OkHttp interface). >> > >> > >> How many plugins depend on this functionality? >> > No idea. File Transfer does. My point though is that we can remove OkHttp > without changing the signature of this function. We can just return the > system default HTTPURLConnection. > > >> >> >> > The grey area is whether we'd want the FileTransfer plugin to depend on >> > OkHttp, or whether we just have FileTransfer be flakey on pre-KitKat >> > devices if devs don't choose to add the plugin. I think I'd be in the >> camp >> > of adding it by default, but then allow it to be removed via "plugin >> rm". >> > Our tools don's support that right now though. >> > >> >> I don't think this is a grey area. We could move this in the plugin, but >> this is an API change. Can you create a feature branch off 4.0.x with >> this? >> > Definitely don't want to bundle it with FileTransfer in case another > plugin also wants to use OkHttp. We'd need it to be its own plugin. > > This work is unfortunately not on my radar to work on in the near term. > > > >> >> >> > >> > >> > >> > >> > On Tue, Sep 30, 2014 at 8:51 AM, Marcel Kinard <[email protected]> >> wrote: >> > >> > > I agree it would be cleaner to not embed okhttp in Cordova. >> > > >> > > If it is removed, what do you see as the user experience? Does the CLI >> > > automatically download the okhttpd jar from square's github? Or do we >> > > expect the user to do that manually and drop it in a lib folder? >> > > >> > > Would it be possible to have the Apache httpd client take the place of >> > > okhttp, or are there okhttp-specific functions being used? >> > > >> > > On Sep 29, 2014, at 5:16 PM, Joe Bowser <[email protected]> wrote: >> > > >> > > > Hey >> > > > >> > > > Can we unbundle okhttp without breaking Cordova? I think that our >> > > bundling >> > > > has become a serious problem, and we should find a way to abstract >> the >> > > > dependency away somehow into a plugin and should do this in 4.0.x. >> > > > >> > > > Ian, anyone else who knows what's going on with File/URIs? What's >> your >> > > > thoughts on this? >> > > > >> > > > Joe >> > > >> > > >> > >> > >
