Pourquoi maven ? Quels sont les avantages ?

Question

Quels sont les principaux avantages d'utiliser maven par rapport à ant, par exemple ? Il semble que ce soit plus une gêne qu'un outil utile. J'utilise maven 2, avec Eclipse Java EE (pas de m2eclipse), et tomcat.

Les partisans de Maven pensent que

1. Maven vous permet d'obtenir facilement les dépendances de vos paquets.

2. Maven vous oblige à avoir une structure de répertoire standard

D'après mon expérience

1. Déterminer les dépendances des paquets n'est pas si difficile. Vous le faites rarement de toute façon. Probablement une fois pendant la mise en place du projet et quelques autres pendant les mises à jour. Avec maven, vous finirez de toute façon par corriger les dépendances mal assorties, les poms mal écrits et les exclusions de paquets.

2. Cycle lent FIX-COMPILE-DEPLOY-DEBUG, qui tue la productivité. C'est mon principal reproche. Vous apportez une modification, vous devez attendre que la compilation maven se mette en route et attendre qu'elle soit déployée. Pas de déploiement à chaud.

Ou est-ce que je m'y prends mal ? Indiquez-moi la bonne direction, je suis tout ouïe.

Answer 1

Il n'est pas si difficile de déterminer les dépendances des paquets. Vous le faites rarement de toute façon. Probablement une fois pendant la mise en place du projet et quelques autres pendant les mises à jour. Avec maven, vous finirez de toute façon par corriger les dépendances mal assorties, les poms mal écrits et les exclusions de paquets.

Pas si difficile... pour les projets de jouets. Mais les projets sur lesquels je travaille en ont beaucoup, vraiment beaucoup, et je suis très heureux de les obtenir de manière transitive, d'avoir un schéma de nommage standardisé pour eux. Gérer tout cela à la main serait un cauchemar.

Et oui, il faut parfois travailler sur la convergence des dépendances. Mais réfléchissez-y à deux fois, ce n'est pas inhérent à Maven, c'est inhérent à tout système utilisant des dépendances (et je parle ici des dépendances Java en général).

Donc avec Ant, vous devez faire le même fonctionnent, sauf que vous devez tout faire manuellement : récupérer une version du projet A et ses dépendances, récupérer une version du projet B et ses dépendances, déterminer vous-même quelles versions exactes ils utilisent, vérifier qu'elles ne se chevauchent pas, vérifier qu'elles ne sont pas incompatibles, etc. Bienvenue en enfer.

D'un autre côté, Maven prend en charge la gestion des dépendances et les récupérera de manière transitive pour moi et me donne l'outillage nécessaire pour gérer la complexité. inhérents à la gestion des dépendances : Je peux analyser un arbre de dépendances, contrôler les versions utilisées dans les dépendances transitives, en exclure certaines si nécessaires, contrôler la convergence entre les modules, etc. Il n'y a pas de magie. Mais au moins, vous avez un soutien.

Et n'oubliez pas que la gestion des dépendances n'est qu'une petite partie de ce que Maven offre, il y a beaucoup plus (sans même mentionner les autres outils qui s'intègrent bien avec Maven, par exemple. Sonar ).

Cycle lent FIX-COMPILE-DEPLOY-DEBUG, qui tue la productivité. C'est mon principal reproche. Vous apportez une modification, puis vous devez attendre que la compilation maven se mette en route et attendre qu'elle soit déployée. Pas de déploiement à chaud.

D'abord, pourquoi utilisez-vous Maven comme ça ? Je ne l'utilise pas. J'utilise mon IDE pour écrire des tests, coder jusqu'à ce qu'ils réussissent, remanier, déployer, déployer à chaud et exécuter une construction Maven locale lorsque j'ai terminé, avant de valider, pour m'assurer que je ne casserai pas la construction continue.

