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