public class AsMavenPlugin extends ProjectPlugin
Downloads a set of artifacts from a p2 repository and stuffs them into a local maven repository in the build/p2asmaven
folder, then adds this repository to the project.
apply plugin: 'com.diffplug.gradle.p2.asmaven'
p2AsMaven {
// the maven group they shall have
group 'eclipse-deps', {
// the repositories and artifacts to download
repoEclipse '4.5.2'
iu 'org.eclipse.jdt.core'
}
}
dependencies {
compile 'eclipse-deps:org.eclipse.jdt.core:+'
}
You can also specify multiple groups, as such
def SUPPORTED_VERSIONS = ['4.4', '4.5', '4.6']
p2AsMaven {
for (version in SUPPORTED_VERSIONS) {
group 'eclipse-deps-' + version, {
repoEclipse version
iu 'org.eclipse.swt'
// this will cause any OSGi jars which ask to be expanded into
// folders to be exploded, e.g. Eclipse-BundleShape: dir
repo2runnable()
}
}
}
// build folder will look like this:
build/p2AsMaven/
maven/
eclipse-deps-4.4/
eclipse-deps-4.5/
eclipse-deps-4.6/
p2/
eclipse-deps-4.4/
eclipse-deps-4.5/
eclipse-deps-4.6/
p2runnable/
eclipse-deps-4.4/
eclipse-deps-4.5/
eclipse-deps-4.6/
The maven repository does not contain any dependency information, just the raw jars. In the example above, when p2 downloads org.eclipse.jdt.core
, it also downloads all of its dependencies. But none of these dependencies are added automatically - you have to add them yourself.
Inspired by Andrey Hihlovskiy’s unpuzzle. Unpuzzle downloads a zipped-up copy of the eclipse IDE and stuffs its jars into a maven repository. Additionally, it parses out the Require-Bundle
directives to put partial dependency information in the maven metadata.
Simon Templer has a fork which supports parsing the Import-Package
and Export-Package
directive to build even more detailed dependency information.
A third option is Dr. David Akehurst’s p2 dependency resolver, which is a partial re-implementation of P2, and uses internal gradle APIs to hook into Gradle’s dependency resolution. It’s very impressive, but it has a few limitations:
All of the above are great work, and served as useful examples. The central problem which is the cause of so many not-quite-satisfying implementations is this:
In Goomph, we will always use the real p2. While we work around limitations in gradle and p2, we will only use public APIs in both products.
Constructor and Description |
---|
AsMavenPlugin() |
Modifier and Type | Method and Description |
---|---|
protected void |
applyOnce(Project project)
Plugin application, which is guaranteed to execute only once.
|
AsMavenExtension |
extension() |
apply, getPlugin, treeDef
protected void applyOnce(Project project)
ProjectPlugin
Plugin application, which is guaranteed to execute only once.
applyOnce
in class ProjectPlugin
public AsMavenExtension extension()