This is the format given by the Eclipse legal doc generator [1].

[1] https://www.eclipse.org/projects/tools/documentation.php?id=technology.jgit

Bug: 548298
Change-Id: I8d8cabc998ba1b083e3f0906a8d558d391ffb6c4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Factor out the test parameterization to use both connection factories
into a common super class and use it in more tests.

This made HttpClientTests.testV2HttpSubsequentResponse() fail for
Apache HTTP. The test used the pattern

  - create POST connection
  - setDoOutput(true)
  - connect()
  - write output stream
  - get & read input stream

This pattern is never used in JGit, which actually calls connect() only
in one case in LFS, and that's on a HEAD request.

The above pattern works on JDK, but fails on Apache HTTP because with
Apache HTTP a connect() actually executes the full request including
writing the entity. To work with Apache HTTP, the pattern would need
to be

  - create POST connection
  - setDoOutput(true)
  - write output stream
  - connect()
  - get & read input stream

which is fine for both. JDK connects implicitly in getOutputStream()
and treats the later explicit connect() as a no-op, and Apache works
because the entity is written when connect() is called.

Because JDK connects implicitly on getOutputStream(), the following
pattern also works with JDK:

  - create POST connection
  - setDoOutput(true)
  - write output stream
  - get & read input stream

Support this with Apache HTTP too: let getInputStream() execute
the request if it wasn't executed already.

Remove explicit connect() calls from test code, since JGit doesn't do
those either.

Change-Id: Ica038c00a7b8edcc01d5660d18e961146305b87f
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

When an auto-closeable resources is not opened in try-with-resource,
the warning "should be managed by try-with-resource" is emitted by
Eclipse.

Fix the ones that can be silenced simply by moving the declaration of
the variable into a try-with-resource.

In cases where we explicitly call the close() method, for example in
tests where we are testing specific behavior caused by the close(),
suppress the warning.

Leave the ones that will require more significant refcactoring to fix.
They can be done in separate commits that can be reviewed and tested
in isolation.

Change-Id: I9682cd20fb15167d3c7f9027cecdc82bc50b83c4
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Since the introduction of generic type parameter inference in Java 7,
it's not necessary to explicitly specify the type of generic parameters.

Enable the warning in Eclipse, and fix all occurrences.

Change-Id: I9158caf1beca5e4980b6240ac401f3868520aad0
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Set missingOverrideAnnotation=warning in Eclipse compiler preferences
which enables the warning:

  The method <method> of type <type> should be tagged with @Override
  since it actually overrides a superclass method

Justification for this warning is described in:

  http://stackoverflow.com/a/94411/381622

Enabling this causes in excess of 1000 warnings across the entire
code-base. They are very easy to fix automatically with Eclipse's
"Quick Fix" tool.

Fix all of them except 2 which cause compilation failure when the
project is built with mvn; add TODO comments on those for further
investigation.

Change-Id: I5772061041fd361fe93137fd8b0ad356e748a29c
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Signed-off-by: Bogdan Gheorghe <gheorghe@ca.ibm.com>
Change-Id: I1047f318bb5c63850f45ba85d73c97fe8bf70a6c