Réponses:
Les plugins et les dépendances sont des fichiers Jar.
Mais la différence entre eux est que la plupart du travail dans maven est effectué à l'aide de plugins; alors 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 compilateur-plugin pour compiler les fichiers java. Vous ne pouvez pas utiliser le compilateur-plugin comme dépendance car cela ne fera qu'ajouter le plugin au chemin de classe 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.
Il en va de même avec votre scénario. Vous devez utiliser spring-plugin pour exécuter des exécutables spring [je ne sais pas à quoi servent les plugins spring. Je prends juste une estimation ici]. Mais vous avez besoin de dépendances pour exécuter ces exécutables. Et Junit est étiqueté sous dépendance car il est utilisé par le plugin surefire pour exécuter des tests unitaires.
Ainsi, nous pouvons dire que le plugin est un fichier Jar qui exécute la tâche, et la dépendance est un Jar qui fournit les fichiers de classe pour exécuter la tâche.
J'espère que cela répond à votre question!
Maven lui-même peut être décrit comme un robot culinaire qui a de nombreuses unités différentes qui peuvent être utilisées pour accomplir différentes tâches. Ces unités sont appelées plugins. Par exemple, pour compiler votre projet utilisé par maven 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 être capable d'écrire des tests JUnit, vous devrez utiliser des annotations et des classes JUnit donc vous devez déclarer que votre projet dépend de JUnit.
Les plugins et les dépendances sont des choses très différentes et elles sont complémentaires.
Les plugins effectuent des tâches pour une version Maven. Ceux-ci ne sont pas inclus dans l'application.
Ce sont le cœur de Maven.
Toute tâche exécutée par Maven est effectuée par des plugins .
Il existe deux catégories de plugins: le build
et les reporting
plugins :
<build/>
élément du POM.<reporting/
élément> 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 y a trois haut-construction: cycles de vie default
, clean
et site
. Le default
cycle de vie gère le déploiement de votre projet, le clean
cycle de vie gère le nettoyage du projet, tandis que le site
cycle de vie gère la création de la documentation du site de votre projet.
Un objectif de plugin peut être lié à une phase spécifique d'un cycle de vie spécifique.
Par exemple , les maven-compiler-plugin
binds par défaut , le compile
but de la phase du cycle de vie: compile
.
La plupart des plugins maven (à la fois les plugins principaux et les plugins tiers) préfèrent la convention à la configuration. Donc, ceux-ci lient généralement un objectif de plugin à une phase spécifique pour 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>
Les dépendances sont des artefacts / composants Maven requis dans le chemin de classe lors de la construction de Maven.
Ceux-ci peuvent être emballés dans l'application mais pas nécessairement (voir scope
ci - dessous).
La plupart des dépendances sont jar mais il peut aussi s'agir d'autres types d'archives: war, ear, test-jar, ejb-client ... ou encore POM ou BOM.
Dans un pom.xml, les dépendances peuvent être spécifiées à plusieurs endroits: la <build><dependencies>
partie, la dependencies management
partie ou encore dans une plugin
déclaration ! En effet, certains plugins peuvent avoir besoin d'avoir des dépendances dans le classpath lors de leur exécution. Ce n'est pas courant mais cela peut arriver.
Voici un exemple de la documentation qui montre cela plugin
et dependency
peut fonctionner ensemble:
Par exemple, le Maven Antrun Plugin version 1.2 utilise Ant version 1.6.5, si vous souhaitez utiliser la dernière version Ant lors de l'exécution de ce plugin, vous devez ajouter un
<dependencies>
élément comme le suivant:
<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 (qui est facultatif) et l'empaquetage ( JAR
par défaut) ne sont pas généralement spécifiés. Ainsi , le format commun dans la dependency
déclaration est plutôt: groupId:artifactId:version
.
Voici un exemple de dépendance déclarée dans la <build><dependencies>
pièce:
<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 couramment nécessaire (convention sur la configuration à nouveau).
L' compile
étendue signifie que la dépendance est disponible dans tous les chemins de classe d'un projet.
La portée définit dans quels chemins de classe la dépendance doit être ajoutée. Par exemple en avons-nous besoin à la compilation et à 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 compile
dépendance car nous en avons besoin partout: compilation source, compilation de test, runtime et ainsi de suite ...
Mais nous ne voulons pas que les bibliothèques de test soient empaquetées dans l'application ou référencées dans le code source . Nous spécifions donc leur test
portée:
<build>
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.1.0</version>
<scope>test</scope>
</dependency>
<dependencies>
</build>
webdriver-ie
j'ai deux options, soit l'inclure comme plugins
ou dependency
, j'ai inclus les deux pour comparer, et j'ai observé que les deux avaient exactement la même chose, groupId
la seule différence était que le plugins
ne venait pas avec une version spécifique mais était dependency
livré avec 0.6.685
. Pourriez-vous l'expliquer en termes simples (par rapport à cet exemple) quelle est la différence, lequel utiliser quand. Toute suggestion?
pom.xml
. Mais une chose qui devrait vous intéresser est que la spécification de la version de dépendance est obligatoire (dans le pom actuel ou dans le pom parent s'il s'agit d'une dépendance héritée) dans n'importe quelle version de Maven alors que depuis Maven 3 (probablement une mauvaise bonne idée en tant que fonctionnalité), la spécification de la version du plugin est facultative. Maven utilisera la dernière version disponible dans le référentiel de versions où Maven la trouve. (1/2)
Si vous venez d'un arrière-plan frontal comme moi et que vous connaissez Grunt et npm, pensez-y comme suit:
D' abord , vous courriez, par exemple, npm install grunt-contrib-copy --save-dev
. C'est comme celui de Maven <dependency></dependency>
. Il télécharge les fichiers nécessaires pour exécuter une tâche de construction.
Ensuite, vous configurez la tâche dans Gruntfile.js
copy: {
main: {
src: 'src/*',
dest: 'dest/',
},
}
C'est comme celui de Maven <plugin>/<plugin>
. Vous indiquez à l'outil de construction 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 plug-ins sont utilisés pour ajouter des fonctionnalités à Maven
lui-même (comme l'ajout de eclipse
support ou de SpringBoot
support à Maven
etc.). Des dépendances sont nécessaires à votre code source pour passer n'importe quelle phase Maven ( compile
ou test
par exemple). Dans le cas JUnit
où le code de test fait essentiellement partie de votre base de code et que vous appelez JUnit
des commandes spécifiques à l'intérieur des suites de tests et que ces commandes ne sont pas fournies par, doivent Java SDK
donc JUnit
être présentes au moment Maven
de la phase de test et cela est géré en mentionnant JUnit
comme une dépendance dans votre pom.xml
dossier.
Maven en son cœur est un cadre d'exécution de plugin - selon la définition compacte formelle et standard. Pour que ce soit plus clair, les commandes que vous utilisez comme maven-install/clean/compile/build etc
pour créer / exécuter des fichiers jars, que nous exécutons parfois aussi manuellement. Donc, les choses que vous voulez exécuter (ou configurer ou exécuter), vous les mettez essentiellement dans la balise de dépendance de mavens pom et la réponse pour savoir qui exécutera ces dépendances (requises pour la configuration de l'environnement) sera les plugins.
javac (compiler) dependency.java (dependency)
Réponse en une ligne - compréhension de base
Le plugin est un outil que vous utilisez lors de l'exécution de votre build maven
La dépendance désigne le type de bibliothèque que vous utiliserez dans votre code
Un plugin est une extension de Maven, quelque chose utilisé pour produire votre artefact (maven-jar-plugin par exemple, est utilisé pour, vous le devinez, créer un pot à partir de vos classes et ressources compilées).
Une dépendance est une bibliothèque nécessaire à l'application que vous créez, à la compilation et / ou au test et / ou à l'exécution.