Différence entre la compilation maven scope et celle fournie pour l’emballage JAR
Quelle est la différence entre la portée maven compile et provided lorsque l'artefact est généré sous la forme d'un fichier JAR? Si c'était WAR, je comprendrais: l'artefact serait inclus ou non dans WEB-INF/lib. Mais dans le cas d'un fichier JAR, cela n'a pas d'importance - les dépendances ne sont pas incluses. Ils doivent être sur classpath lorsque leur portée est compile ou provided. Je sais que les dépendances provided ne sont pas transitives - mais s'agit-il d'une seule différence?
De la Maven Doc :
compiler
C'est la portée par défaut, utilisée si aucune n'est spécifiée. Les dépendances de compilation sont disponibles dans tous les chemins de classes d'un projet. De plus, ces dépendances sont propagées aux projets dépendants.
fourni
Cela ressemble beaucoup à la compilation, mais indique que vous vous attendez à ce que le JDK ou un conteneur fournisse la dépendance au moment de l'exécution. Par exemple, lors de la création d'une application Web pour Java Enterprise Edition, vous devez définir la dépendance de l'API Servlet et des API Java EE associées à la portée fournie, car le conteneur Web fournit ces classes. . Cette portée est uniquement disponible sur le chemin de classe de compilation et de test et n'est pas transitive.
Résumer:
- les dépendances ne sont pas transitives (comme vous l'avez mentionné)
- la portée fournie n'est disponible que sur le chemin de classe de compilation et de test, alors que la portée de compilation est disponible dans tous les chemins de classe.
- les dépendances fournies ne sont pas empaquetées
Compiler signifie que vous avez besoin du JAR pour compiler et exécuter l'application. Pour une application Web, à titre d'exemple, le JAR sera placé dans le répertoire WEB. Répertoire INF/lib.
Fourni signifie que vous avez besoin du fichier JAR pour la compilation, mais qu'au moment de l'exécution, il existe déjà un fichier JAR fourni par l'environnement, vous n'avez donc pas besoin de le packer avec votre application. Pour une application Web, cela signifie que le fichier JAR ne sera pas placé dans le répertoire WEB-INF/lib.
Pour une application Web, si le serveur d'applications fournit déjà le fichier JAR (ou ses fonctionnalités), utilisez "fourni", sinon utilisez "compiler".
Voici le résumé de toutes les dépendances supportées (source maven doc )
compiler
C'est la portée par défaut, utilisée si aucune n'est spécifiée. Les dépendances de compilation sont disponibles dans tous les chemins de classes d'un projet. De plus, ces dépendances sont propagées aux projets dépendants.
à condition de
Cela ressemble beaucoup à la compilation, mais indique que vous vous attendez à ce que le JDK ou un conteneur fournisse la dépendance au moment de l'exécution. Par exemple, lors de la création d'une application Web pour Java Enterprise Edition, vous devez définir la dépendance de l'API Servlet et des API Java EE associées à la portée fournie, car le conteneur Web fournit ces classes. . Cette portée est uniquement disponible sur le chemin de classe de compilation et de test et n'est pas transitive.
runtime
Cette portée indique que la dépendance n'est pas requise pour la compilation, mais pour l'exécution. C'est dans les classpaths d'exécution et de test, mais pas le classpath de compilation.
tester
Cette étendue indique que la dépendance n'est pas requise pour une utilisation normale de l'application et n'est disponible que pour les phases de compilation et d'exécution du test. Cette portée n'est pas transitive.
système
Cette étendue est similaire à fournie sauf que vous devez fournir le fichier JAR qui le contient explicitement. L'artefact est toujours disponible et n'est pas recherché dans un référentiel.
import (disponible uniquement dans Maven 2.0.9 ou version ultérieure)
Cette étendue est uniquement prise en charge sur une dépendance de type pom dans la section. Il indique la dépendance à remplacer par la liste effective des dépendances dans la section du POM spécifié. Dans la mesure où elles sont remplacées, les dépendances avec une étendue d'importation ne participent pas réellement à la limitation de la transitivité d'une dépendance.
Si vous envisagez de générer un seul fichier JAR avec toutes ses dépendances (le fichier typique xxxx-all.jar), la portée fournie est importante, car les classes de cette portée ne seront pas incluses dans le fichier JAR résultant.
Voir maven-Assembly-plugin pour plus d'informations
- compiler
Rendre disponible dans le chemin de classe, n'ajoutez pas cette dépendance dans le fichier final si c'est un fichier normal; mais ajoutez ce jar dans le bocal si le dernier bocal est un seul bocal (par exemple, un jarre exécutable)
- à condition de
La dépendance sera disponible au moment de l’exécution, n’ajoutez pas cette dépendance dans tous les cas. même pas dans un seul bocal (c.-à-d. jar exécutable, etc.)
Pour un fichier jar, la différence réside dans le chemin d'accès aux classes indiqué dans le fichier MANIFEST.MF inclus dans le fichier jar si addClassPath est défini sur true dans la configuration de maven-jar-plugin. Les dépendances 'compiler' apparaîtront dans le manifeste, pas les dépendances 'fournies'.
Une de mes bévues, c'est que ces deux mots devraient avoir le même temps. Soit compilé et fourni, soit compilé et fourni.