在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称(OpenSource Name):xvik/gradle-pom-plugin开源软件地址(OpenSource Url):https://github.com/xvik/gradle-pom-plugin开源编程语言(OpenSource Language):Groovy 100.0%开源软件介绍(OpenSource Introduction):Gradle POM pluginAboutPlugin simplifies maven-publish plugin usage and corrects generated pom. Plugin should make gradle more familiar for maven users (at least simpler to use). With it, multi-module projects could be organized the same way as maven projects: all dependencies managed in the root project (and, optionally, published as bom). Features:
If you develop If your project is hosted on github you may look at github-info plugin which fills some pom sections for you automatically. Also, you can use java-library generator to setup new project with all plugins configured. Summary
Setupbuildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath 'ru.vyarus:gradle-pom-plugin:2.2.1'
}
}
apply plugin: 'ru.vyarus.pom' OR plugins {
id 'ru.vyarus.pom' version '2.2.1'
} CompatibilityPlugin compiled for java 8, compatible with java 11.
SnapshotsSnapshots may be used through JitPack
For gradle before 6.0 use buildscript {
repositories {
maven { url 'https://jitpack.io' }
}
dependencies {
classpath 'ru.vyarus:gradle-pom-plugin:b5a8aee24f'
}
}
apply plugin: 'ru.vyarus.pom' For gradle 6.0 and above:
UsageIf java,
groovy,
java-library or
java-platform plugins enabled,
plugins {
id 'java' // or groovy or java-library
id 'ru.vyarus.pom'
} plugins {
id 'java-platform'
id 'ru.vyarus.pom'
} in both cases Configuration closures added when maven-publish plugin registered (and so will be available even if you don't use java plugins above and only register maven-publish manually). For example the following is also a valid usage: plugins {
id 'maven-publish'
id 'ru.vyarus.pom'
} Publication must be configured manually, for example: publishing {
publications {
mavenJava(MavenPublication) {
from components.java
}
}
} (see java-lib plugin for automatic publication registration) Maven scopes reference:
Also, see good article describing maven/gradle scope analogies.
DependenciesPlugin fixes dependencies scopes in the generated pom:
Note: in context of gradle For example: plugins {
id: 'java'
id 'ru.vyarus.pom'
}
dependencies {
implementation 'com.foo:dep-compile:1.0'
runtimeOnly 'com.foo:dep-runtime:1.0'
provided 'com.foo:dep-provided:1.0'
optional 'com.foo:dep-optional:1.0'
} Will result in: <dependencies>
<dependency>
<groupId>com.foo</groupId>
<artifactId>dep-compile</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.foo</groupId>
<artifactId>dep-runtime</artifactId>
<version>1.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.foo</groupId>
<artifactId>dep-provided</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.foo</groupId>
<artifactId>dep-optional</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optinoal>true</optinoal>
</dependency>
</dependencies> And plugins {
id: 'java-library'
id 'ru.vyarus.pom'
}
dependencies {
implementation 'com.foo:dep-compile:1.0'
api 'com.foo:dep-api-compile:1.0'
} Will produce: <dependencies>
<dependency>
<groupId>com.foo</groupId>
<artifactId>dep-compile</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.foo</groupId>
<artifactId>dep-api-compile</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
</dependencies> NOTE: scope modifications could be disabled with Provided dependenciesProvided dependencies assumed to be present in target environment or already exists in projects consuming library. Provided dependencies will not be loaded as transitive dependencies, they will exist in pom just for consultation. Additional compileOnlyGradle states that The only application for Plugin does not do anything with Make other scopes as providedIf you already have some other scope and want to identify its dependencies in pom as provided then: configurations.provided.extendsFrom configurations.apt
dependencies {
implementation 'com.google.code.gson:gson:2.6.2'
apt 'org.immutables:gson:2.1.19'
} Suppose <dependencies>
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.6.2</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.immutables</groupId>
<artifactId>gson</artifactId>
<version>2.1.19</version>
<scope>provided</scope>
</dependency>
</dependencies> War pluginGradle war plugin declares it's own
provided configurations Optional dependenciesOptional dependencies supposed to be used for not required dependencies, for example, activating additional features. Additional Feature variantsGradle states that native replacement for optional dependencies is gradle feature variants. For example: java {
registerFeature('someFeature') {
usingSourceSet(sourceSets.main)
}
}
dependencies {
someFeatureImplementation 'com.google.code.findbugs:annotations:3.0.0'
} <dependencies>
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>annotations</artifactId>
<version>3.0.0</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
</dependencies> Looks good, but these dependencies will not work as you expect from optionals: these dependencies will not be visible in other scopes. So if you need to test this behavior then you'll have to add another dependency in test scope. Probably, there is a way to workaround this, but, still, simple things must be done simple, so
Pom configurationBy default, pom {
name 'Project Name'
description 'My awesome project'
licenses {
license {
name "The MIT License"
url "http://www.opensource.org/licenses/MIT"
distribution 'repo'
}
}
scm {
url 'https://github.com/me/my-repo.git'
connection 'scm:[email protected]:me/my-repo.git'
developerConnection 'scm:[email protected]:me/my-repo.git'
}
developers {
developer {
id "dev1"
name "Dev1 Name"
email "[email protected]"
}
}
} Closure doesn't restrict structure: any tags may be used. If Here is a complete example of all possible maven pom sections definition (you can use any tags if needed, not just these). If pom already have some tags (e.g. set manually with withXml or by some plugin), plugin will override values and properly merge pom. No duplicate tags will be created. Multiple If multiple publications declared, then pom closure will affect all of them. If you need different data in poms then use pom closure only for general info and gradle native dsl for different parts. Clashed tag namesAs By default, there is only one such case: pom {
parent {
name 'name'
relativePath 'path'
}
}
Special prefix '_' may be used in such cases: pom {
parent {
name 'name'
_relativePath 'path'
}
} This prefix will solve clash with real method and will be dropped during xml generation. You can use this prefix with any tag. Another (standard) solution for this problem is using delegate reference: TestingTo test resulted pom you can use pom generation task: $ gradlew generatePomFileForMavenJavaPublication Note that 'MavenJava' in task name is publication name and in your case task name could be different. Pom will be generated by default in Manual pom modificationIf, for any reason, you need to modify pom manually (like in withXml closure)
you can use pom {
scm {
url 'https://github.com/me/my-repo.git'
connection 'scm:[email protected]:me/my-repo.git'
developerConnection 'scm:[email protected]:me/my-repo.git'
}
}
withPomXml {
it.appendNode('description', 'A demonstration of maven POM customization')
} Generated pom xml passed to closure as parameter (no need to call asNode() as in gradle withXml block), so block above could declare parameter explicitly withPomXml { Node node ->
node.appendNode('description', 'A demonstration of maven POM customization')
} See Node api and groovy xml guide. Multiple
NOTE pom plugin uses withXml to apply pom modifications.
If other plugins use withXml too and these plugins registered after pom plugin, then their xml modification will be executed after pom plugin and after Pom generation optionsPlugin behaviour could be controlled with For example, to disable scopes correction: pomGeneration {
disableScopesCorrection()
} (you may use it to see the default gradle behaviour) All options:
(if you prefer property style declaration then you can use extension fields instead of methods (names differ from methods!): forcedVersions, removedDependencyManagement, disabledScopesCorrection (e.g. pomGeneration.forcedVersions = true)) Improving BOMs usageIf you use BOMs for dependency management: dependencies {
// declare BOM
implementation platform('com.group:some-bom:1.0')
// dependency version managed by BOM
implementation 'com.other.group:some-dep'
} (could be spring plugin instead of platform, behaviour is the same) The resulted pom would look like (native behavior): <dependencyManagement>
<dependencies>
<dependency>
<groupId>com.group</groupId>
<artifactId>some-bom</artifactId>
<version>1.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.other.group</groupId>
<artifactId>some-dep</artifactId>
<scope>compile</scope>
</dependency>
</dependencies> Note that dependency version is not set (assuming resolution through bom). In order to force dependency versions use: pomGeneration {
forceVersions()
} To completely remove dependency management section from generated pom: pomGeneration {
removeDependencyManagement()
} the resulted pom would become: <dependencies>
<dependency>
<groupId>com.other.group</groupId>
<artifactId>some-dep</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
</dependencies> Gradle platforms are very handy for dependency management in the root project (maven style), but they should not "leak" into resulted poms. See the complete multi-module declaration example below. Gradle pom dslPlugin was initially created when pom declaration in publishing {
publications {
maven(MavenPublication) {
from components.java
// native gradle syntax!
pom {
name = 'first'
scm {
url = "http://subversion.example.com/svn/project/trunk/"
}
}
}
}
} So why use pom plugin now? Because maven publication configuration could be moved to external plugin (like ru.vyarus.java-lib which configures maven-compatible publication artifacts) and, in this case, only pom should be customized: plugins {
id 'ru.vyarus.java-lib'
}
pom {
name 'first'
scm {
url "http://subversion.example.com/svn/project/trunk/"
}
} A |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论