198 votes

Comment trouver/supprimer les dépendances inutilisées dans Gradle

Je voulais trouver les dépendances inutilisées dans mon projet. Y a-t-il une fonctionnalité pour cela dans Gradle, comme dans Maven ?

91voto

SkyWalker Points 7044

MISE À JOUR mai 2024: Le plugin n'est plus maintenu. Les auteurs suggèrent dependency-analysis-gradle-plugin qui prend en charge les projets Java, Kotlin et Android, y compris les projets basés sur kts.

MISE À JOUR pour les utilisateurs de Kotlin: 17 décembre 2021: Détecte les dépendances de construction manquantes ou superflues dans les projets Kotlin : Version 1.0.9 (la plus récente)

J'ai ajouté 2 types de configuration pour les utilisateurs de Kotlin.

  • En utilisant les plugins DSL
  • En utilisant l'ancienne application de plugin

En utilisant les plugins DSL:

plugins {
  id("com.faire.gradle.analyze") version "1.0.9"
}

En utilisant l'ancienne application de plugin:

buildscript {
  repositories {
    maven {
      url = uri("https://plugins.gradle.org/m2/")
    }
  }
  dependencies {
    classpath("com.faire.gradle:gradle-kotlin-buildozer:1.0.9")
  }
}

apply(plugin = "com.faire.gradle.analyze")

Lien vers la ressource:

  1. https://plugins.gradle.org/plugin/com.faire.gradle.analyze
  2. https://github.com/Faire/gradle-kotlin-buildozer
  3. https://discuss.gradle.org/t/detecting-unused-projects-dependencies/25522

MISE À JOUR: 28-06-2016: Prise en charge Android de unused-dependency

En juin 2017, ils ont publié la version 4.0.0 et ont renommé le nom du projet racine "gradle-lint-plugin" en "nebula-lint-plugin". Ils ont également ajouté la prise en charge Android de unused-dependency.


En mai 2016, Gradle a mis en œuvre le plugin Gradle lint pour trouver et supprimer les dépendances indésirables.

Plugin Gradle Lint: Documentation complète

Le plugin Gradle Lint est un outil de linter plug-and-play et configurable pour identifier et signaler les modèles d'utilisation incorrecte ou les dépréciations dans les scripts Gradle et les fichiers associés.

Ce plugin a différentes règles. La règle de dépendance non utilisée en fait partie. Elle possède trois caractéristiques spécifiques.

  1. Supprime les dépendances inutilisées.
  2. Promeut les dépendances transitives qui sont directement utilisées par votre code en tant que dépendances explicites de premier ordre.
  3. Relocalise les dépendances dans la configuration 'correcte'.

Pour appliquer la règle, ajoutez :

gradleLint.rules += 'unused-dependency'

Les détails de la règle de dépendance inutilisée sont donnés dans la dernière partie.

Pour appliquer le plugin Gradle lint:

buildscript { repositories { jcenter() } }
plugins {
  id 'nebula.lint' version '0.30.2'
}

En alternative:

buildscript {
  repositories { jcenter() }
  dependencies {
    classpath 'com.netflix.nebula:gradle-lint-plugin:latest.release'
  }
}

apply plugin: 'nebula.lint'

Définir les règles contre lesquelles vous souhaitez vérifier:

gradleLint.rules = ['all-dependency'] // Ajoutez autant de règles que vous le souhaitez ici

Pour une construction d'entreprise, nous recommandons de définir les règles de linter dans un script init.gradle ou dans un script Gradle inclus via le mécanisme apply from de Gradle.

Pour les projets multi-modules, nous recommandons d'appliquer le plugin dans un bloc allprojects:

allprojects {
  apply plugin: 'nebula.lint'
  gradleLint.rules = ['all-dependency'] // Ajoutez autant de règles que vous le souhaitez ici
}


Détails de la règle de dépendance non utilisée sont donnés dans cette partie

Pour appliquer la règle, ajoutez :

gradleLint.rules += 'unused-dependency'

La règle inspecte les binaires compilés provenant des ensembles de sources de votre projet à la recherche de références de classe et associe ces références aux dépendances que vous avez déclarées dans votre bloc de dépendances.

Plus précisément, la règle apporte les ajustements suivants aux dépendances:

1. Supprime les dépendances inutilisées

  • Les JAR de style famille comme com.amazonaws:aws-java-sdk sont supprimés, car ils ne contiennent aucun code

