Community
Participate
Working Groups
Eclipse Platform has switched to using the Bouncy Castle (1.72) artifacts from maven instead of the repackaging provided by Eclipse Orbit. Should JGit to follow suit? Using tycho >= 2.7.5 (which we do), it's possible to do so by including the maven coordinates in the target platform. Using the latest CBI TPD, it's also possible to use TPD files containing maven coordinates to create the target platforms. I have two uncertainties: 1. Will the dash license tool be happy about this? Probably. 2. What happens when one installs EGit (which would have to change its target platform and thus its p2 repository, too) in an older Eclipse that has the Orbit versions of Bouncy Castle? The maven bundles have different bundle names; instead of "org.bouncycastle.bcpg" they use only "bcpg". Would this cause trouble? Note that both JGit and EGit have only Import-Package for BC, no Require-Bundle. The package names in the maven artifacts are identical, but Automatic-Module-Name may be different, too.
If this works with tpd files I am all in for this proposal since it allows us to continue maintaining target platforms for older Eclipse versions as we do today. If this works for bouncycastle we should do this also for all other dependencies which already have OSGi manifests. I don't expect a lot of issues with different bundle names since we mostly use package imports. Do you have pointers to documentation and examples how to do this ?
I have already done this locally. Hadn't found any documentation, I just looked at the TPD grammar at [1] :-). (Not too happy with that grammar, it's way too verbose for maven -- not much better than POM dependencies. Could have used a much more concise syntax using short-hand coordinates like "groupId:artifactId:version". But it does the job.) Basically, use the latest TPD, then define for instance (this is what I did locally) a new file maven/bouncycastle.tpd with contents target "bouncycastle" with source configurePhase maven bouncycastle scope = compile dependencyDepth = none missingManifest = error includeSources { dependency { groupId = "org.bouncycastle" artifactId = "bcpg-jdk18on" version = "1.72.2" } dependency { groupId = "org.bouncycastle" artifactId = "bcprov-jdk18on" version = "1.72" } dependency { groupId = "org.bouncycastle" artifactId = "bcpkix-jdk18on" version = "1.72" } dependency { groupId = "org.bouncycastle" artifactId = "bcutil-jdk18on" version = "1.72" } } Then remove the Orbit BC bundles from orbit/R20230302014618-2023-03.tpd, and iclude maven/bouncycastle.tpd in the top-level TPD files. Change the bundle ids in category.xml (in the p2 repo bundle) from "org.bouncycastle.bc*" to just "bc*". Regenerate target platform files. Rebuild. Done. The thing with the different bundle names does worry me, but in the end I fear I'll just have to try installing from a locally built p2 repo into an older Eclipse to see what happens. (Probably one can't use key classes from the new maven BC with keys returned from a "BC" security provider installed by the old Orbit bundle. If both old and new bcprov are present, I do expect trouble depending on which one installs the security provider.) [1] https://github.com/eclipse-cbi/targetplatform-dsl/blob/master/org.eclipse.cbi.targetplatform/src/main/java/org/eclipse/cbi/targetplatform/TargetPlatform.xtext
(In reply to Thomas Wolf from comment #2) > I have already done this locally. Hadn't found any documentation, I just > looked at the TPD grammar at [1] :-). (Not too happy with that grammar, it's > way too verbose for maven -- not much better than POM dependencies. Could > have used a much more concise syntax using short-hand coordinates like > "groupId:artifactId:version". But it does the job.) > > Basically, use the latest TPD, then define for instance (this is what I did > locally) a new file > > maven/bouncycastle.tpd I'd name this something like maven/dependencies.tpd and later add all the other dependencies we can directly consume from maven > > with contents > > target "bouncycastle" with source configurePhase > > maven bouncycastle > scope = compile > dependencyDepth = none > missingManifest = error > includeSources > { > dependency { > groupId = "org.bouncycastle" > artifactId = "bcpg-jdk18on" > version = "1.72.2" > } > dependency { > groupId = "org.bouncycastle" > artifactId = "bcprov-jdk18on" > version = "1.72" > } > dependency { > groupId = "org.bouncycastle" > artifactId = "bcpkix-jdk18on" > version = "1.72" > } > dependency { > groupId = "org.bouncycastle" > artifactId = "bcutil-jdk18on" > version = "1.72" > } > } > > Then remove the Orbit BC bundles from orbit/R20230302014618-2023-03.tpd, and > iclude maven/bouncycastle.tpd in the top-level TPD files. Change the bundle > ids in category.xml (in the p2 repo bundle) from "org.bouncycastle.bc*" to > just "bc*". Regenerate target platform files. Rebuild. Done. > > The thing with the different bundle names does worry me, but in the end I > fear I'll just have to try installing from a locally built p2 repo into an > older Eclipse to see what happens. (Probably one can't use key classes from > the new maven BC with keys returned from a "BC" security provider installed > by the old Orbit bundle. If both old and new bcprov are present, I do expect > trouble depending on which one installs the security provider.) > > [1] > https://github.com/eclipse-cbi/targetplatform-dsl/blob/master/org.eclipse. > cbi.targetplatform/src/main/java/org/eclipse/cbi/targetplatform/ > TargetPlatform.xtext
New Gerrit change created: https://git.eclipse.org/r/c/jgit/jgit/+/201348
Gerrit change https://git.eclipse.org/r/c/jgit/jgit/+/201348 was merged to [master]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=bf201be0beb284707db0f500e5850be56f966b15
