Le Touilleur ExpressLe Touilleur ExpressLe Touilleur ExpressLe Touilleur Express
  • Accueil
  • A propos de l’auteur
  • A propos du Touilleur Express

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

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

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

    Par Nicolas Martignole | Java | 6 commentaires | 7 octobre, 2008 | 0 | 2 639 affichages
         

    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.

    Commons Validator avec Dependency Analyzer

    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:

    Default ThumbnailMaven2 dans la vraie vie Default ThumbnailMaven2… ou la ruée vers l'Ouest
    maven
    • Avatar
      Erwan Alliaume 7 octobre 2008 at 9 h 59 min

      Bonjour,
      Concernant l’analyse visuelle des dépendances inter pom, ma préférence tend vers l’éditeur de pom inclus dans les dernières versions de m2eclipse. Le filtre et la recherche de dépendances me semblent plus poussés (ce qui n’est pas négligeable lorsqu’un projet dépasse les 150 pom rien que pour son code, si si, aïe aïe).

      http://blog.xebia.fr/2008/07/28/revue-de-presse-xebia-67/#MEclipseLenouvellediteurgraphi

    • Avatar
      Tom 7 octobre 2008 at 11 h 30 min

      A noter aussi la commande : mvn dependency:tree qui affiche la liste des dépendances dans la console. Cela fonctionne également sur un pom parent.

      Merci pour cet outil, c’est beaucoup plus agréable pour analyser les dépendances.

      Tom

    • Avatar
      Jerome Van Der Linden 7 octobre 2008 at 11 h 45 min

      Je n’ai pas essayé Dependency Analyzer mais m2clipse (http://blogs.sonatype.com/book/2008/07/07/1215465888717.html) propose aussi ce genre de graphiques. C’est très lisible, on peut faire une recherche…
      Je l’utilise tous les jours et pour épurer les war, limiter le nombre de jar de Spring… c’est très pratique.

    • Avatar
      Florent Ramière 7 octobre 2008 at 13 h 32 min

      Salut Nicolas,

      Pour travailler sur les dépendances cycliques je recommande dans un premier temps l’utilisation de iSpace.
      iSpace est un plugin eclipse gratuit qui répond à la plupart des besoins d’analyse, plus d’info sur http://ispace.stribor.de/
      Je vois SonarJ plus comme un outil d' »Architecture enforcement ».

      Florent.

    • Avatar
      Benoit Moussaud 7 octobre 2008 at 16 h 17 min

      A noter que le plugin m2Eclipse (0.9.6+) propose maintenant différentes vues pour la gestion de dépendance
      * http://docs.codehaus.org/display/M2ECLIPSE/Maven+POM+editor#MavenPOMeditor-DependencyGraph
      * http://docs.codehaus.org/display/M2ECLIPSE/Maven+POM+editor#MavenPOMeditor-DependencyHierarchyviewer

    • Avatar
      Nicolas Martignole 7 octobre 2008 at 21 h 44 min

      @Tous > Merci pour vos informations. Donc m2Eclipse semble être intéressant.
      IDEA IntelliJ est censé être capable de faire tourner certains plugins d’Eclipse… Je testerai demain

    Recent Posts

    • GitHub Actions : le tueur de Jenkins ?

      Avouez-le : ce titre de blog est super racoleur. J’avais aussi pensé

      15 février, 2021
    • Comment recréer du lien social dans l’Entreprise avec des outils numériques en 2021

      Nous sommes en février 2021 pendant le 3ème confinement lié à la

      10 février, 2021
    • FizzBuzz en Java et Scala (surtout Scala)

      L’exercice FizzBuzz est un petit exercice très simple, à tester par exemple

      9 février, 2021

    Recent Tweets

    • RT  @JosePaumard : Il y a tout juste un an j'ouvrais ma chaîne de cours Java en ligne (près de 80h de cours), c'était la fermeture des univer…

      2 hours ago
    •  @ShirleyAlmCh  Ça fait du bien de te lire

      3 hours ago
    • RT  @kimchy : great read from  @ldoguin  on putting customers first to the benefit of all by cloud vendors, wonderful to see it embraced by  @cl …

      12 hours ago
    •  @juliendubois   @alexismp  Interesting. However I tweet mostly in French so how accurate is this graph ?

      1 day ago
    • Et hop, voici la future liste des talks 2021 https://t.co/kQPehA8uzx avec encore quelques ajustements à faire (masq… https://t.co/mIDLEw0sML

      1 day ago

    Mots clés

    agile (18) ajax (11) Apple (11) architecture (6) barcamp (5) BarCampJavaParis (5) ddd (5) devoxx (33) esb (6) exo (6) flex (9) geek (5) google (11) grails (5) groovy (10) humeur (12) humour (7) independant (6) iphone (12) Java (77) javascript (7) jazoon (28) jboss (22) jboss seam (12) jsf (9) jug (16) Linux (11) mac (6) mule (5) parisjug (7) paris jug (22) pjug (6) play (8) playframework (6) portlet (5) recrutement (6) ria (8) Scala (21) scrum (44) spring (23) Startup (11) usi (21) usi2010 (9) web (16) xebia (7)

    Le Touilleur Express

    Contactez-moi : nicolas@touilleur-express.fr

    Suivez-moi sur Twitter : @nmartignole

    Copyright© 2008 - 2020 Nicolas Martignole | Tous droits réservés
    • A propos de l’auteur
    • A propos du Touilleur Express
    Le Touilleur Express