Bonjour, Je reprends la discussion suite au dernier message d'Eric (sujet "CR Réunion Cantharella du 29/01/2013") concernant la double déclaration systématique des dépendances dans un projet maven multimodule : - pom parent -> dans <dependencyManagement> avec <version> et <scope> - pom enfant -> dans <dependencies> sans <version> et <scope> Le 06/02/2013 22:10, Eric Chatellier a écrit :
Le 29/01/2013 11:06, Eric Chatellier a écrit :
* CodeLutin se renseigne sur la vrai plus value à faire cela et renvoi un mail sur la liste C'est bien une convention maven qui garantit la non divergence de version des dépendances entre modules.
Parce exemple, si la version d'une librairie (par exemple commons-io) est définie dans un module. Si un jour un autre module en a besoin et qu'il défini une version plus récente, il y a divergence. Si la version est défini dans le dependencyManagement les futures divergences seront impossibles.
Après le problème des dépendances wicket est moins évident car le cas où plusieurs modules utilisent des dépendances wicket n'est pas prêt de se produire. Mais par unification et dans le but d'éviter les futures erreurs, toutes les versions sont définies à un seul endroit.
C'est peut-être beaucoup plus évident également dans les gros projets avec beaucoup de modules, mais la convention semble s'appliquer de la même manière même aux projets plus petits. Merci pour les précisions, Eric.
Effectivement, nous n'utilisions pas dependencyManagement bien que cela fasse partie des bonnes pratiques de Maven. Ce mécanisme qui permet de centraliser la gestion des versions de dépendance est en effet bien utile pour éviter les problèmes liées aux dépendances transitives. Cependant, bien que cela permette de fixer les versions réellement utilisées dans un build, ce mécanisme peut également certains effets de bords : dans le cas d'une dépendance transitive d'une version plus élevée que la version définie dans le dependencyManagement, il se peut que la librairie qui comporte cette dépendance transitive utilise un nouvelle méthode qui n'existe alors pas dans la version utilisée (version du dependencyManagement). Dans ce cas, le build s'effectue mais laisse des erreurs qui se produiront à l'exécution. Par conséquent, on voit aussi certains architectes qui préfère limiter au maximum l'utilisation du dependencyManagement : "don't use a |<dependencyManagement>| section unless you absolutely have to" !! (cf. http://blog.kdgregory.com/2012/08/taming-maven-dependency-management.html). Dans notre cas, je suis d'accord avec vous. Mieux vaut plus simplement déclarer toutes les versions des modules utilisées au même endroit, c'est plus uniforme et permettra d'éviter certaines erreurs. Par contre, cela n'empêche pas d'avoir également une section <dependencies> dans le pom parent (sans <version> et <scope>) permettant de factoriser certaines dépendances de base comme slf4j, log4j et junit. Cette pratique ne se retrouve pas dans tous les projets OpenSource, mais elle me semble avoir son sens. On la voit notamment dans des projets d'Apache tel Wicket : http://code.metager.de/source/xref/apache/wicket/pom.xml J'ai commencé à restructurer les pom.xml en enlevant les profils. Si vous partagez mes conclusions, je continuerai demain en modifiant les parties dépendances. D'ailleurs est-ce normal qu'il y ait les dépendances hibernate-core et hibernate-validator dans cantharella.web ? spring-jdbc dans cantharella.service ? ou h2 dans cantharella.service ? Et parmi hibernate-core, hibernate-search-engine, hibernate-search-orm, lucene-core dans cantharella.service, ne peut-on pas en enlever certaines qui se retrouveraient en dépendances transitives ? Bonne journée, Adrien -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789