Quelle est la différence en maven entre les balises dependency et plugin dans pom xml
Je suis nouveau sur l'outil maven, j'ai créé un projet avec Spring et Hibernate et ils sont configurés dans pom.xml en tant que plugins, mais JUnit est marqué sous dépendance. Ma question est la suivante: quelle est la logique derrière un plugin et un comme dépendance?
Les plugins et les dépendances sont des fichiers Jar.
Mais la différence entre eux est que la plus grande partie du travail de maven se fait avec des plugins. tandis que la dépendance est juste un fichier JAR qui sera ajouté au chemin de classe lors de l'exécution des tâches.
Par exemple, vous utilisez un plug-in compiler pour compiler les fichiers Java. Vous ne pouvez pas utiliser compiler-plugin en tant que dépendance car cela ne fera qu'ajouter le plugin au classpath et ne déclenchera aucune compilation. Les fichiers Jar à ajouter au chemin de classe lors de la compilation du fichier seront spécifiés en tant que dépendance.
Même chose avec votre scénario. Vous devez utiliser spring-plugin pour exécuter certains exécutables spring [je ne suis pas sûr de savoir à quoi servent les plugins-spring. Je suis juste en train de deviner ici]. Mais vous avez besoin de dépendances pour exécuter ces exécutables. Et Junit est marqué sous dépendance car il est utilisé par surefire-plugin pour exécuter des tests unitaires.
On peut donc dire que le plugin est un fichier Jar qui exécute la tâche et que la dépendance est un Jar qui fournit les fichiers de classe nécessaires à l’exécution de la tâche.
J'espère que cela répond à votre question!
Maven lui-même peut être décrit comme un robot culinaire comportant plusieurs unités pouvant être utilisées pour accomplir différentes tâches. Ces unités sont appelées plugins. Par exemple, pour compiler votre projet, maven utilise maven-compiler-plugin, pour exécuter des tests - maven-surefire-plugin et ainsi de suite.
La dépendance en termes de maven est un ensemble de classes dont dépend votre projet. Cela peut être jar, war, etc. Par exemple, si vous voulez pouvoir écrire un test JUnit, vous devez utiliser des annotations et des classes JUnit, vous devez donc déclarer que votre projet dépend de JUnit.
Les plug-ins sont utilisés pour ajouter des fonctionnalités à Maven lui-même (comme l’ajout du support Eclipse ou du support SpringBoot à Maven, etc.). Les dépendances sont nécessaires à votre code source pour passer toute phase Maven (compile ou test par exemple). Dans le cas de JUnit puisque le code de test fait partie de votre base de code et que vous appelez des commandes spécifiques à JUnit dans les suites de tests et que ces commandes ne sont pas fournies par Java SDK, donc JUnit doit être présent au moment où Maven est en phase de test et est géré. en mentionnant JUnit en tant que dépendance dans votre fichier pom.xml.
Si vous venez d'un milieu comme moi et connaissez bien Grunt et npm, réfléchissez-y comme ceci:
Commencez par exécuter, par exemple, npm install grunt-contrib-copy --save-dev. C'est comme le <dependency></dependency> de maven. Il télécharge les fichiers nécessaires à l'exécution d'une tâche de construction.
Ensuite, vous configurer la tâche dans Gruntfile.js
copy: {
main: {
src: 'src/*',
dest: 'dest/',
},
}
C'est comme le <plugin>/<plugin> de maven. Vous indiquez à l'outil de génération quoi faire avec le code téléchargé par npm/<dependency></dependency>.
Bien sûr, ce n'est pas une analogie exacte, mais suffisamment proche pour vous aider à comprendre.
Les plugins et les dépendances sont des choses très différentes et complémentaires.
Quels plugins sont?
Les plugins effectuent des tâches pour une construction Maven. Ceux-ci ne sont pas empaquetés dans l'application.
Ce sont le coeur de Maven.
Toute tâche exécutée par Maven est effectuée par des plugins .
Il existe deux catégories de plugins: les plugins build et reporting :
- Les plugins de construction seront exécutés lors de la construction et ils devraient être configurés dans l'élément
<build/>du POM. - Les plugins de génération de rapports seront exécutés lors de la génération du site et doivent être configurés dans l'élément
<reporting/> du POM.
Selon l'objectif maven spécifié dans la ligne de commande (par exemple, mvn clean, mvn clean package ou mvn site), un cycle de vie spécifique sera utilisé et un ensemble spécifique d'objectifs de plugins sera exécuté.
Il existe trois cycles de construction intégrés: default, clean et site. Le cycle de vie default gère le déploiement de votre projet, le cycle de vie clean gère le nettoyage du projet, tandis que le cycle de vie site gère la création de la documentation de site de votre projet.
Un objectif de plug-in peut être lié à une phase spécifique d'un cycle de vie spécifique.
Par exemple, le maven-compiler-plugin lie par défaut l'objectif compile à la phase du cycle de vie: compile.
La plupart des plugins maven (les plugins principaux et les plugins tiers) préfèrent la convention à la configuration. Donc, ceux-ci ont généralement lié un objectif de plug-in à une phase spécifique afin de simplifier leur utilisation.
C'est plus net et moins sujet aux erreurs:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
</plugin>
que :
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
Quelles sont les dépendances?
Les dépendances sont des artefacts/composants Maven requis dans le chemin de classe lors de la construction de Maven.
Ceux-ci peuvent être empaquetés dans l'application mais pas nécessairement (voir le scope ci-dessous).
La plupart des dépendances sont jar, mais il peut également s'agir d'autres types d'archives: guerre, oreille, test-jar, ejb-client ... ou encore POM ou BOM.
Dans un pom.xml, des dépendances peuvent être spécifiées à plusieurs endroits: la partie <build><dependencies>, la partie dependencies management ou toujours dans une déclaration plugin! En effet, certains plugins peuvent avoir besoin de dépendances dans le chemin de classe lors de leur exécution. Ce n'est pas commun mais cela peut arriver.
Voici un exemple tiré de documentation qui montre que plugin et dependency peuvent fonctionner ensemble:
Par exemple, la version 1.2 du plugin Maven Antrun utilise la version Ant 1.6.5, si vous souhaitez utiliser la dernière version Ant lors de l’exécution de ce plug-in, vous devez ajouter un élément
<dependencies>comme suit:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.2</version>
...
<dependencies>
<dependency>
<groupId>org.Apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.1</version>
</dependency>
<dependency>
<groupId>org.Apache.ant</groupId>
<artifactId>ant-launcher</artifactId>
<version>1.7.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
...
</project>
Dans Maven, les dépendances sont référencées dans un format spécifique:groupId:artifactId:packaging:classifier:version.
Le classificateur (facultatif) et l’emballage (JAR par défaut) ne sont pas spécifiés couramment. Ainsi, le format commun dans la déclaration dependency est plutôt: groupId:artifactId:version.
Voici un exemple de dépendance déclarée dans la partie <build><dependencies>:
<build>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>5.2.14.Final</version>
</dependency>
<dependencies>
</build>
Contrairement à un plugin, une dépendance a une portée.
La portée par défaut est compile. C'est la portée la plus souvent nécessaire (convention sur la configuration à nouveau).
La portée compile signifie que la dépendance est disponible dans tous les chemins de classes d'un projet.
La portée définit les chemins de classe auxquels la dépendance doit être ajoutée ..__ Par exemple, en avons-nous besoin lors de la compilation et de l'exécution, ou uniquement pour la compilation et l'exécution des tests?
Par exemple, nous avons précédemment défini Hibernate comme une dépendance compile car nous en avons besoin partout: compilation source, compilation test, exécution, etc.
Mais nous ne voulons pas que les bibliothèques de test puissent être empaquetées dans l'application ou référencées dans le code source. Nous spécifions donc la portée test pour eux:
<build>
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.1.0</version>
<scope>test</scope>
</dependency>
<dependencies>
</build>
Maven est au cœur d’un cadre d’exécution de plug-in, conforme à la définition compacte et formelle standard. Pour que ce soit plus clair, les commandes que vous utilisez sont telles que maven-install/clean/compile/build etc pour créer/exécuter des fichiers JAR, que nous exécutons parfois aussi manuellement. Ainsi, les choses que vous voulez exécuter (ou configurer ou exécuter) sont en général placées dans le tag de dépendance de mavens pom et la réponse indiquant qui exécutera ces dépendances (nécessaires à la configuration de l’environnement).
javac (compiler) dependency.Java (dependency)