Re: [Cantharella-devel] Réorganisation des dépendances MAVEN
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
Le 12/02/2013 10:17, Adrien Cheype a écrit :
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).
C'est un problème de divergence, mais qu'on lui disent comment faire en fixant une version ou qu'on laisse maven le faire tout seul le problème me semble toujours présent.
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
Oui, ça ne me gêne pas non plus tant qu'on a la vision globale du projet et des dépendances. Attention cependant, pour log4j par exemple, il est présent dans tous les modules en scope test, sauf dans le module web en scope runtime.
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.
Ha, je crois que benjamin a commencé aussi en configurant un placeholder spring sur ApplicationConfig, il va certainement y avoir conflit.
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 ? Je ne sais pas si on peut qualifier ça de normal, mais c'est en tout cas voulu :)
Par exemple, dans le module web, la classe : nc.ird.cantharella.web.pages.SandboxPage compile explicitement en utilisant des imports hibernate : import org.hibernate.criterion.DetachedCriteria; import org.hibernate.criterion.Restrictions; Il semble y avoir une bonne pratique maven qui stipule que les dépendances nécessaires à la compilation doivent être explicitement déclarée dans le pom en scope compile. Il y a d'ailleurs un plugin maven qui sert a détecter ce genre d'erreur http://maven.apache.org/plugins/maven-dependency-plugin/usage.html#The_depen... C'est une mauvaise pratique de compiler sur une dépendance transitive car si la librairie qui l'a tire est mise à jour et ne la tire plus, cela causera une erreur de compilation. Là encore, si les dépendances sont maitrisées, cela ne me parait pas gênant de ne pas le faire. D'autant plus qu'hibernate serait une dépendance transitive du module "cantharella.data" et le jour où il ne la tirera plus n'est pas prêt d'arriver. Pour h2, c'est différent. La dépendance étant en scope test, elle n'est pas transitive si on dépend de "cantharella.data" en scope compile. Quoiqu'il en soit, il ne faut pas que les conventions soient un frein au developpement et à la compréhension du projet. Il faut être convaincu de leur utilisation ou ne pas les utiliser si c'est justifié. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
On Tue, 12 Feb 2013 11:45:38 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Par exemple, dans le module web, la classe : nc.ird.cantharella.web.pages.SandboxPage compile explicitement en utilisant des imports hibernate : import org.hibernate.criterion.DetachedCriteria; import org.hibernate.criterion.Restrictions;
Il semble y avoir une bonne pratique maven qui stipule que les dépendances nécessaires à la compilation doivent être explicitement déclarée dans le pom en scope compile. Il y a d'ailleurs un plugin maven qui sert a détecter ce genre d'erreur http://maven.apache.org/plugins/maven-dependency-plugin/usage.html#The_depen...
C'est une mauvaise pratique de compiler sur une dépendance transitive car si la librairie qui l'a tire est mise à jour et ne la tire plus, cela causera une erreur de compilation.
Là encore, si les dépendances sont maitrisées, cela ne me parait pas gênant de ne pas le faire. D'autant plus qu'hibernate serait une dépendance transitive du module "cantharella.data" et le jour où il ne la tirera plus n'est pas prêt d'arriver.
Je ne suis pas vraiment d'accord :). Si dans le code on a un import explicite d'une librairie, il faut l'avoir en dépendance dans le pom.xml Si cela nous dérange de l'avoir en dépendance (ex: mais pourquoi avoir du hibernate dans la couche presentation ?). Pour moi cela veut dire que le projet est mal découpé. On ne devrait pas avoir d'import hibernate dans le module présentation et donc pas besoin de la dépendance. Il ne faut pas caché un mauvais découpage en module ou un manque de méthode métier dans un module, en masquant une dépendance dans le pom.xml en s'appuyant sur les dépendances transitive pour cela. Donc pour moi, soit on en a besoin et on met la dépendance soit on en veut pas, et il faut refactoré le code pour supprimer la dépendance -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Tue, 12 Feb 2013 20:17:04 +1100 Adrien Cheype <adrien.cheype@ird.fr> wrote:
J'ai commencé à restructurer les pom.xml en enlevant les profils.
Houla, j'étais justement en train de faire la même chose pour intégrer la mise en place du fichier de configuration :(. J'étais en train de validé le travail fait (vérifier que ça fonctionnait) avant de tout commiter. Je pensais commiter cet après midi. Je ne vois pas pour l'instant de commit sur les pom.xml Donc j'espère que lorsque je vais commiter cela ne posera de problème à personne :( -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
participants (3)
-
Adrien Cheype -
Benjamin POUSSIN -
Eric Chatellier