Portée (scope) des dépendances

Bonjour,

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

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 :ccool:

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.

Bonjour et merci pour l'explication :ccool:

Citation:

---

Envoyé par romaintaz

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.

---

Citation:

---

Envoyé par romaintaz

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 :

Citation:

---

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 ;)

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:

---

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 ?

Citation:

---

Envoyé par romaintaz

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

a rien, tu peux virer :)

Citation:

---

Envoyé par tchize_

a rien, tu peux virer :)

---

Thanks ! Alors je vire :mouarf:

Mouais, moyennement d'accord là-dessus. Ca peut toujours être intéressant d'avoir le pom.xml quand on a un JAR pas très bien identifié.
Après, techniquement, ça ne sert pas à grand chose, c'est vrai (du moins Maven n'en fait pas usage, à ma connaissance).

Salut je reviens avec ma question sur les scopes :D

Honnêtement c'est le flou ^^

J'ai crée un projet de test contenant une seule classe :

Code:

---

1 2 3 4 5 6 7 8 9 10

package com;   public class AInclure {   public String plop(){ return "plop"; }   }

---

classe que installé dans mon repository local avec install:install-file.

Ensuite, dans un autre projet j'appelle cette dépendance dans mon POM :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">   <modelVersion>4.0.0</modelVersion> <groupId>com.ainclure</groupId> <artifactId>main</artifactId> <version>0.0.1-SNAPSHOT</version>   <dependencies> <dependency> <groupId>com.ainclure</groupId> <artifactId>ainclure</artifactId> <version>1.0</version> </dependency> </dependencies>   </project>

---

et ce projet comprend une classe java toute simple que voici :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

package com;   public class Main {   /**          * @param args          */ public static void main(String[] args) { // TODO Auto-generated method stub   Main m = new Main(); m.launch();       }   private void launch(){ AInclure ai = new AInclure(); System.out.println(ai.plop()); }   }

---

un mvn clean package me compîle/package bien mon projet seulement...en quoi cela change t-il quelque chose de mettre compile ou provided par exemple ? Mon jar final sera toujours le même et mon manifest aussi...

Finalement, pourrait on par flemmardise laisser tout en scope compile sachant que de toute manière c'est à nous d'arranger le classpath/manifest pour que cela fonctionne ?

(dans mon cas de figure, je suis obligé de copier mon jar de dépendances dans le même répertoire que mon projet pour qu'il fonctionne une fois packagé)

Citation:

---

Envoyé par jecomprendsrien

Mon jar final sera toujours le même et mon manifest aussi...

---

Oui, ça ne change rien pour le jar, puisqu'un jar est toujours tout seul. La distinction provided / compile ne sert que pour les war et autres archive qui empaquettent aussi les dépendances

Citation:

---

Finalement, pourrait on par flemmardise laisser tout en scope compile sachant que de toute manière c'est à nous d'arranger le classpath/manifest pour que cela fonctionne ?

---

La pluspart du temps, si tu regarde les pom.xml existant, tu verra que 80~90% des dépendances dedans sont de scope compile :)
Les 10~20% restant étant souvent du scope test.

Citation:

---

Envoyé par tchize_

La distinction provided / compile ne sert que pour les war et autres archive qui empaquettent aussi les dépendances

---

merci pour cette précision je vais tester cela dans le cadre d'un war :)

Dans tous les cas de figure, si on veut modifier avec maven le manifest, faut le faire avec le plugin assembly (je crois) ? Y'a pas moyen de le faire directement avec la plugin jar:jar en fait ?

Merci

Citation:

---

Envoyé par jecomprendsrien

Y'a pas moyen de le faire directement avec la plugin jar:jar en fait ?

Merci

---

Si

http://maven.apache.org/plugins/mave...omization.html

Merci !

Cette fois je pense avoir compris les tenants et les aboutissants des scopes :)

Merci encore

Juste une petite précision : inutile de passer par install:install-file. Passe plutôt par la commande mvn clean install quand tu veux installer un projet dont tu as les sources dans ton repository local.

La commande install:install-file est plutôt utile quand tu n'as que le JAR (avec ou sans son pom.xml).