Deuxièmement, je ne suis pas sûr que l'utilisation de Ant améliorerait beaucoup les choses. Et d'après mon expérience, les constructions Maven modulaires utilisant des dépendances binaires me donnent un temps de construction plus rapide que les constructions Ant monolithiques typiques. Quoi qu'il en soit, jetez un coup d'œil à Maven Shell pour un environnement Maven prêt à être (re)utilisé (qui est d'ailleurs génial).

Au final, et je suis désolé de le dire, ce n'est pas vraiment Maven qui tue votre productivité, c'est vous qui utilisez mal vos outils. Et si vous n'en êtes pas satisfait, eh bien, que puis-je dire, ne l'utilisez pas. Personnellement, j'utilise Maven depuis 2003 et je n'ai jamais regardé en arrière.

Answer 2

Maven peut être considéré comme un outil complet de développement de projet et pas seulement comme un outil de construction comme Ant. Vous devriez utiliser IDE Eclipse avec plugin maven pour régler tous vos problèmes.

Voici quelques avantages de Maven, cités dans le document Avantages de l'utilisation de Maven page :

Henning

• configuration rapide du projet, pas de fichiers build.xml compliqués, juste un POM et c'est parti.
• tous les développeurs d'un projet utilisent les mêmes dépendances jar grâce à un POM centralisé.
• obtenir "gratuitement" un certain nombre de rapports et de métriques pour un projet
• réduire la taille des distributions de sources, car les bocaux peuvent être tirés d'un emplacement central

Emmanuel Venisse

• beaucoup d'objectifs sont disponibles, il n'est donc pas nécessaire de développer une partie spécifique du processus de construction, contrairement à ce qui se passe dans les autres pays. partie spécifique du processus de construction contrairement à ANT nous pouvons réutiliser des tâches ANT existantes dans le processus de construction avec le plugin antrun

Jesse Mcconnell

• Favorise la conception modulaire du code. En simplifiant la gestion de plusieurs projets, elle projets, la conception peut être en plusieurs parties logiques, tissant ces parties ensemble à travers l'utilisation du suivi des dépendances dans les dans les fichiers pom.
• Exige une conception modulaire du code. Il est facile de faire l'éloge du code modulaire, mais lorsque le code est séparé en plusieurs parties, il est difficile d'y parvenir. mais lorsque le code est dans des projets de compilation projets de compilation séparés, il est impossible de pollinisation croisée des références entre modules de code, à moins que vous que vous l'autorisiez spécifiquement dans votre gestion des dépendances... il n'y a pas de il n'y a pas d'implémentation "je vais juste faire ça maintenant et le corriger plus tard".
• La gestion des dépendances est clairement déclarée. Avec le mécanisme de gestion des dépendances, vous devez essayer d'améliorer la qualité de votre travail. mécanisme de gestion des dépendances, vous devez essayer de bousiller votre jar versioning... il n'y a pas de problème classique de problème classique de "quelle version de version de ce jar de fournisseur ? Et la mise en place Et le mettre en place sur un projet existant le dessus de la pagaille existante si elle existe lorsque vous êtes forcé de faire des versions 'inconnues' dans votre référentiel pour faire fonctionner les choses... ou bien mentir à vous-même que vous connaissez la version réelle de ABC.jar.
• cycle de vie fortement typé il existe un cycle de vie fortement défini qu'un qu'un système logiciel traverse depuis le l'initiation d'une construction jusqu'à la fin... et les utilisateurs sont autorisés à mélanger et leur système au cycle de vie au lieu de bricoler leur propre cycle de vie... cela a l'avantage supplémentaire l'avantage supplémentaire de permettre aux gens de se déplacer d'un projet à un autre et de parler en utilisant le même vocabulaire en termes de construction de logiciels

Vincent Massol

• Un plus grand élan : Ant est maintenant un héritage et ne progresse pas rapidement. Maven est avance rapidement et il y a une potentiel d'avoir beaucoup d'outils de grande valeur outils de grande valeur autour de Maven (CI, Dashboard projet, intégration IDE, etc).

Answer 3

Il n'est pas difficile de déterminer les dépendances pour les petits projets. Mais une fois que vous commencez à traiter un arbre de dépendances avec des centaines de dépendances, les choses peuvent facilement devenir incontrôlables. (Je parle en connaissance de cause ici ...)

L'autre point est que si vous utilisez un IDE avec compilation incrémentale et support Maven (comme Eclipse + m2eclipse), alors vous devriez être en mesure de mettre en place un système d'édition/compilation/déploiement à chaud et de test.

Personnellement, je ne le fais pas car j'ai fini par me méfier de ce mode de développement en raison de mauvaises expériences dans le passé (avant Maven). Peut-être quelqu'un peut-il nous dire si cela fonctionne réellement avec Eclipse + m2eclipse.

Answer 4

Maven est l'un des outils où vous devez réellement décider que vous l'aimez et que vous voulez l'utiliser, car vous passerez un certain temps à l'apprendre, et le fait d'avoir pris cette décision une fois pour toutes vous permettra d'éviter toutes sortes de doutes pendant l'apprentissage (car vous comme et veulent pour l'utiliser) !

Les conventions fortes aident à de nombreux endroits - comme Hudson qui peut faire des merveilles avec les projets Maven - mais cela peut être difficile à voir au départ.

Answer 5

Les avantages de Maven par rapport à Ant sont assez nombreux. J'essaie de les résumer ici.

La convention plutôt que la configuration
Mave utilise une approche distinctive pour la mise en page et le démarrage du projet, qui permet de se lancer facilement dans un projet. En général, il suffit d'utiliser le checkount et la commande maven pour obtenir les artefacts du projet.

Modularisation des projets
Les conventions de projet suggèrent (ou mieux, obligent) le développeur à modulariser le projet. Au lieu d'un projet monolithique, vous êtes souvent obligé de diviser votre projet en sous-composants plus petits, ce qui facilite le débogage et la gestion de la structure globale du projet.

Gestion des dépendances et cycle de vie du projet
Globalement, avec une bonne configuration SCM et un référentiel interne, la gestion des dépendances est assez facile, et vous êtes à nouveau obligé de penser en termes de cycle de vie du projet - versions des composants, gestion des versions, etc. Un peu plus complexe que la fourmi quelque chose, mais là encore, une amélioration de la qualité du projet.

Quel est le problème avec maven ?
Maven n'est pas facile. Le cycle de construction (ce qui est fait et quand) n'est pas très clair dans le POM. En outre, la qualité des composants et les dépendances manquantes dans les dépôts publics posent problème.
La meilleure approche (pour moi) est d'avoir un référentiel interne pour mettre en cache (et conserver) les dépendances, et d'appliquer la gestion des versions des composants. Pour les projets plus importants que les exemples de projets dans un livre, vous remercierez maven avant ou après