Pourquoi maven? Quels sont les bénéfices? [fermé]


131

Quels sont les principaux avantages de l'utilisation de maven par rapport à, disons, fourmi? Cela semble être plus un ennui qu'un outil utile. J'utilise maven 2, avec Eclipse Java EE (pas de m2eclipse) et tomcat.

Les partisans de maven croient que

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

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

Dans mon expérience

  1. Comprendre les dépendances des packages n'est vraiment pas si difficile. De toute façon, vous le faites rarement. Probablement une fois lors de la configuration du projet et quelques autres lors des mises à niveau. Avec maven, vous finirez par corriger les dépendances qui ne correspondent pas, les poms mal écrits et faire quand même des exclusions de paquets.

  2. Cycle lent FIX-COMPILE-DEPLOY-DEBUG, qui tue la productivité. C'est mon principal reproche. Vous effectuez un changement, vous devez attendre le lancement de maven build et attendre son déploiement. Aucun déploiement à chaud du tout.

Ou est-ce que je fais juste mal? Veuillez m'indiquer la bonne direction, je suis toutes les oreilles.


1
Je suis vraiment intéressé par le point 2. Quelqu'un d'autre remarque-t-il le lent cycle fix-compile-deploy? ou tout le monde le sait, mais se tait à ce sujet car maven est la meilleure chose que nous ayons / la plus courante / la plus cool. Créer une guerre / oreille à déployer est déjà assez mauvais, maven aggrave les choses. Il faut environ 5 secondes sur ma machine pour afficher un changement de jsp sur un projet maven, sur une structure de répertoires éclatée? moins de 1 sec. Je peux enregistrer plusieurs fois, et il ne compile que la dernière modification, sur maven? chaque sauvegarde déclenche une construction.
trix

Peut-être que maven n'est pas le problème ici, mais le support / plugin IDE? Cependant, maven existe depuis un certain temps, si nous ne pouvons pas faire les choses correctement, devrions-nous déplacer / inventer / proposer autre chose? outre Ivy
trix

2
@Javid Bien que le titre de la question semble similaire, le corps de la question est différent IMO et je ne le considère pas comme une dupe.
Pascal Thivent


Pendant une seconde, on aurait dit que vous parliez de NuGet ...
micahhoover

Réponses:


108

Comprendre les dépendances des packages n'est vraiment pas si difficile. De toute façon, vous le faites rarement. Probablement une fois lors de la configuration du projet et quelques autres lors des mises à niveau. Avec maven, vous finirez par corriger les dépendances qui ne correspondent pas, les poms mal écrits et faire quand même des 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 avoir de manière transitoire, d'avoir un schéma de dénomination standardisé pour eux. Gérer tout cela manuellement à 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, tu dois faire la même chose travail, sauf que vous devez tout faire manuellement: saisir une version du projet A et ses dépendances, saisir une version du projet B et ses dépendances, déterminer vous-même quelles versions exactes ils utilisent, vérifier qu'ils ne se chevauchent pas, en vérifiant qu'ils ne sont pas incompatibles, etc. Bienvenue en enfer.

D'autre part, Maven prend en charge la gestion des dépendances et les récupérera de manière transitoire pour moi et me donne les outils dont j'ai besoin pour gérer la complexité inhérente à la gestion des dépendances : je peux analyser une arborescence de dépendances, contrôler les versions utilisées dans les dépendances transitives, exclure certaines des les si nécessaire, contrôler Converge entre les modules, etc. Il n'y a pas de magie. Mais au moins, vous avez du soutien.

Et n'oubliez pas que la gestion des dépendances n'est qu'une petite partie de ce que propose Maven, 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 effectuez un changement, vous devez attendre le lancement de maven build et attendre son déploiement. Aucun déploiement à chaud du tout.

Premièrement, pourquoi utilisez-vous Maven comme ça? Je ne. J'utilise mon IDE pour écrire des tests, du code jusqu'à ce qu'ils réussissent, refactoriser, déployer, déployer à chaud et exécuter une version locale de Maven lorsque j'ai terminé, avant de m'engager, pour m'assurer de ne pas casser la construction continue.

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

Donc à la fin, et je suis désolé de le dire, ce n'est pas vraiment Maven qui tue votre productivité, c'est vous qui abusez de vos outils. Et si vous n'ê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.


