summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test/build.properties
Commit message (Collapse)AuthorAgeFilesLines
* Update slf4j to 1.7.36 and consume it directly from Maven CentralMatthias Sohn2023-05-021-1/+1
| | | | | | | | BundleSymbolicNames changed to the names used upstream: - slf4j.api - slf4j.simple Change-Id: Ibcaafae282d3a6fa013bc39d879def1b66073bca
* Use slf4j-simple instead of log4j for loggingMatthias Sohn2021-12-311-2/+1
| | | | | | | | | | | | | | | | | | | | | JGit uses slf4j-api as logging API. The libraries - org.eclipse.jgit.http.test - org.eclipse.jgit.pgm - org.eclipse.jgit.ssh.apache.test - org.eclipse.jgit.test used the outdated log4j 1.2.15 which is EOL since years. Since both jgit command line and also the tests don't need sophisticated logging features replace log4j with the much simpler slf4j-simple log implementation. The org.slf4j.binding.simple 1.7.30 archive has only 25kB instead of 429kB for log4j 1.2.15 Applications using jgit are free to choose any other log implementation supporting slf4j API. Change-Id: I89e85cd3c76e954c3434622510975ce65dc227d4
* Update slf4j to 1.7.30Matthias Sohn2020-10-281-1/+1
| | | | | Bug: 566475 Change-Id: Ia3e5b72d53ead435e4677e46c73a3ff45a606b41 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Decouple JSch from JGit CoreMatthias Sohn2020-06-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | Motivation: JSch serves as 'default' implementations of the SSH transport. If a client application does not use it then there is no need to pull in this dependency. Move the classes depending on JSch to an OSGi fragment extending the org.eclipse.jgit bundle and keep them in the same package as before since moving them to another package would break API. Defer moving them to a separate package to the next major release. Add a new feature org.eclipse.jgit.ssh.jsch feature to enable installation. With that users can now decide which of the ssh client integrations (JCraft JSch or Apache Mina SSHD) they want to install. We will remove the JCraft JSch integration in a later step due to the reasons discussed in bug 520927. Bug: 553625 Change-Id: I5979c8a9dbbe878a2e8ac0fbfde7230059d74dc2 Also-by: Michael Dardis <git@md-5.net> Signed-off-by: Michael Dardis <git@md-5.net> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: David Ostrovsky <david@ostrovsky.org>
* Apache MINA sshd clientThomas Wolf2018-11-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Add a new ssh client implementation based on Apach MINA sshd 2.0.0. This implementation uses JGit's own config file parser and host entry resolver. Code inspection of the Apache MINA implementation revealed a few bugs or idiosyncrasies that immediately would re-introduce bugs already fixed in the past in JGit. Apache MINA sshd is not without quirks either, and I had to configure and override more than I had expected. But at least it was all doable in clean ways. Apache MINA boasts support for Bouncy Castle, so in theory this should open the way to using more ssh key algorithms, such as ed25519. The implementation is in a separate bundle and is still not used in the core org.eclipse.jgit bundle. The tests re-use the ssh tests from the core test bundle. Bug: 520927 Change-Id: Ib35e73c35799140fe050d1ff4fb18d0d3596580e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Fix test setup for Eclipse Photon and greaterThomas Wolf2018-11-021-1/+3
| | | | | | | | | | | | | | When a source folder is marked as a test folder, JDT requires that it has an output folder different from the one used for regular sources. Therefore give the test folders in org.eclipse.jgit.test a separate output folder "bin-tst". Moreover JDT reports errors if non-test classes have dependencies on test classes. Therefore remove the "test" annotation from org.eclipse.jgit.junit. Change-Id: Ib527439ff5b7d7b570b8a60819ecaa70f59c63a3 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Add missing dependency to slf4j-log4j bridgeMatthias Sohn2016-09-051-1/+2
| | | | | | Without the bridge JGit tests don't show log output in Eclipse console. Change-Id: I7acce1f1787960b5ca98377cb5c7f599a8a220b5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add path src/ to source path in build.propertiesMatthias Sohn2016-08-061-1/+2
| | | | | | This fixes the warning "src/ is missing from source.." Change-Id: I166e3a6a3d5230e4110d3283ec4dbc7d1dfe6732 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Adding AES Walk Encryption support in http://www.jets3t.org/ modeAndrei Pozolotin2015-10-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See previous attempt: https://git.eclipse.org/r/#/c/16674/ 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 jgit-s3-config.properties * 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 <andrei.pozolotin@gmail.com>
* Partial revert "Switch build to Apache Felix maven-bundle-plugin"Robin Rosenberg2010-01-101-0/+6
| | | | | | | | | | 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>
* Switch build to Apache Felix maven-bundle-pluginShawn O. Pearce2009-12-281-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Refactor org.eclipse.jgit.test to be a bundleChris Aniszczyk2009-10-161-0/+6
This way dependencies are described by the MANIFEST.MF, and the same build tools can be used to compile the tests. Change-Id: I4dc926148410ecbadcf71b9474aeeb509691aa32