Skip to main content
AgeCommit message (Collapse)AuthorFilesLines
2019-04-01.gitignore: remove editor- and OS-specific filesMatthew DeVore1-2/+5
Whenever Vim opens a file, it creates a .<filename>.swp file in the same directory as the file. Emacs adds *~ backup files. macOS creates .DS_Store files. Other editors and OS' surely do their own thing. Rather than add each one's own swap/backup file to this .gitignore, encourage users to add the corresponding items to their system-wide gitignore files. Change-Id: I5535f5d2f1ebe896eef108cfda087dcb4c50f031 Signed-off-by: Matthew DeVore <>
2017-07-28git ignore .DS_StoreDavid Pursehouse1-0/+1
Change-Id: I04887b91d07ee93f51d27c9a3597e258b9affc0b Signed-off-by: David Pursehouse <>
2017-07-28git ignore all bazel foldersDavid Pursehouse1-5/+1
Change-Id: I38ae02d07020d8ccb8dc1ac4c0fa08ce93512f94 Signed-off-by: David Pursehouse <>
2017-03-21Remove Buck buildDavid Pursehouse1-3/+0
Buck will be replaced with Bazel Change-Id: I3cf07d7aaaa2a58bac34e16c50af5416693254ac Signed-off-by: Matthias Sohn <>
2017-01-18Implement initial framework of Bazel buildDavid Ostrovsky1-0/+6
The initial implementation only builds the packages consumed by Gerrit Code Review. Test build and execution is not implemented. We prefer to consume maven_jar custom rule from bazlets repository, for the same reasons as in the Gerrit project: * Caching artifacts across different clones and projects * Exposing source classifiers and neverlink artifact TEST PLAN: $ bazel build :all $ unzip -t bazel-genfiles/ Archive: bazel-genfiles/ testing: libjgit-archive.jar OK testing: libjgit-servlet.jar OK testing: libjgit.jar OK testing: libjunit.jar OK No errors detected in compressed data of bazel-genfiles/ Change-Id: Ia837ce95d9829fe2515f37b7a04a71a4598672a0 Signed-off-by: David Ostrovsky <> Signed-off-by: David Pursehouse <>
2016-12-18Ignore infer output folderMatthias Sohn1-0/+1
Infer [1] is a static code checker. [1] Change-Id: I880cefe0a20f6af88ab10f6e862fda44fbe0883d Signed-off-by: Matthias Sohn <>
2016-04-19Add .buckd to .gitignoreDave Borowitz1-1/+2
Change-Id: I527923e282808c905ae9acd128ecc8a5b33d34c7
2015-12-31Implement Buck driven buildDavid Ostrovsky1-0/+2
Today there are plenty of modern build tool systems available in the wild (in no particular order): * * * * * The attributes, that all these build tools have in common, are: * reliable * correct * very fast * reproducible It must not always be the other build tool, this project is currently using. Or, quoting Gerrit Code Review maintainer here: "Friends, don't let friends use <the other build tool system>!" This change is non-complete implementation of JGit build in Buck, needed by Gerrit Code Review to replace its dependency with standlone JGit cell. This is very useful when a developer is working on both projects and is trying to integrate changes made in JGit in Gerrit. The supported workflow is: $ cd jgit $ emacs <hack> $ cd ../gerrit $ buck build --config repositories.jgit=../jgit gerrit With --config repositories.jgit=../jgit jgit cell is routed through JGit development tree. To build jgit, issue: $ buck build //:jgit [-] PROCESSING BUCK FILES...FINISHED 0,0s Yes, you can't measure no-op build time, given that Buck daemon is used. Change-Id: I301a71b19fba35a5093d8cc64d4ba970c2877a44 Signed-off-by: David Ostrovsky <>
2015-10-18Adding AES Walk Encryption support in modeAndrei Pozolotin1-0/+1
See previous attempt: Here we preserve as much of JetS3t mode as possible while allowing to use new Java 8+ PBE algorithms such as PBEWithHmacSHA512AndAES_256 Summary of changes: * change pom.xml to control long tests * add WalkEncryptionTest.launch to run long tests * add AmazonS3.Keys to to normalize use of constants * change WalkEncryption to support AES in JetS3t mode * add WalkEncryptionTest to test remote encryption pipeline * add support for CI configuration for live Amazon S3 testing * add log4j based logging for tests in both Eclipse and Maven build To test locally, check out the review branch, then: * create amazon test configuration file * located your home dir: ${user.home} * named * file format follows AmazonS3 connection settings file: accesskey = your-amazon-access-key secretkey = your-amazon-secret-key test.bucket = your-bucket-for-testing * finally: * run in Eclipse: WalkEncryptionTest.launch * or * run in Shell: mvn test --define test=WalkEncryptionTest Change-Id: I6f455fd9fb4eac261ca73d0bec6a4e7dae9f2e91 Signed-off-by: Andrei Pozolotin <>
2012-03-06Ignore /targetShawn O. Pearce1-0/+1
Maven seems to be creating target/antrun/build-main.xml. This isn't a tracked file. Elsewhere we blanket ignore /target inside of each plugin/component directory so do the same at the top level. Change-Id: Id799ac6da65e6789e48e28efbdb455153b34ff2e Signed-off-by: Chris Aniszczyk <>
2010-01-10Partial revert "Switch build to Apache Felix maven-bundle-plugin"Robin Rosenberg1-2/+0
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 <>
2009-12-28Switch build to Apache Felix maven-bundle-pluginShawn O. Pearce1-0/+2
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/ 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 <>
2009-11-02Refactor our Maven build to be modularShawn O. Pearce1-6/+0
Drop our simple and stupid and instead rely upon Maven for the command line based build. Maven is relatively simple to download and install, and doesn't require the entire Eclipse IDE. To avoid too much refactoring of the current code we reuse the existing src/ directory within each plugin, and treat each of the existing OSGI bundles as one Maven artifact. The command line wrapper no longer works in the uncompiled state, as we don't know where to obtain our JSch or args4j from. Developers will now need to compile it with `mvn package`, or run our Main class from within an IDE which has the proper classpath. Bug: 291265 Change-Id: I355e95fa92fa7502651091d2b651be6917a26805 Signed-off-by: Shawn O. Pearce <>
2009-09-29Initial JGit contribution to eclipse.orgGit Development Community1-0/+6
Per CQ 3448 this is the initial contribution of the JGit project to It is derived from the historical JGit repository at commit 3a2dd9921c8a08740a9e02c421469e5b1a9e47cb. Signed-off-by: Shawn O. Pearce <>

    Back to the top