@Pascal, pouvez-vous dire quels outils vous utilisez? IDE, plugins, etc. Êtes-vous en train de nous dire que si je change un fichier .properties, ou un fichier jsp, il sera déployé à chaud sans faire de build maven? (peut-être que le déploiement à chaud n'est pas le terme correct ici). Je ne savais pas ce que je voulais dire par fourmi. Je voulais dire utiliser le répertoire éclaté standard pendant le développement et utiliser ant pour créer une guerre / oreille avant la sortie. Pour un répertoire éclaté, les règles sont simples, copiez / compilez les fichiers de src vers les classes et ne touchez pas au reste.
trix

suite ... Cependant, dans mes projets, ce qui est déployé sur tomcat, ce sont les jars des modules. Si je change un .jsp, maven ne doit-il pas reconstruire ces fichiers jar?
trix

4
Vous devez admettre que la plupart des projets sont des projets de jouets, c'est-à-dire de simples dépendances. C'est juste la loi des statistiques.
trix

2
@trix, à propos du déploiement à chaud fourmi vs maven: si vous ne faites pas de génération de fourmi pour un déploiement à chaud, pourquoi utilisez-vous Maven pour le même? Je suppose que si vous utilisez fourmi pour la même chose, cela prendrait au moins le même temps ... n'est-ce pas?
Reddy

2
Alors Pascal, pourriez-vous nous dire comment avez-vous un projet configuré à Maven nature et n'utilisez pas le processus de construction pour le déployer? C'est le point 2 de la question initiale. Je me demande comment faire cela, alors appréciez vraiment si vous êtes en mesure de nous donner une explication claire.

20

Maven peut être considéré comme un outil de développement de projet complet, pas seulement un outil de création comme Ant. Vous devez utiliser Eclipse IDE avec le plugin maven pour résoudre tous vos problèmes.

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

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 en raison du POM centralisé.
  • obtenir un certain nombre de rapports et de statistiques pour un projet "gratuitement"
  • réduire la taille des distributions source, car les bocaux peuvent être extraits 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 à ANT, nous pouvons réutiliser les 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, il permet à la conception d'être organisée en plusieurs parties logiques, en tissant ces parties ensemble grâce à l'utilisation du suivi des dépendances dans les fichiers pom.
  • Applique la conception modulaire du code. il est facile de payer lipservice au code modulaire, mais lorsque le code est dans des projets de compilation séparés, il est impossible de croiser les références entre les modules de code à moins que vous ne l'autorisiez spécifiquement dans votre gestion des dépendances ... il n'y a pas de 'je vais faites-le simplement maintenant et corrigez-le plus tard.
  • La gestion des dépendances est clairement déclarée. avec le mécanisme de gestion des dépendances, vous devez essayer de bousiller la gestion des versions de votre fichier jar ... il n'y a aucun problème classique de «quelle version de ce fichier jar est-il? Et le configurer sur un projet existant déchire le sommet du désordre existant s'il existe lorsque vous êtes obligé de créer des versions `` inconnues '' dans votre référentiel pour que les choses soient opérationnelles ... cela ou vous mentir que vous connaissez le version actuelle d'ABC.jar.
  • cycle de vie fortement typé il y a un cycle de vie défini fort qu'un système logiciel traverse du début d'une construction à la fin ... et les utilisateurs sont autorisés à mélanger et assortir leur système au cycle de vie au lieu de bricoler leur propre cycle de vie. Cela présente l'avantage supplémentaire de permettre aux gens de passer d'un projet à un autre et de parler en utilisant le même vocabulaire en termes de création de logiciels

Vincent Massol

  • Un plus grand élan: Ant est désormais hérité et n'évolue pas rapidement. Maven avance rapidement et il est possible d'avoir de nombreux outils de grande valeur autour de Maven (CI, projet Dashboard, intégration IDE, etc.).

5
Lors du vote vers le bas, veuillez fournir une raison, ce n'est pas dit, mais une règle éthique sur le stackoverflow.
YoK

1
Il n'y a rien de mal avec les références, mais vous devez vraiment préciser que le contenu ne vous appartient pas.
Pascal Thivent

Merci. Je vais m'assurer de le citer autrement qu'en mentionnant simplement d'où il a été référencé. juste 30 jours impairs à stackoverflow et toujours en train d'apprendre l'art :).
YoK

11

Déterminer les dépendances pour les petits projets n'est pas difficile. 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 d'expérience ici ...)

L'autre point est que si vous utilisez un IDE avec une compilation incrémentielle et un support Maven (comme Eclipse + m2eclipse), vous devriez être en mesure de configurer éditer / compiler / déployer et tester à chaud.

Personnellement, je ne fais pas cela parce que 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 que quelqu'un peut dire si cela fonctionne réellement avec Eclipse + m2eclipse.


On pourrait commencer par maven pour obtenir toutes les dépendances puis copier les dépendances dans son projet, non?
trix

2
Je suppose que vous pourriez. Mais cela risquerait de se rompre si vous mettiez à jour les dépendances de votre projet ... ou si votre projet dépendait d'instantanés.
Stephen C

Je veux dire avoir 2 projets, le seul but du projet maven est d'obtenir des dépendances. Utilisez le contrôle de version pour suivre les modifications entre les mises à jour des dépendances. Je le fais quand même, juste pour que je puisse voir les changements, au cas où cela casse ma construction.
trix

4
Ughh. Ce n'est pas ainsi que Maven est conçu pour être utilisé. L'un des grands avantages de Maven est d'éviter de vérifier les bibliothèques dépendantes dans le contrôle de version. Avec votre approche, vous encombrerez votre VCS avec de nombreuses versions de nombreux fichiers binaires. Et certains VCS sont particulièrement mauvais pour gérer les fichiers binaires.
Stephen C

