The package is not used by the plugin and seems to be missing in the
platform anyway under some conditions, see bug 508321 (newer
org.apache.httpcomponents.httpclient_4.5.2 does NOT include the package,
org.apache.httpcomponents.httpclient_4.3.6 does).
Change-Id: Ida5d926a611812b5177af651b3cf22f1b2519e02
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Test plan:
$ bazel build all
$ unzip -t bazel-genfiles/all.zip
Archive: bazel-genfiles/all.zip
testing: libhttp-apache.jar OK
testing: libjgit-archive.jar OK
testing: libjgit-lfs-server.jar OK
testing: libjgit-lfs.jar OK
testing: libjgit-servlet.jar OK
testing: libjgit.jar OK
testing: libjunit.jar OK
No errors detected in compressed data of bazel-genfiles/all.zip.
Change-Id: I9e6c60898ccc6d2a4557ec7544c297442a9702b4
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Per the interface specification, the getContentLength method should
return -1 if content length is unknown or greater than
Integer.MAX_VALUE.
For chunked transfer encoding, the content length is not included in the
header, hence will cause a NullPointerException when trying to parse the
content length header.
Change-Id: Iaa36b5c146a8d654e364635fa0bd2d14129baf17
Signed-off-by: Zhen Chen <czhen@google.com>
It is necessary to register a socket connection factory to prevent the
"http protocol is not supported" error when connecting over a proxy.
Change-Id: Iedf554acef841f52c1f2e3401ef0a0583ac5253b
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
- raise minimum version for HttpClient packages to 4.3 since some of the
used classes aren't available in older versions
- recompute OSGi uses clauses
Change-Id: I8f0bff1433762561e02f7439db27a6a9e846c290
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
HttpClientConnection uses a TemporaryBufferEntity which uses
TemporaryBuffer.LocalFile to buffer an HttpEntity. It was leaking
temporary files if the buffered entities were larger than 1MB since it
failed to destroy the TemporaryBuffer.LocalFile.
Bug: 500079
Change-Id: Ib963e04efc252bdd0420a5c69b1a19181e9e6169
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Construct the java_application JAR wrapped with the shell script
header. This is enough to clone a repository over HTTPs:
$ buck build :jgit_bin
$ buck-out/gen/jgit_bin/jgit_bin clone https://...
Change-Id: I4aceb4e77b2ec9be76a32ec93d94f2dafe9acce6
Pushing with JGit commandline to e.g. Github failed with "unauthorized"
since HttpUrlConnection calls the configured authenticator implicitly.
The problem is that during a push two requests are sent to the server,
first a GET and then a POST (containing the pack data). The first GET
request sent anonymously is rejected with 401 (unauthorized). When an
Authenticator is installed the java.net classes will use the
Authenticator to ask the user for credentials and retry the request.
But this happens under the hood and JGit level code doesn't see that
this happens.
The next request is the POST but since JGit thinks the first GET request
went through anonymously it doesn't add authentication headers to the
POST request. This POST of course also fails with 401 but since this
request contains a lot of body-data streamed from JGit (the pack file!)
the java.net classes can't simply retry the request with authorization
headers. The whole process fails.
Fix this by using Apache httpclient which doesn't use Authenticator to
retrieve credentials. Instead initialize TransportCommand to use the
default credential provider if no other credentials provider was set
explicitly. org.eclipse.jgit.pgm.Main sets this default for the JGit
command line client.
Change-Id: Ic4e0f8b60d4bd6e69d91eae0c7e1b44cdf851b00
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Clirr doesn't support Java 8 hence use japicmp instead.
See https://github.com/siom79/japicmp
Change-Id: If4b30a6d6aa849b4d6b3b0c900558c609822840c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Andrey Loskutov
David Pursehouse
Matthias Sohn
Zhen Chen
Rüdiger Herrmann
Shawn Pearce