Conflit de la version 12 de Gradle

La question la plus importante de la dépendance de gestion est la gestion des conflits de version dans le processus de dépendance transitive. Dans le processus de dépendance de gestion manuelle précédent, nous avons souvent rencontré des conflits de version. Dès que la version était en conflit, le programme ne pouvait pas s'exécuter. En tant qu'outil de gestion de version, nous devrions avoir la capacité de résoudre ce problème.

Exemples de problèmes de conflit de version dans les dépendances transitives:

compile group:'org.hibernate',name:'hibernate-core',version:'3.6.3.Final'

hibernate dépend de hibernate-commons-annotations.jar dépend de slf4j, le framework hibernate actuel dépend également de slf4j, en raison des caractéristiques de transitivité des dépendances, deux versions différentes du package jar dépendent, donc il y aura un problème de conflit de version

Résolution des conflits de version

Résolution automatique des conflits de version Maven

Par rapport à maven, il gère automatiquement les conflits de versions de dépendance transitive. Maven gère le

principe du chemin le plus court selon le principe du chemin le plus court et le principe de déclaration de priorité : le
chemin D1 est: projet-> A-> D1 Le
chemin D2 est: projet-> B-> E1- > D2 Le
chemin D1 est plus court que D2, donc D1 est utilisé pour
déclarer le principe en premier:
E1 et E2 ont la même distance de chemin, et E1 est déclaré avant E2, donc E1 est utilisé à la place de E2

Résolution des conflits de version Gradle

La solution par défaut de Gradle pour résoudre automatiquement les conflits de version consiste à choisir la version la plus élevée. En général, la version supérieure est rétrocompatible avec la version inférieure, de sorte que cette option peut utiliser les fonctionnalités de la nouvelle version, et il n'est pas facile de se tromper.

Résoudre manuellement les conflits de version

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.12'
    compile group:'org.hibernate',name:'hibernate-core',version:'3.6.3.Final'
}

Faisons d'abord référence à heibernate et vérifions la dépendance: nous

pouvons voir que le slf4j référencé est la version 1.6.1. Modifiez la stratégie de configuration et résolvez automatiquement les conflits pour tous les fichiers JAR
.

configurations.all{
    resolutionStrategy{
        //修改gradle不自动处理版本冲突
        failOnVersionConflict()
    }
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.12'
    compile group:'org.hibernate',name:'hibernate-core',version:'3.6.3.Final'
}

Rafraîchir gradle,

Could not resolve all dependencies for configuration ':compileClasspath'.
A conflict was found between the following modules:
  - org.slf4j:slf4j-api:1.6.1
  - org.slf4j:slf4j-api:1.5.8
Run with:
    --scan or
    :dependencyInsight --configuration compileClasspath --dependency org.slf4j:slf4j-api
to get more insight on how to solve the conflict.

Vous verrez une erreur dans le conflit de version. La configuration ci-dessus empêchera gradle de gérer automatiquement le conflit de version et la génération lèvera une exception. Cette opération peut vérifier quels fichiers jar ont des conflits de version.

Excluons la dépendance transitive d'un package jar:
Prenons slf4j comme exemple:

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.12'
    compile (group:'org.hibernate',name:'hibernate-core',version:'3.6.3.Final') {
        exclude group:'org.slf4j', module:'slf4j-api'
    }
}

Regardez à nouveau les dépendances:

vous pouvez voir que le projet ne dépend d'aucune version du package jar slf4j-api. Vous devez configurer vous-même le package jar de la version requise

Exclure toutes les dépendances transitives des pots (non recommandé)

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.12'
    compile (group:'org.hibernate',name:'hibernate-core',version:'3.6.3.Final') {
        transitive = false
    }
}

Spécifiez une version jar manuellement

configurations.all{
    resolutionStrategy{
        force 'org.slf4j:slf4j-api:1.7.24'
    }
}