Accélerer Maven2 : l'analyse des dépendances

Votre projet utilise Maven2 ? Cet article est pour vous. Un projet compilé avec Maven2 fait appel à un certain nombre de dépendances externes (spring, hibernate, commons-*…). Il est aussi courant de rencontrer des « super pom », c’est à dire des pom.xml appelant par dépendances d’autres pom. Par expérience, j’ai vu qu’il devient difficile de maintenir dans le temps l’ensemble de l’arbre des dépendances. La conséquence ? Le projet devient plus compliqué, donc plus lent à compiler. Il est difficile d’identifier rapidement les dépendances inter-modules dans le projet.

J’ai trouvé un petit outil bien pratique hier : Dependency Analyzer est un outil d’analyse graphique des dépendances Maven d’un projet. Après l’avoir installé, cet outil écrit en Java prend un fichier pom.xml en entrée, pour ensuite afficher en étoile ou en arbre, les dépendances. Grâce à cet outil, je me suis rendu compte qu’il y a un trop grand nombre de versions de JUnit dans le projet, que certains modules sont trop liés, donc fragiles, pour effectuer du refactoring facilement dessus.

Vous allez me dire : quel intérêt y-a-t-il à regarder la build Maven qui après tout, fonctionne très bien sur votre projet ?
Réponse : la productivité.
Si la compilation complète d’un projet dépasse les 2 minutes, l’équipe aura souvent mis en place des systèmes plus rapides pour fonctionner comme le déploiement à chaud, ou le fonctionnement en mode « exploded » afin de ne recharger que les classes modifiées. Bien que très efficace, il est parfois délicat de savoir les réelles dépendances du code, surtout lorsque le volume des fichiers est important.

Je pense aussi à l’intégration continue. Idéalement, un projet en journée doit fonctionner en incrémental, sans effectuer de clean. Ce projet compile rapidement afin d’assurer que l’ensemble du code compile. Ensuite, et seulement ensuite, je pense qu’une tâche de l’intégration continue doit être les tests unitaires.
Pour que tout ceci s’effectue le plus rapidement possible il faut
– une machine d’intégration puissante
– un repository SVN local ou un proxy svn
– un projet qui compile l’ensemble du code de manière incrémental, sans qu’un clean ne soit nécessaire
– un projet d’exécution des test unitaires

Plus globalement, faire respirer son intégration continue est un investissement indispensable. J’ai lu avec intérêts les article de Jérôme Van Der Linden s d’OCTO sur la mise en place d’usine de production. Articles que je vous conseille si vous réflechissez à la mise en place d’une intégration continue, de la compilation à la mise en production.

Xebia propose aussi un pointeur sur un article de Kevlin Henney sur des sujets moins terre à terre que Maven, intéressant pour prendre un peu de recul.
Enfin je garde en mémoire SonarJ, l’outil dont je vous ai parlé cet été qui permet d’apporter de la structuration d’architecture entre différents modules d’une application.

Articles similaires:

Maven2 dans la vraie vie Maven2… ou la ruée vers l'Ouest