2
Généralement, vous apprenez à être très fatigué de toute sorte de magie lors de l'écriture de programmes: -S
Thorbjørn Ravn Andersen

9

Maven est l'un des outils où vous devez réellement décider à l'avance que vous l'aimez et que vous voulez l'utiliser, car vous passerez un certain temps à l'apprendre, et avoir pris cette décision une fois pour toutes vous permettra de sauter toutes sortes. du doute en apprenant (parce que vous l' aimez et que vous voulez l' utiliser)!

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

edit: Depuis 2016, Maven est le seul outil de construction Java où les trois principaux IDE peuvent utiliser les sources prêtes à l'emploi. En d'autres termes, l'utilisation de maven rend votre build indépendante de l'IDE. Cela permet par exemple d'utiliser le profilage Netbeans même si vous travaillez normalement dans eclipse


1
Et le contraire est également vrai, beaucoup de gens viennent au maven avec une haine préconçue, parce que ce n'est pas une fourmi, etc.
Goibniu

L'opposé? Vous voulez dire?
Thorbjørn Ravn Andersen

9

Les avantages de Maven par rapport à la fourmi sont nombreux. J'essaye de les résumer ici.

Convention sur la configuration
Maven utilise une approche distincte pour la mise en page et le démarrage du projet, qui permet de se lancer facilement dans un projet. Habituellement, il ne faut que le checkount et la commande maven pour obtenir les artefacts du projet.

Modularisation du projet
projet Les conventions du 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
Dans l'ensemble, avec une bonne configuration SCM et un référentiel interne, la gestion des dépendances est assez simple, 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 encore une fois, 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 si clair dans le POM. En outre, certains problèmes surviennent avec la qualité des composants et les dépendances manquantes dans les référentiels publics.
La meilleure approche (pour moi) est d'avoir un référentiel interne pour la mise en cache (et la conservation) des dépendances, et de l'appliquer à la gestion des versions des composants. Pour les projets plus grands que les exemples de projets dans un livre, vous remercierez maven avant ou après


6

Maven peut offrir des avantages pour votre processus de construction en utilisant des conventions et des pratiques standard pour accélérer votre cycle de développement tout en vous aidant à atteindre un taux de réussite plus élevé. Pour un aperçu plus détaillé de la manière dont Maven peut vous aider dans votre processus de développement, veuillez consulter les avantages de l'utilisation de Maven.


3

Maven est un puissant outil de gestion de projet basé sur POM (Project Object Model). Il est utilisé pour la construction de projets, les dépendances et la documentation. Cela simplifie le processus de construction comme ANT. Mais c'est trop avancé que ANT. Maven aide à gérer - Builds, Documentation, Reporing, SCMs, Releases, Distribution. - Le référentiel maven est un répertoire de fichier JAR empaqueté avec le fichier pom.xml. Maven recherche les dépendances dans les référentiels.


2

Je n'ai jamais rencontré le point 2? Pouvez-vous expliquer pourquoi vous pensez que cela affecte le déploiement de quelque manière que ce soit? Si quoi que ce soit, maven vous permet de structurer vos projets de manière modulaire qui autorise en fait les correctifs pour les bogues dans un niveau particulier, et permet le développement indépendant d'une API à partir du reste du projet par exemple.

Il est possible que vous essayiez de tout entasser dans un seul module, auquel cas le problème n'est pas vraiment génial, mais la façon dont vous l'utilisez.


J'utilise eclipse jee, maven 2 et tomcat. De toute évidence, une application Web. Si je change un fichier de propriétés, ou un jsp, afin de voir mes modifications sur tomcat, maven doit faire sa construction, créer un war / ear et déployer sur tomcat. C'est lent par rapport à si j'utilise une structure de répertoires éclatée.
trix

1
@trix Hot deploy sous Eclipse avec Tomcat fonctionne juste. Vous le faites mal.
Pascal Thivent

0

Cela aurait dû être un commentaire, mais cela ne correspondait pas à une longueur de commentaire, alors je l'ai posté comme réponse.

Tous les avantages mentionnés dans d'autres réponses sont réalisables par des moyens plus simples que l'utilisation de maven. Si, par exemple, vous êtes nouveau dans un projet, vous passerez de toute façon plus de temps à créer une architecture de projet, à joindre des composants, à coder que de télécharger des fichiers JAR et de les copier dans le dossier lib. Si vous êtes expérimenté dans votre domaine, vous savez déjà comment démarrer le projet avec quelles bibliothèques. Je ne vois aucun avantage à utiliser maven, surtout quand cela pose beaucoup de problèmes tout en faisant automatiquement la "gestion des dépendances".

Je n'ai qu'une connaissance de niveau intermédiaire de maven, mais je vous le dis, j'ai réalisé de gros projets (comme des ERP) sans utiliser maven.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.