This reverts commit 0c6e7d7127 which
didn't work since package imports need to be different with Jetty 7.5
and 7.6. Jetty 7.6 can be installed into Eclipse SDK 3.7.2 so rather
require Jetty 7.6 instead of adding a lot of reflective code to
workaround these incompatible changes.
Change-Id: I7eb6413ecf2bc4ad7bef0c70cde45ae3fde02b2f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Class Constraint was moved from package org.eclipse.jetty.http.security
in Jetty 7.5 to package org.eclipse.jetty.util.security in Jetty 7.6.
Hence also import package org.eclipse.jetty.security, then also Jetty
7.5, coming with Indigo, can be used to run JGit HTTP tests.
Change-Id: I26c38ec9f51b0a4fb62e1aa9f2266ada7bb2fa0c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This reverts commit 24a0f47e32 and
updates JGit dependencies to use the latest available Jetty 7.x
release. We can't use Jetty 8.x since it depends on Servlet API 3.0
which requires Java 6 but JGit still wants to support Java 5.
Use one of the target platforms defined in
Ibf67a6d3539fa0708a3e5dbe44fb899c56fbd8ed to work with that in Eclipse.
Change-Id: I343273d994dc7b6e0287c604e5926ff77d5b585b
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This never should have been in the core library test suite, as that
test suite never should depend upon the HTTP server module.
Change-Id: Ie0528c4d1c755823303d138e327a3a2f4caccc32
The package was removed in I763590a45d75f00a09097ab6f89581a3bbd3c797
Change-Id: Ifa9e75714f85d17609f9bf61581aaed0631a6fa7
Signed-off-by: Kevin Sawicki <kevin@github.com>
This only works with Eclipse 3.6 and newer and requires installation
of new package. Documentation is not very good, but there is a blog
about it here:
http://eclipseandjazz.blogspot.com/2011/10/of-invalid-references-to-system.html
API checking is especially useful on OS X where Java5 is not readily
available.
Change-Id: I3c0ad460874a21c073f5ac047146cbf5d31992b4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Error messages are typically short, below the 32 KiB in-memory buffer
size of the SmartOutputStream. When an error is queued up for sending
to a client and an exception is thrown up into the servlet handler we
discarded the message and sent nothing to the client, as the messages
were stuck inside of the SmartOutputStream buffer.
Hoist the creation of the output stream above the invocation of try
block of the service, and use close() in the few catch blocks that
assume there are buffered messages ready for transmission. This will
ensure errors from unpacking a stream in ReceivePack are sent off to
a client correctly, as previously these were causing no status report
to arrive at the client side as the data was stuck in the buffer.
Change-Id: I5534b560697731121f48979ae077aa7c95b8e39c
I modified the way errors are returned, and this particular test is
now getting a different access denied response. The new text happens
to be what I intended to have here, so update the test.
Change-Id: I53f8410ca0a52755d80473cd5cbcdb4d8502febf
We should use a template for Mylyn commit messages that matches with our
guidelines for commit messages.
http://wiki.eclipse.org/EGit/Contributor_Guide#Commit_message_guidelines
Bug: 337401
Change-Id: I05812abf0eb0651d22c439142640f173fc2f2ba0
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
It's useful to have ReflogEntry refactored out so it can be
used by clients via the JGit API.
Change-Id: I03044df9af9f9547777545b7c9b93bdf5f8b7cb5
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Smart HTTP clients may request both multi_ack_detailed and no-done in
the same request to prevent the client from needing to send a "done"
line to the server in response to a server's "ACK %s ready".
For smart HTTP, this can save 1 full HTTP RPC in the fetch exchange,
improving overall latency when incrementally updating a client that
has not diverged very far from the remote repository.
Unfortuantely this capability cannot be enabled for the traditional
bi-directional connections. multi_ack_detailed has the client sending
more "have" lines at the same time that the server is creating the
"ACK %s ready" and writing out the PACK stream, resulting in some race
conditions and/or deadlock, depending on how the pipe buffers are
implemented. For very small updates, a server might actually be able
to send "ACK %s ready", then the PACK, and disconnect before the
client even finishes sending its first batch of "have" lines. This
may cause the client to fail with a broken pipe exception. To avoid
all of these potential problems, "no-done" is restricted only to the
smart HTTP variant of the protocol.
Change-Id: Ie0d0a39320202bc096fec2e97cb58e9efd061b2d
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Matthias Sohn
Dave Borowitz
Shawn O. Pearce
Tomasz Zarna
Robin Rosenberg
Chris Aniszczyk