2. Promeut les dépendances transitives qui sont utilisées directement par votre code en tant que dépendances explicites de premier ordre

  • Cela a pour effet secondaire de diviser les fichiers JAR de style famille, comme com.amazonaws:aws-java-sdk, en parties que vous utilisez réellement, et d'ajouter celles-ci en tant que dépendances de premier ordre

3. Relocalise les dépendances dans la configuration 'correcte'

  • Les Webjars sont déplacés vers la configuration d'exécution
  • Les fichiers JAR qui ne contiennent pas de classes et de contenu en dehors de META-INF sont déplacés vers l'exécution
  • 'xerces', 'xercesImpl', 'xml-apis' devraient toujours être de portée exécution
  • Les fournisseurs de services (fichiers JAR contenant META-INF/services) comme mysql-connector-java sont déplacés vers l'exécution s'il n'y a pas de référence à la compilation
  • Les dépendances sont déplacées vers la configuration d'ensemble de source la plus élevée possible. Par exemple, 'junit' est relocalisé vers testCompile sauf s'il y a une dépendance explicite dessus dans l'ensemble de sources principal (rare).


MISE À JOUR: Anciens plugins

Pour votre information, je tiens à partager des informations sur d'anciens plugins

  1. Le plugin Gradle qui trouve les dépendances non utilisées, déclarées et transitives est com.github.nullstress.dependency-analysis

Mais sa dernière version 1.0.3 a été créée le 23 décembre 2014. Après cela, il n'y a pas eu de mises à jour.

N.B: Beaucoup de nos ingénieurs se sont trompés à propos de ce plugin car ils ont mis à jour seulement le numéro de version, rien d'autre.

21voto

SatelliteSD Points 2686

Je viens de découvrir ceci : https://plugins.gradle.org/plugin/com.autonomousapps.dependency-analysis

Github

À première vue, il est en cours de développement actif, mais je ne l'ai pas encore testé.

Édition : En fait, c'est plutôt génial, il offre beaucoup de conseils (par exemple sur l'utilisation de api vs implementation)

9voto

Le projet mentionné dans les réponses précédentes semble être mort. J'utilise gradle-dependency-analyze. La configuration est simple :

buildscript {
  repositories {
    jcenter()
  }
  dependencies {
    classpath 'ca.cutterslade.gradle:gradle-dependency-analyze:1.0.3'
  }
}

apply plugin: 'ca.cutterslade.analyze'

Ensuite, faites :

$ gradle analyzeDependencies

8voto

jstricker Points 438

J'ai eu beaucoup de chance en utilisant le plugin d'analyse de dépendances Gradle. Pour commencer avec lui, ajoutez les deux éléments suivants à votre script de construction Gradle.

buildscript {
    repositories {
        maven {
            url "https://plugins.gradle.org/m2/"
        }
    }
    dependencies {
        classpath "com.github.nullstress:DependencyAnalysisPlugin:1.0.3"
    }
}

et

apply plugin: "dependencyAnalysis"

Une fois que ces éléments sont en place, exécutez gradle analyze. S'il y a des dépendances inutilisées, vous obtiendrez un échec de construction qui affiche une sortie similaire au texte ci-dessous, ainsi qu'une liste des dépendances inutilisées (déclarées et transitives). L'échec de construction est vraiment utile si vous voulez imposer qu'il ne devrait y avoir aucune dépendance inutilisée via une construction CI.

:foo:analyze ÉCHEC

ÉCHEC: La construction a échoué avec une exception.

* Qu'est-ce qui n'a pas fonctionné :
L'exécution de la tâche ':foo:analyze' a échoué.
> Le projet a des artefacts déclarés inutilisés

1voto

EFernandes Points 1076

Note de l'éditeur : Cette réponse est obsolète. Veuillez consulter la réponse principale.

Vous pouvez essayer le plugin Gradle com.github.nullstress.dependency-analysis

Extrait du script de construction à utiliser dans toutes les versions de Gradle :

buildscript {
  repositories {
    jcenter()
  }
  dependencies {
    classpath "com.github.nullstress:DependencyAnalysisPlugin:1.0.3"
  }
}

apply plugin: "com.github.nullstress.dependency-analysis"

Extrait du script de construction pour le nouveau mécanisme de plugin en incubation introduit dans Gradle 2.1 :

plugins {
  id "com.github.nullstress.dependency-analysis" version "1.0.3"
}

De plus, il existe un fil de discussion (Y a-t-il un équivalent Gradle de "mvn dependency:analyze" ?) dans le forum Gradle à ce sujet.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X