github
/
jgit
mirror of https://gitee.com/github-mirror-repo/jgit.git
1
0
Fork 0
Code Issues Releases Wiki Activity
纯java实现的git操作库。
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
5284 Commits
45 Branches
0 Tags
37 MiB
Tree: 8abb47b296
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '8abb47b296'
${ noResults }
jgit/org.eclipse.jgit.http.test/META-INF/MANIFEST.MF

49 lines
2.4 KiB
Raw Normal View History Unescape

Make HTTP test project work in Eclipse The Jetty components are not available as part of Eclipse, but a P2 packaged version can be found via [1] for Eclipse 3.5 and newer. [1] http://wiki.eclipse.org/Jetty-OSGi_SDK Change-Id: Ibd5930bb9fc9589125876ca50c52e58bd31b051c Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
15 years ago
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Correct bundle, provider names to be consistent Technically our project name is "JGit", not "Java Git". In fact there is already another project called "JavaGit" (no space) that we don't want to become confused with. Ensure we always call ourselves "JGit" in user visible assets, like the bundle name. Other Eclipse products list their provider as "Eclipse.org", not "eclipse.org". So list ourselves that way in all of our plugin.properties files. Change-Id: Ibcea1cd6dda2af757a8584099619fc23b7779a84 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
15 years ago
Bundle-Name: %plugin_name
Make HTTP test project work in Eclipse The Jetty components are not available as part of Eclipse, but a P2 packaged version can be found via [1] for Eclipse 3.5 and newer. [1] http://wiki.eclipse.org/Jetty-OSGi_SDK Change-Id: Ibd5930bb9fc9589125876ca50c52e58bd31b051c Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
15 years ago
Bundle-SymbolicName: org.eclipse.jgit.http.test
Prepare 4.9.0-SNAPSHOT builds Change-Id: I52a4153d573799e861ab104939f51fac1aceb9ee Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
8 years ago
Bundle-Version: 4.9.0.qualifier
Correct bundle, provider names to be consistent Technically our project name is "JGit", not "Java Git". In fact there is already another project called "JavaGit" (no space) that we don't want to become confused with. Ensure we always call ourselves "JGit" in user visible assets, like the bundle name. Other Eclipse products list their provider as "Eclipse.org", not "eclipse.org". So list ourselves that way in all of our plugin.properties files. Change-Id: Ibcea1cd6dda2af757a8584099619fc23b7779a84 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
15 years ago
Bundle-Vendor: %provider_name
Bundle-Localization: plugin
Change JGit minimum execution environment to JavaSE-1.8 Bug: 500059 Change-Id: I47f3f6749a67da52029f84e002d9b155ed56d2b7 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
8 years ago
Bundle-RequiredExecutionEnvironment: JavaSE-1.8
Update javax.servlet to 3.1 Change-Id: Ifad154ed2f52f0102d297ac7fd4943ff1f309b9e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
10 years ago
Import-Package: javax.servlet;version="[2.5.0,3.2.0)",
javax.servlet.http;version="[2.5.0,3.2.0)",
Do authentication re-tries on HTTP POST There is at least one git server out there (GOGS) that does not require authentication on the initial GET for info/refs?service=git-receive-pack but that _does_ require authentication for the subsequent POST to actually do the push. This occurs on GOGS with public repositories; for private repositories it wants authentication up front. Handle this behavior by adding 401 handling to our POST request. Note that this is suboptimal; we'll re-send the push data at least twice if an authentication failure on POST occurs. It would be much better if the server required authentication up-front in the GET request. Added authentication unit tests (using BASIC auth) to the SmartClientSmartServerTest: - clone with authentication - clone with authentication but lacking CredentialsProvider - clone with authentication and wrong password - clone with authentication after redirect - clone with authentication only on POST, but not on GET Also tested manually in the wild using repositories at try.gogs.io. That server offers only BASIC auth, so the other paths (DIGEST, NEGOTIATE, fall back from DIGEST to BASIC) are untested and I have no way to test them. * public repository: GET unauthenticated, POST authenticated Also tested after clearing the credentials and then entering a wrong password: correctly asks three times during the HTTP POST for user name and password, then gives up. * private repository: authentication already on GET; then gets applied correctly initially to the POST request, which succeeds. Also fix the authentication to use the credentials for the redirected URI if redirects had occurred. We must not present the credentials for the original URI in that case. Consider a malicious redirect A->B: this would allow server B to harvest the user credentials for server A. The unit test for authentication after a redirect also tests for this. Bug: 513043 Change-Id: I97ee5058569efa1545a6c6f6edfd2b357c40592a Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
8 years ago
org.apache.commons.codec;version="1.6.0",
org.apache.commons.codec.binary;version="1.6.0",
Update jetty to 9.4.5 * Adapt to API removals in jetty 9.4+ * Manifests changed to restrict jetty to [9.4.5,10.0.0) Bug: 514336 Bug: 516514 Change-Id: Ifcfd968084dfa6db0ae07cf541d33a6cdedc1ee2 Signed-off-by: Mat Booth <mat.booth@redhat.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
8 years ago
org.eclipse.jetty.continuation;version="[9.4.5,10.0.0)",
org.eclipse.jetty.http;version="[9.4.5,10.0.0)",
org.eclipse.jetty.io;version="[9.4.5,10.0.0)",
org.eclipse.jetty.security;version="[9.4.5,10.0.0)",
org.eclipse.jetty.security.authentication;version="[9.4.5,10.0.0)",
org.eclipse.jetty.server;version="[9.4.5,10.0.0)",
org.eclipse.jetty.server.handler;version="[9.4.5,10.0.0)",
org.eclipse.jetty.server.nio;version="[9.4.5,10.0.0)",
org.eclipse.jetty.servlet;version="[9.4.5,10.0.0)",
org.eclipse.jetty.util;version="[9.4.5,10.0.0)",
org.eclipse.jetty.util.component;version="[9.4.5,10.0.0)",
org.eclipse.jetty.util.log;version="[9.4.5,10.0.0)",
org.eclipse.jetty.util.security;version="[9.4.5,10.0.0)",
org.eclipse.jetty.util.thread;version="[9.4.5,10.0.0)",
Prepare 4.9.0-SNAPSHOT builds Change-Id: I52a4153d573799e861ab104939f51fac1aceb9ee Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
8 years ago
org.eclipse.jgit.errors;version="[4.9.0,4.10.0)",
org.eclipse.jgit.http.server;version="[4.9.0,4.10.0)",
org.eclipse.jgit.http.server.glue;version="[4.9.0,4.10.0)",
org.eclipse.jgit.http.server.resolver;version="[4.9.0,4.10.0)",
org.eclipse.jgit.internal;version="[4.9.0,4.10.0)",
org.eclipse.jgit.internal.storage.dfs;version="[4.9.0,4.10.0)",
org.eclipse.jgit.internal.storage.file;version="[4.9.0,4.10.0)",
org.eclipse.jgit.junit;version="[4.9.0,4.10.0)",
org.eclipse.jgit.junit.http;version="[4.9.0,4.10.0)",
org.eclipse.jgit.lib;version="[4.9.0,4.10.0)",
org.eclipse.jgit.nls;version="[4.9.0,4.10.0)",
org.eclipse.jgit.revwalk;version="[4.9.0,4.10.0)",
org.eclipse.jgit.storage.file;version="[4.9.0,4.10.0)",
org.eclipse.jgit.transport;version="[4.9.0,4.10.0)",
org.eclipse.jgit.transport.http;version="[4.9.0,4.10.0)",
org.eclipse.jgit.transport.http.apache;version="[4.9.0,4.10.0)",
org.eclipse.jgit.transport.resolver;version="[4.9.0,4.10.0)",
org.eclipse.jgit.util;version="[4.9.0,4.10.0)",
Workaround incompatible refactoring in Jetty 7.6.0 In Jetty 7.6 package org.eclipse.jetty.http.security was renamed to org.eclipse.jetty.util.security [1] breaking compatibility. Compare docs for the package in 7.5.4 [2] and missing part in 7.6.0 [3]. To fix until we switch to Jetty 8, restrict the maximum version to 7.6.0 exclusive. [1] http://dev.eclipse.org/mhonarc/lists/jetty-dev/msg01175.html [2] http://download.eclipse.org/jetty/7.5.4.v20111024/apidocs/ [3] http://download.eclipse.org/jetty/7.6.0.RC4/apidocs/ Change-Id: I82b107ec76e66367e55e2cc20233a7924bf7be9f Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
13 years ago
org.hamcrest.core;version="[1.1.0,2.0.0)",
Add an implementation for HttpConnection using Apache HttpClient This change implements the http connection abstraction with the help of org.apache.http.client.HttpClient. The default implementation used by JGit is still the JDK HttpURLConnection. But now JGit users have the possibility to switch completely to org.apache.httpclient. The reason for this is that in certain (e.g. cloud) environments you are forced to use the org.apache classes. Change-Id: I0b357f23243ed13a014c79ba179fa327dfe318b2 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
11 years ago
org.junit;version="[4.0.0,5.0.0)",
org.junit.runner;version="[4.0.0,5.0.0)",
org.junit.runners;version="[4.0.0,5.0.0)"