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

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.

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.

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

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.

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

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

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.

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.

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.

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.