Discussion :

[jecomprendsrien]

Bonjour,

malgré ma bonne volonté ( ) j'ai toujours pas compris réellement à quoi servait le scope d'une dépendance

Que je mettes n'importe quel scope de toute façon mon .jar est packagé de la même façon...

Je pensais que le scope allait servir à créer un manifest avec un class-path automatiquement configuré mais non

Apparemment à ce que j'ai compris faut utiliser un plugin assembly...

Donc question toute bête : à quoi sert les scope de dépendances et plus généralement à quoi sert une dépendance (mis à part à ce qu'Eclipse trouve les classes et à pouvoir compiler via mvn ?)

Merci

[romaintaz]

Bonjour.

Globalement, les scopes expliquent quand, dans le cycle de vie de Maven, la dépendance est utilisée.
Par défaut, le scope est runtime, ce qui signifie que la dépendance est requise à tout moment : à la compilation, durant les tests, dans le package final.

Si j'ai une dépendance avec un scope test, cela signifie que ma dépendance ne sera utilisée qu'à 2 moments : lors de la compilation du code des tests (par défaut situé dans src/test/java), ainsi que durant l'exécution. C'est tout. Par exemple, la dépendance junit:junit n'est utile que durant les tests. Ainsi, point besoin d'elle à la compilation des sources, ni dans le packaging. La dépendance junit n'est ainsi jamais livrée dans le WAR/EAR/... final.

La dépendance provided signifie que c'est une dépendance nécessaire à tout moment (comme compile donc), mais qu'elle sera fournie (donc provided) par le containeur d'applications. Autrement dit, elle ne sera pas packagée dans le WAR/EAR/... final. C'est par exemple (souvent) le cas de javax.servlet, fourni par ton serveur Tomcat ou autre.

La dépendance runtime est, comme son nom l'indique, uniquement utilisée lors de l'exécution de ton application. Donc elle ne sera pas utilisée lors de la compilation, mais sera quand même livrée dans le package final. Ce sont généralement des librairies chargées dynamiquement par le code (ou d'autres librairies), l'exemple le plus courant étant les drivers de base de données.

Enfin, la dépendance system, tu oublies C'est une façon crade d'utiliser un JAR qui n'est pas stocké dans un repository Maven, et on va dire à Maven où trouver le fichier JAR en question (par exemple dans un répertoire lib/). Mais c'est à proscrire !!

Voilà, j'espère que c'est plus clair comme ça

Sinon, une dépendance, ce n'est jamais qu'une librairie contenant diverses fonctionnalités que tu souhaites utiliser dans ton application, pour éviter de tout recoder de 0, de réinventer la roue (qu'on ré-invente souvent carrée du coup). Tu as des dépendances pour faire du log, accéder à une base de données, etc. Spring, Hibernate sont des dépendances par exemple.

[jecomprendsrien]

Bonjour et merci pour l'explication

Par exemple, la dépendance junit:junit n'est utile que durant les tests. Ainsi, point besoin d'elle à la compilation des sources, ni dans le packaging. La dépendance junit n'est ainsi jamais livrée dans le WAR/EAR/... final.

La dépendance provided signifie que c'est une dépendance nécessaire à tout moment (comme compile donc), mais qu'elle sera fournie (donc provided) par le containeur d'applications. Autrement dit, elle ne sera pas packagée dans le WAR/EAR/... final. C'est par exemple (souvent) le cas de javax.servlet, fourni par ton serveur Tomcat ou autre.

En fait, j'avais saisi à peu près tout ça mais globalement ce que je n'arrive pas à saisir c'est finalement l'intérêt su scope pour le développeur puisque que finalement (je prends l'exemple de la génération d'un EAR), il faudra manuellement (via le POM) inclure les dépendances pour constituer l'EAR, il n'y a pas vraiment de transitivité des dépendances dans la mesure ou si A a besoin de B et si un ear C embarque A alors il faudra manuellement inclure B dans C (du moins à ce que j'ai cru comprendre/voir durant mes tests).

J'ai chopé le traduction française du Maven definitive guide et sur les scope il y est marqué pour compile :

compile est le scope par défaut ; toutes les dépendances sont dans ce scope compile si aucun
scope n'est précisé. Les dépendances du scope compile se retrouvent dans tous les classpaths et sont packagées avec l'application.

J'ai pas toujours l'impression que cela soit le cas. Exemple j'avais constitué un projet Maven log4jperso contenant basiquement la version officielle Log4j ainsi qu'un fichier perso xml de conf. Le packaging s'est bien passé et un jar a été crée.
Maintenant, j'ai voulu insérer ce jar comme dépendance dans un projet ejb mais la dépendance ne s'y est pas packagé. Je pense que c'est du au fait que j'essayais finalement d'inclure un jar dans un autre jar mais j'en suis pas sur

Enfin merci en tout cas, je vais approfondir mes tests

[romaintaz]

Bonjour,

Désolé, j'ai écrit trop vite mon 1er post, le scope par défaut est bien compile (je vais mettre à jour mon post pour éviter les erreurs).

Maven gère tout à fait la transitivité des dépendances. Par exemple, si j'ai besoin de la dépendance A, je me fiche de savoir de quoi elle a besoin pour fonctionner. Je n'inclue que A dans mon pom. Maven, de son côté, va aller lire le pom.xml de A pour connaitre ses propres dépendances, et ainsi les rapatrier (sauf quand elles sont marquées <optional>true</optional>). Ces dépendances sont donc, pour moi, des dépendances transitives, ce qui signifie qu'elles ne sont pas dans mon pom, mais seront bien livrées dans mon package final (sinon A ne marchera pas).

Tu peux connaitre l'arbre des dépendances dans un projet avec la commande mvn dependency:tree (les IDE propose une vision graphique aussi de cet arbre). Voici un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[INFO] [dependency:tree {execution: default-cli}]
[INFO] devoxx-envers:demo:jar:1.0
[INFO] +- org.hibernate:hibernate-core:jar:3.6.9.Final:compile
[INFO] |  +- antlr:antlr:jar:2.7.6:compile
[INFO] |  +- commons-collections:commons-collections:jar:3.1:compile
[INFO] |  +- dom4j:dom4j:jar:1.6.1:compile
[INFO] |  +- org.hibernate:hibernate-commons-annotations:jar:3.2.0.Final:compile
[INFO] |  +- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.1.Final:compile
[INFO] |  +- javax.transaction:jta:jar:1.1:compile
[INFO] |  \- org.slf4j:slf4j-api:jar:1.6.1:compile
[INFO] +- org.hibernate:hibernate-envers:jar:3.6.9.Final:compile
[INFO] |  \- org.hibernate:hibernate-entitymanager:jar:3.6.9.Final:compile
[INFO] |     \- cglib:cglib:jar:2.2:compile
[INFO] |        \- asm:asm:jar:3.1:compile
[INFO] +- javassist:javassist:jar:3.12.0.GA:compile
[INFO] +- p6spy:p6spy:jar:1.3:compile
[INFO] +- commons-lang:commons-lang:jar:2.6:compile
[INFO] +- junit:junit:jar:4.10:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.1:test
[INFO] +- com.h2database:h2:jar:1.3.167:test
[INFO] \- org.easytesting:fest-assert:jar:1.4:test
[INFO]    \- org.easytesting:fest-util:jar:1.1.6:test

Dans mon projet (devoxx-envers), j'ai besoin d'Hibernate Envers. Mais lui-même a besoin d'Hibernate Entitymanager, qui lui même a besoin de cglib, etc. Mais ça, à la limite, je m'en fiche (et même ne veux pas trop le savoir).

Pour ton cas du log4jperso, il faudrait un peu plus de détail. Mais si tu as un projet qui génère un JAR, il ne contiendra bien sûr pas le code de ses dépendances. Le JAR de ton projet ne contient que le code compilé de ton application, et éventuellement ses ressources. Est-ce plus clair ?

[jecomprendsrien]

Est-ce plus clair ?

Oui en effet je te remercie pour ton aide

Sinon j'ai une question subsidiaire...

Quand Maven package un JAR il inclut dans le META-INF un dossier maven contenant mon pom.xml et un pom.properties...à quoi cela lui sert-il ? Est ce nécessaire ou bien peut on le supprimer de l'archive ?

Merci encore

[tchize_]

a rien, tu peux virer