相关文章推荐
贪玩的紫菜  ·  黑暗圣鲸动漫第一集 - 抖音·  昨天    · 
很拉风的日记本  ·  为 Python Server Pages ...·  6 月前    · 
坏坏的路灯  ·  工具变量法（IV）的Stata操作 - ...·  7 月前    · 
深沉的松鼠  ·  有料|敲黑板！聚光灯下的明星婚姻面子里子这样 ...·  9 月前    · 
霸气的蘑菇  ·  西藏干部群众集中观看电影《我的喜马拉雅》_央宗·  10 月前    · 
Code  ›  Dependency Management Plugin
groovy pom
https://docs.spring.io/dependency-management-plugin/docs/current/reference/html/
玩足球的企鹅
2 年前

Snapshots are available from repo.spring.io/plugins-snapshot and can be used as shown in the following example:

Groovy 
buildscript {
    repositories {
        maven { url 'https://repo.spring.io/plugins-snapshot' }
    dependencies {
        classpath 'io.spring.gradle:dependency-management-plugin:<<snapshot-version>>'
apply plugin: "io.spring.dependency-management"
  dependencies {
    classpath("io.spring.gradle:dependency-management-plugin:<<snapshot-version>>")
apply(plugin = "io.spring.dependency-management")

Dependency management can be applied to every configuration (the default) or to one or more specific configurations.


4.1. Dependency Management DSL


The DSL allows you to declare dependency management using a : separated string to configure the coordinates of the managed dependency, as shown in the following example:


Groovy


dependencyManagement {
    dependencies {
        dependency 'org.springframework:spring-core:4.0.3.RELEASE'

dependencyManagement {
    dependencies {
        dependency("org.springframework:spring-core:4.0.3.RELEASE")

Alternatively, you can use a map with group, name, and version entries, as shown in the following example:


Groovy


dependencyManagement {
    dependencies {
        dependency group:'org.springframework', name:'spring-core', version:'4.0.3.RELEASE'

With either syntax, this configuration will cause all dependencies (direct or transitive) on spring-core to have the version 4.0.3.RELEASE.
When dependency management is in place, you can declare a dependency without a version, as shown in the following example:


Groovy


dependencies {
    implementation 'org.springframework:spring-core'

4.1.1. Dependency Sets


When you want to provide dependency management for multiple modules with the same group and version you should use a dependency set.
Using a dependency set removes the need to specify the same group and version multiple times, as shown in the following example:


Groovy


dependencyManagement {
     dependencies {
          dependencySet(group:'org.slf4j', version: '1.7.7') {
               entry 'slf4j-api'
               entry 'slf4j-simple'

You can also use the DSL to declare exclusions.
The two main advantages of using this mechanism are that they will be included in the <dependencyManagement> of your project’s generated pom and that they will be applied using Maven’s exclusion semantics.


An exclusion can be declared on individual dependencies, as shown in the following example:


Groovy


dependencyManagement {
    dependencies {
        dependency('org.springframework:spring-core:4.0.3.RELEASE') {
            exclude 'commons-logging:commons-logging'

dependencyManagement {
    dependencies {
        dependency("org.springframework:spring-core:4.0.3.RELEASE") {
            exclude("commons-logging:commons-logging")

An exclusion can also be declared on an entry in a dependency set, as shown in the following example:


Groovy


dependencyManagement {
    dependencies {
        dependencySet(group:'org.springframework', version: '4.1.4.RELEASE') {
            entry('spring-core') {
                exclude group: 'commons-logging', name: 'commons-logging'
        dependencySet("org.springframework:4.1.4.RELEASE") {
            entry("spring-core") {
                exclude(mapOf("group" to "commons-logging", "name" to "commons-logging"))
Gradle does not provide an API for accessing a dependency’s classifier during resolution.
Unfortunately, this means that dependency management-based exclusions will not work when a classifier is involved.

4.2. Importing a Maven Bom


The plugin also allows you to import an existing Maven bom to utilise its dependency management, as shown in the following example:


Groovy


dependencyManagement {
     imports {
          mavenBom 'io.spring.platform:platform-bom:1.0.1.RELEASE'
dependencies {
     implementation 'org.springframework.integration:spring-integration-core'
------------------------------------------------------------
Root project
------------------------------------------------------------
compileClasspath - Compile classpath for source set 'main'.
\--- org.springframework.integration:spring-integration-core -> 4.0.2.RELEASE
     +--- org.springframework.retry:spring-retry:1.1.0.RELEASE
     |    \--- org.springframework:spring-context:4.0.3.RELEASE -> 4.0.6.RELEASE
     |         +--- org.springframework:spring-aop:4.0.6.RELEASE
     |         |    +--- aopalliance:aopalliance:1.0
     |         |    +--- org.springframework:spring-beans:4.0.6.RELEASE
     |         |    |    \--- org.springframework:spring-core:4.0.6.RELEASE
     |         |    \--- org.springframework:spring-core:4.0.6.RELEASE
     |         +--- org.springframework:spring-beans:4.0.6.RELEASE (*)
     |         +--- org.springframework:spring-core:4.0.6.RELEASE
     |         \--- org.springframework:spring-expression:4.0.6.RELEASE
     |              \--- org.springframework:spring-core:4.0.6.RELEASE
     +--- org.springframework:spring-tx:4.0.5.RELEASE -> 4.0.6.RELEASE
     |    +--- org.springframework:spring-beans:4.0.6.RELEASE (*)
     |    \--- org.springframework:spring-core:4.0.6.RELEASE
     +--- org.springframework:spring-messaging:4.0.5.RELEASE -> 4.0.6.RELEASE
     |    +--- org.springframework:spring-beans:4.0.6.RELEASE (*)
     |    +--- org.springframework:spring-context:4.0.6.RELEASE (*)
     |    \--- org.springframework:spring-core:4.0.6.RELEASE
     +--- org.springframework:spring-context:4.0.5.RELEASE -> 4.0.6.RELEASE (*)
     \--- org.springframework:spring-aop:4.0.5.RELEASE -> 4.0.6.RELEASE (*)


It’s provided a version of 4.0.2.RELEASE for the spring-integration-core dependency.
It has also set the version of all of the Spring Framework dependencies to 4.0.6.RELEASE


4.2.1. Importing Multiple Boms


If you import more than one bom, the order in which the boms are imported can be important.
The boms are processed in the order in which they are imported.
If multiple boms provide dependency management for the same dependency, the dependency management from the last bom will be used.


4.2.2. Overriding Versions in a Bom


If you want to deviate slightly from the dependency management provided by a bom, it can be useful to be able to override a particular managed version.
There are two ways to do this:


Building on the example above, the Spring IO Platform bom that is used contains a property named spring.version.
This property determines the version of all of the Spring Framework modules and, by default, its value is 4.0.6.RELEASE.


A property can be overridden as part of importing a bom, as shown in the following example:


Groovy


dependencyManagement {
    imports {
        mavenBom('io.spring.platform:platform-bom:1.0.1.RELEASE') {
            bomProperty 'spring.version', '4.0.4.RELEASE'

dependencyManagement {
    imports {
        mavenBom("io.spring.platform:platform-bom:1.0.1.RELEASE") {
            bomProperty("spring.version", "4.0.4.RELEASE")

dependencyManagement {
    imports {
        mavenBom('io.spring.platform:platform-bom:1.0.1.RELEASE') {
            bomProperties([
                'spring.version': '4.0.4.RELEASE'

dependencyManagement {
    imports {
        mavenBom("io.spring.platform:platform-bom:1.0.1.RELEASE") {
            bomProperties(mapOf(
                "spring.version" to "4.0.4.RELEASE"

Alternatively, the property can also be overridden using a project’s properties configured via any of the mechanisms that Gradle provides.
You may choose to configure it in your build.gradle script, as shown in the following example:


Groovy


ext['spring.version'] = '4.0.4.RELEASE'
------------------------------------------------------------
Root project
------------------------------------------------------------
compileClasspath - Compile classpath for source set 'main'.
\--- org.springframework.integration:spring-integration-core -> 4.0.2.RELEASE
     +--- org.springframework.retry:spring-retry:1.1.0.RELEASE
     |    \--- org.springframework:spring-context:4.0.3.RELEASE -> 4.0.4.RELEASE
     |         +--- org.springframework:spring-aop:4.0.4.RELEASE
     |         |    +--- aopalliance:aopalliance:1.0
     |         |    +--- org.springframework:spring-beans:4.0.4.RELEASE
     |         |    |    \--- org.springframework:spring-core:4.0.4.RELEASE
     |         |    \--- org.springframework:spring-core:4.0.4.RELEASE
     |         +--- org.springframework:spring-beans:4.0.4.RELEASE (*)
     |         +--- org.springframework:spring-core:4.0.4.RELEASE
     |         \--- org.springframework:spring-expression:4.0.4.RELEASE
     |              \--- org.springframework:spring-core:4.0.4.RELEASE
     +--- org.springframework:spring-tx:4.0.5.RELEASE -> 4.0.4.RELEASE
     |    +--- org.springframework:spring-beans:4.0.4.RELEASE (*)
     |    \--- org.springframework:spring-core:4.0.4.RELEASE
     +--- org.springframework:spring-messaging:4.0.5.RELEASE -> 4.0.4.RELEASE
     |    +--- org.springframework:spring-beans:4.0.4.RELEASE (*)
     |    +--- org.springframework:spring-context:4.0.4.RELEASE (*)
     |    \--- org.springframework:spring-core:4.0.4.RELEASE
     +--- org.springframework:spring-context:4.0.5.RELEASE -> 4.0.4.RELEASE (*)
     \--- org.springframework:spring-aop:4.0.5.RELEASE -> 4.0.4.RELEASE (*)


Overriding the Dependency Management


If the bom that you have imported does not use properties, or you want the override to be honoured in the Maven pom that’s generated for your Gradle project, you should use dependency management to perform the override.
For example, if you’re using the Spring IO Platform bom, you can override its version of Guava and have that override apply to the generated pom, as shown in the following example:


Groovy


dependencyManagement {
    imports {
        mavenBom 'io.spring.platform:platform-bom:1.1.1.RELEASE'
    dependencies {
        dependency 'com.google.guava:guava:18.0'
            <groupId>io.spring.platform</groupId>
            <artifactId>platform-bom</artifactId>
            <version>1.1.1.RELEASE</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>18.0</version>
        </dependency>
    </dependencies>
</dependencyManagement>


The dependency management for Guava that’s declared directly in the pom takes precedence over any dependency management for Guava in the platform-bom that’s been imported.


You can also override the dependency management by declaring a dependency and configuring it with the desired version, as shown in the following example:


dependencies {
    implementation("com.google.guava:guava:18.0")

This will cause any dependency (direct or transitive) on com.google.guava:guava:18.0 in the implementation configuration to use version 18.0, overriding any dependency management that may exist.
If you do not want a project’s dependencies to override its dependency management, this behavior can be disabled using overriddenByDependencies, as shown in the following example:


Groovy


dependencyManagement {
    overriddenByDependencies = false

4.2.3. Configuring the Dependency Management Resolution Strategy


The plugin uses separate, detached configurations for its internal dependency resolution.
You can configure the resolution strategy for these configurations using a closure.
If you’re using a snapshot, you may want to disable the caching of an imported bom by configuring Gradle to cache changing modules for zero seconds, as shown in the following example:


Groovy


dependencyManagement {
    resolutionStrategy {
        cacheChangingModulesFor 0, 'seconds'

To target dependency management at multiple configurations, you use configurations to list the configurations to which the dependency management should be applied, as shown in the following example:


Groovy


dependencyManagement {
     configurations(implementation, custom) {
          dependencies {
          imports {

dependencyManagement {
    configurations {
        listOf("implementation", "custom").forEach {configName ->
            getByName(configName) {
                dependencies {
                imports {

The plugin makes all of the properties from imported boms available for use in your Gradle build.
Properties from both global dependency management and configuration-specific dependency management can be accessed.
A property named spring.version from global dependency management can be accessed as shown in the following example:


Groovy


dependencyManagement.importedProperties['spring.version']

The same property from the implementation configuration’s dependency management can be accessed as shown in the following example:


Groovy


dependencyManagement.implementation.importedProperties['spring.version']

While Gradle can consume dependencies described with a Maven pom file, Gradle does not honour Maven’s semantics when it is using the pom to build the dependency graph.
A notable difference that results from this is in how exclusions are handled.
This is best illustrated with an example.


Consider a Maven artifact, exclusion-example, that declares a dependency on org.springframework:spring-core in its pom with an exclusion for commons-logging:commons-logging, as illustrated in the following example:


<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.1.3.RELEASE</version>
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>


If we have a Maven project, consumer, that depends on exclusion-example and org.springframework:spring-beans the exclusion in exlusion-example prevents a transitive dependency on commons-logging:commons-logging.
This can be seen in the following output from mvn dependency:tree:


+- com.example:exclusion-example:jar:1.0:compile
|  \- org.springframework:spring-core:jar:4.1.3.RELEASE:compile
\- org.springframework:spring-beans:jar:4.1.3.RELEASE:compile


If we create a similar project in Gradle the dependencies are different as the exclusion of commons-logging:commons-logging is not honored.
This can be seen in the following output from gradle dependencies:


+--- com.example:exclusion-example:1.0
|    \--- org.springframework:spring-core:4.1.3.RELEASE
|         \--- commons-logging:commons-logging:1.2
\--- org.springframework:spring-beans:4.1.3.RELEASE
     \--- org.springframework:spring-core:4.1.3.RELEASE (*)


Despite exclusion-example excluding commons-logging from its spring-core dependency, spring-core has still pulled in commons-logging.


The dependency management plugin improves Gradle’s handling of exclusions that have been declared in a Maven pom by honoring Maven’s semantics for those exclusions.
This applies to exclusions declared in a project’s dependencies that have a Maven pom and exclusions declared in imported Maven boms.


6.1. Disabling Maven exclusions


The plugin’s support for applying Maven’s exclusion semantics can be disabled by setting applyMavenExclusions to false, as shown in the following example:


Groovy


dependencyManagement {
    applyMavenExclusions = false

Gradle’s maven-publish plugin automatically generates a pom file that describes the published artifact.
The dependency management plugin will automatically include any global dependency management, i.e. dependency management that does not target a specific configuration, in the <dependencyManagement> section of the generated pom file.
For example, the following dependency management configuration:


Groovy


dependencyManagement {
    imports {
        mavenBom 'com.example:bom:1.0'
    dependencies {
        dependency 'com.example:dependency:1.5'

7.1. Disabling the customization of a generated pom


If you prefer to have complete control over your project’s generated pom, you can disable the plugin’s customization by setting enabled to false, as shown in the following example:


Groovy


dependencyManagement {
    generatedPomCustomization {
        enabled = false
------------------------------------------------------------
Root project
------------------------------------------------------------
global - Default dependency management for all configurations
    org.springframework:spring-core 4.1.5.RELEASE
annotationProcessor - Dependency management for the annotationProcessor configuration
No configuration-specific dependency management
apiElements - Dependency management for the apiElements configuration
No configuration-specific dependency management
archives - Dependency management for the archives configuration
No configuration-specific dependency management
compile - Dependency management for the compile configuration
No configuration-specific dependency management
compileClasspath - Dependency management for the compileClasspath configuration
No configuration-specific dependency management
compileOnly - Dependency management for the compileOnly configuration
No configuration-specific dependency management
default - Dependency management for the default configuration
No configuration-specific dependency management
implementation - Dependency management for the implementation configuration
No configuration-specific dependency management
runtime - Dependency management for the runtime configuration
No configuration-specific dependency management
runtimeClasspath - Dependency management for the runtimeClasspath configuration
No configuration-specific dependency management
runtimeElements - Dependency management for the runtimeElements configuration
No configuration-specific dependency management
runtimeOnly - Dependency management for the runtimeOnly configuration
No configuration-specific dependency management
testAnnotationProcessor - Dependency management for the testAnnotationProcessor configuration
No configuration-specific dependency management
testCompile - Dependency management for the testCompile configuration
No configuration-specific dependency management
testCompileClasspath - Dependency management for the testCompileClasspath configuration
    org.springframework:spring-beans 4.1.5.RELEASE
    org.springframework:spring-core 4.1.5.RELEASE
testCompileOnly - Dependency management for the testCompileOnly configuration
No configuration-specific dependency management
testImplementation - Dependency management for the testImplementation configuration
    org.springframework:spring-beans 4.1.5.RELEASE
    org.springframework:spring-core 4.1.5.RELEASE
testRuntime - Dependency management for the testRuntime configuration
No configuration-specific dependency management
testRuntimeClasspath - Dependency management for the testRuntimeClasspath configuration
    org.springframework:spring-beans 4.1.5.RELEASE
    org.springframework:spring-core 4.1.5.RELEASE
testRuntimeOnly - Dependency management for the testRuntimeOnly configuration
No configuration-specific dependency management


This report is produced by a project with the following dependency management:


dependencyManagement {
    dependencies {
        dependency 'org.springframework:spring-core:4.1.5.RELEASE'
    testImplementation {
        dependencies {
            dependency 'org.springframework:spring-beans:4.1.5.RELEASE'

8.2. Programmatic access


The plugin provides an API for accessing the versions provided by the configured dependency management.
The managed versions from global dependency management are available from dependencyManagement.managedVersions, as shown in the following example:


Groovy


def managedVersions = dependencyManagement.managedVersions

Managed versions from configuration-specific dependency management are available from dependencyManagement.<configuration>.managedVersions, as shown in the following example for the implementation configuratation`:


Groovy


def managedVersions = dependencyManagement.implementation.managedVersions

The managed versions are of map of groupId:artifactId to version, as shown in the following example for accessing the version of org.springframework:spring-core:


Groovy


def springCoreVersion = managedVersions['org.springframework:spring-core']
 
推荐文章
贪玩的紫菜  ·  黑暗圣鲸动漫第一集 - 抖音
昨天
很拉风的日记本  ·  为 Python Server Pages 和 Oracle 构建快速 Web 开发环境
6 月前
坏坏的路灯  ·  工具变量法（IV）的Stata操作 - celine227 - 博客园
7 月前
深沉的松鼠  ·  有料|敲黑板！聚光灯下的明星婚姻面子里子这样拿_新浪娱乐_新浪网
9 月前
霸气的蘑菇  ·  西藏干部群众集中观看电影《我的喜马拉雅》_央宗
10 月前
今天看啥   ·   Py中国   ·   codingpro   ·   小百科   ·   link之家   ·   卧龙AI搜索
删除内容请联系邮箱 2879853325@qq.com
Code - 代码工具平台
© 2024 ~ 沪ICP备11025650号