github/jgit - jgit - 帆软第三方插件仓库

Commit Graph

Author	SHA1	Message	Date
Jonathan Nieder	56276d053f	Move ArchiveCommand into standard porcelain API Allow use of ArchiveCommand without depending on the jgit command-line tools. To avoid complicating the process of installing and upgrading JGit, this does not add a dependency by the org.eclipse.jgit bundle on commons-compress. Instead, the caller is responsible for registering any formats they want to use by calling ArchiveCommand.registerFormat. This patch puts functionality that requires an archiver into a separate org.eclipse.jgit.archive bundle for people who want it. One can use it by calling ArchiveCommand.registerFormat directly to register its formats or by relying on OSGi class loading to load org.eclipse.jgit.archive.FormatActivator, which takes care of registration automatically. Once the appropriate formats are registered, you can make a tar or zip from a git tree object as follows: ArchiveCommand cmd = git.archive(); try { cmd.setTree(tree).setFormat(fmt).setOutputStream(out).call(); } finally { cmd.release(); } Change-Id: I418e7e7d76422dc6f010d0b3b624d7bec3b20c6e	12 years ago
Robin Rosenberg	dd3181603e	Extend the FS class for Java7 The most important difference is that in Java7 we have symbolic links and for most operations in the work tree we want to operate on the link itself rather than the link target, which the old File methods generally do. We also add support for the hidden attribute, which only makes sense on Windows and exists, just since there are claims that Files.exists is faster the File.exists. A new bundle is only activated when run with a Java7 execution environment. It is implemented as a fragment. Tycho currently has no way to conditionally include optional features based on the java version used to run the build, this means with this change the jgit packaging build always needs to be run using java 7. Change-Id: I3d6580d6fa7b22f60d7e54ab236898ed44954ffd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>	12 years ago
Matthias Sohn	f2d0b50e0a	Fix line endings Change-Id: I61c9c173237a535da8576a9299bfd4bb29e8f56b Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>	12 years ago
Jens Baumgart	51e2646d4a	Introduce http test bundle Introduce a http test bundle to make this functionality available for EGit tests. A simple http server class is provided. The jetty version was updated to a version that is also available via p2 (needed in EGit UI tests). Change-Id: I13bfc4c6c47e27d8f97d3e9752347d6d23e553d4 Signed-off-by: Jens Baumgart <jens.baumgart@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>	14 years ago
Robin Rosenberg	5eac1a4896	Partial revert "Switch build to Apache Felix maven-bundle-plugin" This restores the ability to build using just Eclipse without strange procedures, extra plugins and it is again possible to work on both JGit and EGit in the same Eclipse workspace with ease. Change-Id: I0af08127d507fbce186f428f1cdeff280f0ddcda Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>	15 years ago
Shawn O. Pearce	fc5fc70e2e	Switch build to Apache Felix maven-bundle-plugin Tycho isn't production ready for projects like JGit to be using as their primary build driver. Some problems we ran into with Tycho 0.6.0 that are preventing us from using it are: * Tycho can't run offline The P2 artifact resolver cannot perform its work offline. If the build system has no network connection, it cannot compile a project through Tycho. This is insane for a distributed version control system where developers are used to being offline during development and local testing. * Magic state in ~/.m2/repository/.meta/p2-metadata.properties Earlier iterations of this patch tried to use a hybrid build, where Tycho was only used for the Eclipse specific feature and P2 update site, and maven-bundle-plugin was used for the other code. This build seemed to work, but only due to magic Tycho specific state held in my local home directory. This means builds are not consistently repeatable across systems, and lead me to believe I had a valid build, when in fact I did not. * Manifest-first build produces incomplete POMs The POM created by the manifest-first build format does not contain the dependency chain, leading a downstream consumer to not import the runtime dependencies necessary to execute the bundle it has imported. In JGit's case, this means JSch isn't included in our dependency chain. * Manifest-first build produces POMs unreadable by Maven 2.x JGit has existing application consumers who are relying on Maven 2.x builds. Forcing them to step up to an alpha release of Maven 3 is simply unacceptable. * OSGi bundle export data management is tedious Editing each of our pom.xml files to mark a new release is difficult enough as it is. Editing every MANIFEST.MF file to list our exported packages and their current version number is something a machine should do, not a human. Yet the Tycho OSGi way unfortunately demands that a human do this work. * OSGi bundle import data management is tedious There isn't a way in the MANIFEST.MF file format to reuse the same version tags across all of our imports, but we want to have a consistent view of our dependencies when we compile JGit. After wasting more than 2 full days trying to get Tycho to work, I've decided its a lost cause right now. We need to be chasing down bugs and critical features, not trying to bridge the gap between the stable Maven repository format and the undocumented P2 format used only by Eclipse. So, switch the build to use Apache Felix's maven-bundle-plugin. This is the same plugin Jetty uses to produce their OSGi bundle manifests, and is the same plugin used by the Apache Felix project, which is an open-source OSGi runtime. It has a reasonable number of folks using it for production builds, and is running on top of the stable Maven 2.x code base. With this switch we get automatically generated MANIFEST.MF files based on reasonably sane default rules, which reduces the amount of things we have to maintain by hand. When necessary, we can add a few lines of XML to our POMs to tweak the output. Our build artifacts are still fully compatible with Maven 2.x, so any downstream consumers are still able to use our build products, without stepping up to Maven 3.x. Our artifacts are also valid as OSGi bundles, provided they are organized on disk into a repository that the runtime can read. With maven-bundle-plugin the build runs offline, as much as Maven 2.x is able to run offline anyway, so we're able to return to a distributed development environment again. By generating MANIFEST.MF at the top level of each project (and therefore outside of the target directory), we're still compatible with Eclipse's PDE tooling. Our projects can be imported as standard Maven projects using the m2eclipse plugin, but the PDE will think they are vaild plugins and make them available for plugin builds, or while debugging another workbench. This change also completely removes Tycho from the build. Unfortunately, Tycho 0.6.0's pom-first dependency resolver is broken when resolving a pom-first plugin bundle through a manifest-first feature package, so bundle org.eclipse.jgit can't be resolved, even though it might actually exist in the local Maven repository. Rather than fight with Tycho any further, I'm just declaring it plugina-non-grata and ripping it out of the build. Since there are very few tools to build a P2 format repository, and no documentation on how to create one without running the Eclipse UI manually by poking buttons, I'm declaring that we are not going to produce a P2 update site from our automated builds. Change-Id: If7938a86fb0cc8e25099028d832dbd38110b9124 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	15 years ago
Shawn O. Pearce	7e8dc53881	Prompt for passwords from the console in jgit command line tools If we are on a Java 6 JVM we should have the Console class available, unless the user has redirected /dev/null to stdin. When there is a console present we would prefer to use that for command line prompts as that is what the user expects from a command line tool. Change-Id: Ibaf87bb5540371d94d96d1b7e94ca002f752e5bd Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	15 years ago
Shawn O. Pearce	49aac32500	Create JUnit test utilities for JGit derived sources The LocalDiskRepositoryTestCase class is derived from the current RepositoryTestCase code and is meant for application (or our own) tests to subclass and access temporary repositories on the local client disk. Change-Id: Idff096cea40a7b2b56a90fb5de179ba61ea3a0eb Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	15 years ago
Shawn O. Pearce	5b89088f87	Switch pgm, test to proper plugin projects This way we depend upon the MANIFEST.MF to define our classpath and our build will act more like any other OSGI bundle build. Change-Id: I9e1f1f5a0bccb0ab0e39e49b75fb400fea446619 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	15 years ago
Mykola Nikishov	cf2edb6518	Move AWT UI code to new org.eclipse.jgit.ui bundle This new UI bundle contains the org.eclipse.jgit.awtui package, which was moved out of the org.eclipse.jgit bundle. org.eclipse.jgit.pgm depends on org.eclipse.jgit.ui, so we need to update the classpath and make_jgit.sh to include it. This move takes the awtui classes out of the Maven build, which means we are no longer able to distribute these classes to our downstream Maven customers. The entire Maven package structure needs to be overhauled so that Eclipse bundle matches 1:1 with the Maven artifact. Bug: https://bugs.eclipse.org/291124 Change-Id: Ibf1a9968387e3d11fdce54592f710ec4cc7f1ddb Signed-off-by: Mykola Nikishov <mn@mn.com.ua> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	15 years ago
Git Development Community	1a6964c827	Initial JGit contribution to eclipse.org Per CQ 3448 this is the initial contribution of the JGit project to eclipse.org. It is derived from the historical JGit repository at commit 3a2dd9921c8a08740a9e02c421469e5b1a9e47cb. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	15 years ago

1 Commits (5639639b06c004d18415f59a271319da2fb7b930)