Pourquoi Maven a-t-il une si mauvaise réputation? [fermé]


99

On parle beaucoup sur Internet de la façon dont Maven est mauvais. J'utilise certaines fonctionnalités de Maven depuis quelques années maintenant et l'avantage le plus important à mon avis est la gestion des dépendances.

La documentation Maven est loin d'être adéquate, mais généralement, lorsque j'ai besoin d'accomplir quelque chose, je le découvre une fois, puis cela fonctionne (par exemple, lorsque j'ai implémenté la signature des fichiers JAR). Je ne pense pas que Maven soit génial, mais cela résout certains problèmes qui sans cela seraient une véritable douleur.

Alors, pourquoi Maven a-t-il une si mauvaise réputation et à quels problèmes avec Maven puis-je m'attendre à l'avenir? Peut-être qu'il existe de bien meilleures alternatives que je ne connais pas? (Par exemple, je n'ai jamais regardé Ivy en détail.)

REMARQUE: il ne s'agit pas d'une tentative de provoquer un argument. C'est une tentative d'effacer le FUD.


29
Je n'ai jamais entendu personne parler en mal de Maven. J'ai trouvé que les projets étaient beaucoup plus productifs avec Maven qu'avec Ant.
Taylor Leese

2
Je suis d'accord avec Taylor. Je n'ai pas utilisé Maven, mais j'ai entendu beaucoup de gens en dire beaucoup. Cette question ressemble beaucoup à FUD.
Matthew Flaschen

27
@Taylor, @Matthew, @victor: Je suis surpris que vous n'ayez pas vu certains des coups de gueule Maven. C'est un outil très controversé. C'est un vrai truc d'amour ou de haine. Certaines personnes aiment l'intelligence de la gestion des dépendances et accusent ceux qui ne l'aiment pas de ne pas l'obtenir, et certaines personnes ne voient que les problèmes qui peuvent survenir et se produisent avec des dépendances distribuées complexes et décident que cela ne vaut pas la peine.
Dan Dyer le

8
Maven ne respecte pas le principe KISS. Essayez de faire autre chose que mvn clean install et vous êtes en difficulté. Avec fourmi, vous pouvez faire ce que vous voulez sans aucune douleur.
TraderJoeChicago

4
Ce n'est qu'une anecdote, mais le passage de Maven à Ant a fait passer nos temps de construction incrémentiels de ~ 15s à bien plus de 2 minutes. Vous ne trouverez pas beaucoup de fans de Maven dans notre équipe.
Peter Bratton

Réponses:


141

J'ai examiné maven il y a environ six mois. Nous démarrions un nouveau projet et n'avions aucun héritage à soutenir. Cela dit:

  • Maven est tout ou rien. Ou du moins pour autant que je puisse dire d'après la documentation. Vous ne pouvez pas facilement utiliser maven en remplacement de la fourmi et adopter progressivement des fonctionnalités plus avancées.
  • Selon la documentation, Maven est un bonheur transcendantal qui réalise tous vos rêves les plus fous. Il vous suffit de méditer sur le manuel pendant 10 ans avant de devenir éclairé.
  • Maven rend votre processus de construction dépendant de votre connexion réseau.
  • Maven a des messages d'erreur inutiles. Comparez «La cible x n'existe pas dans le projet y» de fourmi avec «Tâche non valide 'run' de mvn: vous devez spécifier une phase de cycle de vie valide, ou un objectif au format plugin: goal ou pluginGroupId: pluginArtifactId: pluginVersion: goal» il suggère que je lance mvn avec -e pour plus d'informations, ce qui signifie qu'il affichera le même message, puis une trace de pile pour une BuildFailureException.

Une grande partie de mon aversion pour maven peut être expliquée par l'extrait suivant de Better Builds with Maven:

Quand quelqu'un veut savoir ce qu'est Maven, il demande généralement «Qu'est-ce que Maven exactement?», Et s'attend à une réponse courte et expressive. «Eh bien, c'est un outil de construction ou un cadre de script» Maven est plus de trois mots ennuyeux et sans intérêt. C'est une combinaison d'idées, de normes et de logiciels, et il est impossible de distiller la définition de Maven à des extraits sonores simplement digérés. Les idées révolutionnaires sont souvent difficiles à transmettre avec des mots.

Ma suggestion: si vous ne pouvez pas transmettre les idées avec des mots, vous ne devriez pas essayer d'écrire un livre sur le sujet, car je ne vais pas absorber les idées par télépathie.


134
Pour ceux qui comprennent Maven, aucune explication n'est nécessaire. Pour ceux qui ne le font pas, aucune explication n'est possible.
Apocalisp

35
L'un de vos puces est faux. -o - mode hors ligne, donc non, cela ne rend pas votre processus de construction dépendant de votre connexion réseau.
MetroidFan2002

10
Je suis d'accord sur le tout ou rien. J'ai vu beaucoup de gens perdre trop de temps à essayer de garder la moitié de leur portefeuille de projets en fourmi et l'autre moitié en maven. Une fois que vous vous êtes engagé, vous devez effectuer le travail pour convertir chaque partie de votre déploiement.
sal

14
@Apocalisp: Donc, en d'autres termes, les seules personnes qui comprennent Maven sont les personnes qui l'ont écrit?
Powerlord

5
Maven est tout ou rien. Ce n'est pas vrai. Vous pouvez utiliser maven pour la gestion des dépendances et rien d'autre si vous le souhaitez. Tout ce qu'il faut, c'est un exemple pratique d'utilisation des tâches Maven ant pour lire votre fichier pom et générer un chemin de classe ANT contenant toutes vos dépendances.
Jherico

109
  • Il vous impose une structure rigide dès le départ.
  • Il est basé sur XML, il est donc aussi difficile à lire que l'était ANT.
  • Son rapport d'erreur est obscur et vous laisse bloqué lorsque les choses tournent mal.
  • La documentation est médiocre.
  • Cela rend les choses difficiles faciles et les choses simples difficiles.
  • Il faut trop de temps pour maintenir un environnement de construction Maven, ce qui va à l'encontre de l'intérêt d'avoir un système de construction tout chantant.
  • Il faut beaucoup de temps pour comprendre que vous avez trouvé un bogue dans maven et que vous n'avez pas configuré quelque chose de mal. Et les bugs existent, et dans des endroits surprenants.
  • Il promet beaucoup mais vous trahit comme un amant beau et séduisant mais émotionnellement froid et manipulateur.

45
++ Cela rend les choses difficiles faciles et les choses simples difficiles. C'est tellement vrai!
Martin K.

8
"Cela promet beaucoup mais vous trahit comme une amante belle et séduisante mais émotionnellement froide et manipulatrice." hahahaha ... cela ressemble beaucoup à ce maître fong de "Balls of Fury"
cesar

8
Re puce 2: Il utilise des éléments presque toujours, des attributs presque jamais, donc le XML est encore plus difficile à lire que celui d'Ant!
Carl Smotricz

4
+1 pour la dernière puce. Rien ne fait que ma journée ressemble à une analogie géniale et hilarante qui est si vraie.
Adam

1
La documentation n'est pas pauvre, elle est excellente.
HDave le

96

J'ai certainement râlé et gémi à propos de maven dans le passé. Mais maintenant, je ne serais pas sans ça. Je pense que les avantages l'emportent largement sur les problèmes. Principalement:

  • Structure de projet standardisée.
    • Étant donné qu'un nouveau développeur rejoint un projet:
      • Lorsque vous dites que c'est un projet Maven, le développeur connaît la disposition du projet et comment créer et empaqueter le projet
      • Lorsque vous dites que c'est un projet Ant, le développeur devra attendre que vous expliquiez plus ou devra passer par le build.xml pour comprendre les choses.
    • Bien sûr, il est toujours possible d'imposer un standard à l'échelle de l'entreprise avec Ant, mais je pense que le plus souvent, vous réinventerez la roue proverbiale.
  • Gestion des dépendances.
    • Non seulement avec des bibliothèques externes, mais aussi avec des bibliothèques / modules internes. Assurez-vous d'utiliser un serveur proxy de référentiel Maven tel que Nexus ou Artifactory .
    • Il est possible de faire une partie de cela avec Ivy . En fait, si vous n'avez besoin que d'une gestion des dépendances, vous feriez probablement mieux d'utiliser Ivy.
  • Particulièrement au sein d'un projet. J'ai trouvé très utile d'éclater de petits sous-projets, et maven gère bien cela. C'est beaucoup plus difficile avec la fourmi.
  • Gestion standardisée des artefacts (en particulier en association avec un nexus ou un artefact )
  • Le plugin release est merveilleux.
  • L'intégration Eclipse & NetBeans est assez bonne.
  • L'intégration avec hudson est superbe. En particulier, les graphiques de tendance pour des choses comme les findbugs.
  • Il est un point mineur, mais le fait que Maven Incorporations détails comme le numéro de version dans le pot ou la guerre ( et pas seulement dans le nom de fichier) par défaut est extrêmement utile.

Les inconvénients pour moi sont principalement:

  • La ligne de commande n'est pas très utile. Cela m'a beaucoup découragé au début.
  • Le format XML est très détaillé. Je peux voir pourquoi cela a été fait de cette façon, mais c'est toujours difficile à lire.
    • Cela dit, il a un XSD pour une édition facile dans un IDE.
  • Il est difficile de se faire une idée au début. Des choses comme le cycle de vie, par exemple.

Je crois sincèrement que cela vaut la peine de passer un peu de temps à connaître maven.


2
Le format XML ne me dérange pas particulièrement (Eclipse peut s'occuper de la plupart des parties fastidieuses) et les instructions de construction pour les grands projets sont généralement désagréables et complexes de toute façon. Par exemple, vous ne vous êtes pas vraiment cogné la tête sur un mur de briques jusqu'à ce que vous ayez essayé de convaincre GNU automake de faire quelque chose qui ne lui importe pas…
Donal Fellows

2
IntelliJ dispose également d'un excellent support Maven.
Steven Benitez

1
Oh regardez une réponse sensée avec des détails.
Tim O'Brien

80

Mon expérience pratique de deux grands projets est que nous avons passé 1000 à 1500 heures pour chaque projet sur des problèmes liés à maven, à l'exclusion d'un effort de 500 heures pour passer de maven 1 à maven 2.

Depuis, je dois dire que je déteste absolument les maven. Je suis frustré quand j'y pense.

L'intégration Eclipse est horrible. (Nous avons eu des problèmes sans fin avec la génération de code par exemple, où eclipse s'est désynchronisée avec le code généré, et a nécessité une reconstruction complète, assez souvent. Le blâme est à la fois maven et eclipse, mais eclipse est plus utile que maven et disons emacs, donc l'éclipse reste et les maven doivent partir.)

Nous avions beaucoup de dépendances, et comme nous l'avons découvert, les erreurs de syntaxe sont en fait assez souvent commises dans des référentiels publics maven, ce qui peut ruiner des heures de votre temps précieux. Chaque semaine. La solution de contournement consiste à avoir un proxy ou un référentiel régi localement et cela a également pris un certain temps.

La structure du projet Mavens n'est pas vraiment adaptée au développement avec Eclipse, et le temps de construction dans eclipse augmente.

Un effet du problème de génération de code et de synchronisation, nous avons dû reconstruire à partir de scrach assez souvent, réduisant votre cycle de code / compilation / test à un cycle de compilation / websurf / sleep / die / code sans fin, vous renvoyant aux années 90 et Temps de compilation de 40 minutes.

La seule excuse pour maven est la résolution des dépendances, mais j'aimerais le faire de temps en temps, pas dans chaque build.

Pour résumer, maven est aussi loin que possible de KISS. Et aussi, les défenseurs ont tendance à être le type de personnes qui célèbrent davantage leur anniversaire lorsque leur âge est un nombre premier. N'hésitez pas à voter contre moi :-)


3
Je suis d'accord avec certains de ce que vous dites en fait, même si je pense avoir finalement raison. Pour obtenir ce que vous voulez cependant, vous pouvez jeter un œil à Ivy, ne l'avez pas encore essayé mais il semble apporter la gestion des dépendances dans un environnement Ant plus structuré.
Newtopian

5
Alors, avez-vous trouvé une bonne alternative à Maven?
Thilo

4
L'intégration Eclipse est toujours horrible. Malgré les plugins à jour, il existe des tâches maven contrôlées par plugin qui échouent avec des messages d'erreur obscurs. Les collègues me disent alors de passer à un shell de commande et d'exécuter la même commande ... alors cela fonctionne mystérieusement. Eclipse est un environnement mature, le plugin maven est loin derrière.
Carl Smotricz

2
Il existe une différence fondamentale dans la manière dont Maven et Eclipse définissent ce qu'est un projet. Dans Maven, un projet est plus ou moins un moyen pratique d'organiser le code source. Eclipse a été initialement conçu pour que vous puissiez travailler sur un ou plusieurs projets plus ou moins indépendants en même temps. Les exigences ultérieures (pas toujours saines) conduisent les IBM à abuser des projets en tant que «modules» que Eclipse gère en fait plutôt mal. Afin de faire converger les définitions, dans de nombreux cas, les projets maven devraient probablement être mappés vers les dossiers source d'éclipse. Cependant, comme maven est nul, pourquoi s'embêter.
KarlP

3
Hey! Je déplore le fait que la prochaine fois que je serai dans la force de l'âge est de 29 ans, et le prochain âge du cube parfait est de 64 ans, et mon dernier âge parfait sera de 32 ans ... mais je ne préconise pas activement maven.
cwallenpoole

46

Maven est génial. La raison de sa réputation a à voir avec la courbe d'apprentissage abrupte, à mon avis. (ce que je suis enfin sur le point de surmonter)

La documentation est un peu difficile à parcourir, simplement parce que l'on a l'impression qu'il y a beaucoup de texte et de nouvelles choses à comprendre avant de commencer à avoir un sens. Je dis que le temps est tout ce qu'il faut pour que Maven soit plus largement salué.


6
Cela peut être un peu vrai, mais j'ai trouvé que l'utilisation de l'intégration de Maven avec Eclipse aide vraiment à réduire la courbe d'apprentissage pour les gens. m2eclipse.codehaus.org
Taylor Leese

2
@Taylor, j'ai eu beaucoup de problèmes avec le plug-in, surtout si vous utilisez une autre version d'Eclipse ou paradis interdit RAD. Je pense que ça y arrive, cependant ...
Dan

Je ne l'ai utilisé qu'avec Eclipse 3.3, 3.4 et le studio de développement JBoss et j'ai convenu qu'il y avait quelques ennuis mineurs (comme l'éditeur POM ne joue pas bien) mais je n'ai pas eu de problèmes majeurs.
Taylor Leese

10
Ce n'est pas la courbe d'apprentissage qui me dérange. Ce n'est vraiment pas si difficile à comprendre. Mon problème est que pour les grands projets (commerciaux), vous obtenez beaucoup moins de valeur que l'effort dépensé. OK, vos projets se construisent. Cool, mais le coût d'une année-homme passée, des échecs de construction constants dus à des facteurs externes, des compilations de 10 minutes au lieu de 5 secondes et un espace de travail horrible d'éclipse, cela n'en vaut tout simplement pas la peine. De plus, pour le même coût, vous pouvez plus ou moins embaucher un gars qui construit constamment le coffre manuellement.
KarlP

8
@Karlp - eh bien, vous ne le comprenez pas encore complètement ... 1.) "échecs dus à des facteurs externes" - vous devez créer un référentiel de projet dans lequel vous gardez toutes vos dépendances et dont vous contrôlez les versions. 2.) "Compilation de 10 minutes au lieu de 5 secondes" - peut-être pour l'installation initiale de maven et la première construction - maven télécharge toutes les dépendances dont il a besoin ainsi que votre projet - mais les versions régulières que vous faites pour essayer de créer votre propre code ne devraient pas être en téléchargement - voir 1 - également, en mode hors ligne. 3.) "ugly eclipse workspace" - maven fonctionne dans tous les principaux IDE (NB, IntelliJ) et depuis la ligne de commande.
Nate

24

Parce que Maven est un appareil pour réduire les hommes adultes à des masses sanglantes de terreur absolue.


3
Nous devrions le produire en masse et le vendre à tous les méchants pour un énorme profit!
Joachim Sauer

7
Non! Maven ne peut pas être utilisé à des fins lucratives. Il ne peut être utilisé que pour le mal.
Apocalisp

18

Avantages:

  • Gestion des dépendances. Depuis plusieurs années déjà, mes collègues et moi ne téléchargeons et ne gérons pas les dépendances manuellement. Cela permet un immense gain de temps.
  • Indépendance IDE. Il s'avère que tous les principaux IDE, Eclipse, IDEA et NetBeans ont un support décent des projets Maven afin que nos développeurs ne soient pas enfermés dans un IDE particulier.
  • Ligne de commande. Avec Maven, la prise en charge simultanée des configurations IDE et de ligne de commande est simple, ce qui est bon pour une intégration continue.

Les inconvénients:

  • Vous devez investir dans l'apprentissage de Maven. Eh bien, dois le faire. Bonne nouvelle, tout le monde dans l'équipe n'a pas à apprendre.
  • Documentation. Autrefois un problème, maintenant grâce à Sonatype et à leur livre ( http://www.sonatype.com/products/maven/documentation/book-defguide ), la situation est bien meilleure.
  • Rigidité. Il est parfois difficile et frustrant de faire les choses comme vous le souhaitez. Mon conseil serait de ne pas se battre et de ne pas obliger Maven à faire les choses qu'il fait le mieux, des constructions simples ou quand un mojo stable est disponible. Dans d'autres cas, nous abandonnons et faisons des choses avec des tâches Ant ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) ou des programmes externes. Mon préféré est Groovy plugun ( http://groovy.codehaus.org/GMaven ).

Compétition:

  • Ant: n'a pas de gestion des dépendances. Période.
  • Ivy: encore moins mature que Maven (non que ce dernier n'ait pas ses bizarreries aussi) Presque le même ensemble de fonctionnalités, donc aucune raison impérieuse de déménager. J'ai fait plusieurs tentatives pour l'essayer; tout échoue.

Conclusion: tous nos projets sont réalisés avec Maven depuis plusieurs années déjà.


3
Ant ne rivalise pas avec Maven. Ivy n'est pas en concurrence avec Maven (il est en concurrence avec les tâches de Maven Ant). Maven est plus qu'un outil de build + gestion des dépendances. Période.
Pascal Thivent

18

Je pense qu'il a mauvaise réputation auprès des gens qui ont les projets les plus simples et les plus compliqués.

Si vous créez un seul WAR à partir d'une seule base de code, cela vous oblige à déplacer la structure de votre projet et à répertorier manuellement les deux des trois fichiers JAR dans le fichier POM.

Si vous construisez un EAR à partir d'un ensemble de neuf prototypes de fichiers EAR avec une combinaison de cinq fichiers WAR, trois EJB et 17 autres outils, des fichiers JAR de dépendances et des configurations qui nécessitent de peaufiner les fichiers MANIFEST.MF et XML dans les ressources existantes lors de la construction finale; alors Maven est probablement trop restrictif. Un tel projet devient un gâchis de profils imbriqués compliqués, de fichiers de propriétés et d'une mauvaise utilisation des objectifs de construction Maven et de la désignation du classificateur.

Donc, si vous êtes dans les 10% inférieurs de la courbe de complexité, c'est exagéré. Au sommet de 10% de cette courbe, vous êtes dans une camisole de force.

La croissance de Maven est due au fait qu'elle fonctionne bien pour les 80% du milieu


16

Mon expérience fait écho à la frustration de nombreux messages publiés ici. Le problème avec Maven est qu'il enveloppe et cache les détails de la gestion de build dans sa quête de la bonté automagique ultime. Cela vous rend presque impuissant s'il se brise.

Mon expérience est que tout problème avec maven a rapidement dégénéré en une chasse au snipe de plusieurs heures à travers des toiles de fichiers xml imbriqués, dans une expérience similaire à celle du canal radiculaire.

J'ai aussi travaillé dans des magasins qui comptaient beaucoup sur Maven, les gens qui l'ont aimé (qui l'aimaient pour l'aspect "appuyez sur un bouton, faites tout faire") ne l'ont pas compris. Les builds maven avaient un million de cibles automatiques, ce qui, j'en suis sûr, serait utile si j'avais envie de prendre des heures pour lire ce qu'ils ont fait. Mieux 2 cibles qui fonctionnent que vous comprenez parfaitement.

mise en garde: la dernière fois que j'ai travaillé avec Maven il y a 2 ans, ça va peut-être mieux maintenant.


14

Comme Glenn, je ne pense pas que Maven ait une mauvaise réputation, mais une représentation mitigée. Je travaille depuis 6 mois exclusivement en essayant de migrer un projet assez gros vers Maven et cela montre clairement les limites de l'outil.

D'après mon expérience, Maven est bon pour:

  • gestion des dépendances externes
  • gestion centralisée de la construction (héritage pom)
  • beaucoup de plugins pour plein de choses
  • très bonne intégration avec les outils d'intégration continue
  • très bonnes capacités de reporting (FindBugs, PMD, Checkstyle, Javadoc, ...)

Et il a quelques problèmes avec:

  • approche tout ou rien (difficile de migrer lentement vers Maven)
  • dépendances complexes, dépendances intermodules
  • dépendances cycliques (je sais, mauvaise conception, mais on ne peut pas réparer 5 ans de développement ...)
  • cohérence (les gammes de versions ne fonctionnent pas de la même manière partout)
  • bogues (encore une fois avec les gammes de versions)
  • builds reproductibles (à moins que vous ne corrigiez le numéro de version de tous les plugins, vous ne pouvez pas être sûr que vous obtiendrez la même build dans 6 mois)
  • manque de documentation (la documentation est assez bonne pour les bases, mais il n'y a pas beaucoup d'exemples sur la façon de gérer de grands projets)

Pour donner un peu de contexte, une trentaine de développeurs travaillent sur ce projet, et le projet existe depuis plus de 5 ans, donc: beaucoup d'héritage, beaucoup de processus déjà en place, beaucoup d'outils propriétaires personnalisés déjà en place. Nous avons décidé d'essayer de migrer vers Maven car le coût de maintenance de nos outils propriétaires devenait trop élevé.


12

Je voudrais contrer quelques-unes des plaintes formulées dans ce forum:

Maven est tout ou rien. Ou du moins pour autant que je puisse dire d'après la documentation. Vous ne pouvez pas facilement utiliser maven en remplacement de la fourmi et adopter progressivement des fonctionnalités plus avancées.

Ce n'est pas vrai. La grande victoire de Maven est de l'utiliser pour gérer vos dépendances de manière rationnelle et si vous voulez faire cela dans maven et faire tout le reste dans ant, vous pouvez. Voici comment:

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

Vous avez maintenant un objet classpath nommé «maven.classpath» qui contient toutes les dépendances maven définies dans le fichier pom. Tout ce dont vous avez besoin est de mettre le fichier jar des tâches maven ant dans le répertoire lib de votre fourmi.

Maven rend votre processus de construction dépendant de votre connexion réseau.

Le processus de récupération des dépendances et des plugins par défaut dépend d'une connexion réseau, oui, mais uniquement pour la construction initiale (ou si vous modifiez les dépendances ou les plugins utilisés). Après cela, tous les fichiers JAR sont mis en cache localement. Et si vous voulez forcer la connexion sans réseau, vous pouvez dire à maven d'utiliser le mode hors ligne.

Il vous impose une structure rigide dès le départ.

Ce n'est pas clair si cela fait référence au format de fichier ou au problème de la «convention contre la configuration». Pour ce dernier, il y a beaucoup de valeurs par défaut invisibles comme l'emplacement attendu des fichiers source java et des ressources, ou la compatibilité de la source. Mais ce n'est pas de la rigidité, il s'agit de mettre des valeurs par défaut raisonnables pour vous afin que vous n'ayez pas à les définir explicitement. Tous les paramètres peuvent être remplacés assez facilement (bien que pour un débutant, il puisse être difficile de trouver dans la documentation comment changer certaines choses).

Si vous parlez du format de fichier, eh bien c'est couvert dans la réponse à la partie suivante ...

Il est basé sur XML, il est donc aussi difficile à lire que l'était ANT.

Tout d'abord, je ne vois pas comment vous pouvez vous plaindre du fait qu'un aspect de quelque chose «N'est pas meilleur que la fourmi» pour justifier une mauvaise réputation. Deuxièmement, bien qu'il soit toujours XML, le format du XML est beaucoup plus défini. De plus, comme il est ainsi défini, il est beaucoup plus facile de créer un éditeur de client lourd sensible pour un POM. J'ai vu des pages longues et créer des scripts qui sautent partout. Aucun éditeur de script de construction de fourmis ne rendra cela plus acceptable, juste une autre longue liste de tâches interconnectées présentées d'une manière légèrement différente.

Cela dit, il y a quelques plaintes que j'ai vues ici qui ont ou avaient une certaine validité, la plus grande étant

  • La documentation est pauvre / manquante
  • Constructions reproductibles
  • L'intégration d'Eclipse est mauvaise
  • Bugs

A quoi ma réponse est double. Premièrement, Maven est un outil beaucoup plus récent que Ant ou Make, vous devez donc vous attendre à ce que cela prenne du temps pour atteindre le niveau de maturité de ces applications. Deuxièmement, si vous ne l'aimez pas, corrigez-le . C'est un projet open source et l'utiliser, puis se plaindre de quelque chose que tout le monde peut aider à résoudre me semble assez absurde. Vous n'aimez pas la documentation? Contribuez-y pour le rendre plus clair, plus complet ou plus accessible à un débutant.

Le problème des builds reproductibles se décompose en deux problèmes, les gammes de versions et les mises à jour automatiques du plugin maven. Pour les mises à jour du plugin, à moins que vous ne vous assuriez, lorsque vous reconstruisez un projet un an plus tard, que vous utilisez exactement le même JDK et exactement la même version d'Ant, bien c'est juste le même problème avec un nom différent. Pour les gammes de versions, je recommande de travailler sur un plugin qui produira un pom temporaire avec des versions verrouillées pour toutes les dépendances directes et transitives et l'intègrera au cycle de vie de la version maven. De cette façon, vos poms de build de version sont toujours des descriptions exactes de toutes les dépendances.


11

Il mérite la réputation qu'il a. Tout le monde n'a pas besoin de la structure rigide que les développeurs de Maven pensaient appropriée pour chaque projet. C'est tellement inflexible. Et ce qui est «Pro» pour beaucoup de gens, la gestion des dépendances, est à mon humble avis son plus gros «con». Je ne suis absolument pas à l'aise avec le fait que maven télécharge les fichiers jar depuis le réseau et je perds mon sommeil à cause d'incompatibilités (oui, le mode hors ligne existe, mais alors pourquoi devrais-je avoir toutes ces centaines de fichiers xml et de sommes de contrôle). Je décide quelles bibliothèques j'utilise et de nombreux projets sont sérieusement préoccupés par les versions dépendant de la connexion réseau.

Pire encore, lorsque les choses ne fonctionnent pas, vous êtes absolument perdu. La documentation est nulle, la communauté n'a aucune idée.


4
Je suis d'accord avec ça. Je pense que la valeur de la gestion des dépendances est surestimée. Bien sûr, c'est bien quand tout fonctionne, mais cela introduit plusieurs points de défaillance potentiels (sans parler des failles de sécurité potentielles). Vous pouvez configurer votre propre serveur de référentiel pour atténuer quelque peu les problèmes et verrouiller les numéros de version pour éviter les mises à jour inattendues, mais je préfère toujours ajouter simplement les dépendances au contrôle de version car elles ne changent pas souvent et cela garantit une construction répétable .
Dan Dyer

8

Un an plus tard, je voulais mettre à jour ceci: je n'ai plus cet avis sur la communauté Maven. Je n'écrirais pas cette réponse si la question était posée aujourd'hui. Je vais ajouter mon opinion actuelle en tant que réponse distincte.


C'est une réponse très subjective, mais la question porte sur les opinions, donc ...

J'aime Maven et je l'aime mieux à mesure que je le connais. Une chose qui affecte mes sentiments à ce sujet, cependant: la communauté maven est largement centrée autour de Sonatype ("la société maven", c'est là que beaucoup de honchos Maven travaillent), et Sonatype pousse ses produits d'entreprise de manière assez agressive sur la communauté.

Un exemple: le flux Twitter «Maven Book» renvoie à une prétendue introduction à la gestion des référentiels .

Désolé, mais cette "intro" est mi-information, mi-argument de vente pour Nexus. Quiz Pop: y a-t-il d' autres gestionnaires de repo en plus de Nexus et Nexus Pro? De plus, qu'est-ce que cela a à voir avec le soi-disant livre Maven open-source? Oh, c'est vrai, le chapitre sur la gestion des référentiels a été transformé en un livre séparé ... sur Nexus. Huh. Si je contribue au livre Maven, est-ce que je reçois des frais de parrainage si je provoque une augmentation des ventes Nexus?

Imaginez si vous participiez à un forum de développement Java et qu'il était clair que les employés de Sun discutant de Java allaient saisir toutes les occasions possibles pour parler de NetBeans et de "NetBeans Pro". Après un certain temps, il perd un peu de son sentiment communautaire. Je n'ai jamais eu une expérience pareille avec Ant.

Cela dit, je pense que Maven est un système très intéressant et utile (je ne l'appelle pas un outil, comme Ant est, Maven est plus large que cela) pour la configuration du développement logiciel et la gestion des builds. La gestion des dépendances est parfois une bénédiction et une malédiction, mais elle est rafraîchissante - et certainement pas le seul avantage offert par Maven. Je réagis probablement un peu trop fortement au shilling Sonatype, mais ça fait mal à Maven par association, à mon avis. Je ne sais pas si cette opinion est partagée par quelqu'un d'autre.


2
Zac, tu sais que je me demandais si tu voulais en savoir plus sur Nexus Professional. :-)
Tim O'Brien

7

Je pense que Maven a mauvaise réputation car il impose une structure à votre projet, alors que d'autres outils comme Ant vous permettent de définir complètement la structure comme vous le souhaitez. Je suis également d'accord pour dire que la documentation est mauvaise, mais je pense que la mauvaise réputation de Maven est principalement due au fait que les gens sont tellement habitués à Ant.


2
Je conviens qu'au départ, les gens peuvent manquer le contrôle qu'ils avaient avec Ant, mais une fois qu'un projet en vient à accepter les conventions que Maven impose, ils en verront vraiment un gain de productivité.
Taylor Leese

5
Ce n'est pas vrai, Maven vous permet de changer la structure du projet, il suggère simplement une structure largement utilisée.
adrian.tarau

3
Je ne pense pas que ce soit vrai. La plupart des plaintes concernant Maven portent sur la manière dont il peut échouer, sa lenteur ou la documentation. Je n'ai jamais vraiment remarqué quiconque se plaignait de la structure.
Dan Dyer

@Dan Dyer: J'approuve cela. La structure est en fait l'une des rares bonnes choses que Maven fait. C'est tout le reste qui rend Maven si horrible.
Carl Smotricz

6

Trop de magie.


3
Soyez plus précis - qu'est-ce qui est si magique à ce sujet qui n'est pas documenté?
whaley

4
C'est magique dès que vous devez effectuer une recherche sur le Web pendant 2 heures pour savoir pourquoi quelque chose ne fonctionne pas comme prévu. Si vous voulez un exemple spécifique: pourquoi mon plugin n'est-il pas exécuté? Vous avez 2 heures.
Damien B

En fait, chaque fois que je fais quelque chose qui n'implique pas de rechercher sur le Web pendant 2 heures, je commence à me méfier du fait que j'utilise le mauvais outil pour le travail ou j'ai gravement mal compris / sous-estimé les exigences.
Doug Moscrop

6

Parce que les gens insatisfaits se plaignent tandis que les gens satisfaits ne se disent pas satisfaits. Mon point est qu'il y a beaucoup plus d'utilisateurs de maven satisfaits que d'insatisfaits, mais ces derniers font plus de bruit. C'est un modèle courant de la vie réelle (FAI, opérateur de téléphonie, transports, etc.).


5

Le problème le plus important pour moi est que Maven, lorsqu'il n'est pas configuré correctement, peut ne pas produire de builds répétables, en raison de:

  • référentiels distants peu fiables;
  • dépendances sur les plugins et les bibliothèques avec soit des versions SNAPSHOT, soit aucune version.

Comparez cela avec une construction de fourmi qui - bien que verbeuse et ennuyeuse IMO - fonctionne puisque tous les pots sont enregistrés localement.

L'avantage est que les problèmes sont résolus:

  • utilisez votre propre référentiel maven, qui est devenu très simple, j'utilise Archiva avec de bons résultats;
  • version toujours correctement vos dépendances. Maven a commencé à verrouiller les versions de plug-in dans le super-POM à partir de 2.0.8 ou 2.0.9 et toutes vos dépendances devraient être sur les versions publiées.

+1 pour créer un lien vers une autre implémentation de référentiel.
Donal Fellows

5

excellente idée - mauvaise mise en œuvre.

J'ai récemment déménagé un projet de Ant à Maven. Cela a bien fonctionné à la fin, mais j'ai dû utiliser deux versions différentes de maven-assembly-plugin et maven-jar-plugin dans le même pom (obtenu deux profils) car ce qui fonctionnait dans une version était cassé dans une autre.

C'était donc un véritable casse-tête. La documentation n'est pas toujours excellente, mais je dois admettre qu'il était relativement facile de trouver des réponses sur Google.

assurez-vous de toujours spécifier les versions des plugins que vous utilisez. Ne vous attendez pas à ce que la nouvelle version soit rétrocompatible.

Je pense que la controverse vient du fait que maven évolue encore et que le processus est parfois douloureux.

Cordialement

v.


Je reconnais que l'idée vaut mieux que l'exécution. Ce n'est pas une petite tâche qu'ils ont choisie pour leur défense, mais je me demande régulièrement si les choses n'auraient pas pu être faites de manière plus simple.
Eelco

5

J'aime maven. Je l'ai utilisé depuis la version antérieure à 1.0. C'est un outil puissant qui, dans l'ensemble, m'a fait gagner un temps considérable et amélioré mon infrastructure de développement. Mais je peux comprendre la frustration de certaines personnes. Je vois 3 types de frustration:

  1. où les causes sont de réelles préoccupations (par exemple POM verbeux, manque de documentation),
  2. une partie est de la désinformation (par exemple "vous devez avoir une connexion Internet pour construire" - pas vrai - non, cela peut être évité),
  3. une partie est évacuée sur maven mais en réalité quelqu'un d'autre est coupable ("ne tirez pas sur le messager").

Pour le premier cas, de vrais problèmes - eh bien, bien sûr, il y a des problèmes, les POM sont verbeux, la documentation pourrait être meilleure. Pourtant, malgré cela, il est possible d'obtenir de bons résultats avec maven en un rien de temps. Je grince des dents chaque fois que je reçois un projet construit avec fourmi, et j'essaye de l'importer dans mon IDE. La configuration de la structure des répertoires peut prendre un certain temps. avec maven, il s'agit simplement d'ouvrir le fichier POM dans l'IDE.

Pour le second cas, Maven est complexe et les malentendus sont monnaie courante. Si maven 3 peut trouver un moyen de traiter cette complexité (ou même la complexité perçue), ce serait bien. maven demande un investissement considérable, mais, d'après mon expérience, l'investissement se rentabilise rapidement.

Pour le dernier point, je pense que le reproche concernant les dépendances transitives de maven est probablement l'exemple le plus connu.

Les dépendances transitives sont la nature des logiciels réels utilisant la réutilisation. Les DLL Windows, les packages Debian, les packages java, les bundles OSGi, même les fichiers d'en-tête C ++ incluent tous des dépendances et souffrent du problème de dépendance. Si vous avez deux dépendances et que chacune utilise une version différente de la même chose, vous devez essayer de résoudre cela d'une manière ou d'une autre. Maven n'essaie pas de résoudre le problème de dépendance, mais le met plutôt au premier plan et fournit des outils pour aider à gérer le problème, par exemple en signalant les conflits et en fournissant des dépendances cohérentes pour une hiérarchie de projets, et en fait, fournit un contrôle absolu sur les dépendances d'un projet.

L'approche consistant à inclure manuellement les dépendances avec chaque projet (un poster dit qu'il vérifie toutes les dépendances dans le contrôle de code source) court le risque d'utiliser la mauvaise dépendance, comme des mises à jour négligées lorsqu'une bibliothèque est mise à jour sans vérifier les mises à jour pour ses dépendances. Pour un projet de toute taille, la gestion manuelle des dépendances va sûrement entraîner des erreurs. Avec maven, vous pouvez mettre à jour la version de la bibliothèque que vous utilisez et les dépendances correctes sont incluses. Pour la gestion des changements, vous pouvez comparer l'ancien ensemble de dépendances (pour votre projet dans son ensemble) avec le nouvel ensemble, et tout changement peut être soigneusement examiné, testé, etc.

Maven n'est pas la cause du problème de dépendance, mais le rend plus visible. En abordant les problèmes de dépendance, maven rend toute dépendance explicite (une modification de votre POM remplaçant la dépendance), plutôt qu'implicite, comme c'est le cas avec les fichiers JAR gérés manuellement dans le contrôle de version, où les fichiers JAR sont simplement présents, sans rien à support météo ils sont la dépendance correcte ou non.


5

Je pense que Maven a une mauvaise réputation car la plupart des détracteurs n'ont pas observé la combinaison Maven + Hudson + Sonar . S'ils l'avaient fait, ils demanderaient «comment puis-je commencer»?


+1 pour mentionner Sonar.
Donal Fellows

1
Je l'ai vu. Il n'y a toujours aucune raison d'utiliser Maven. Hudson et Sonar n'ont pas besoin de maven.
rk2010

5

Certains de mes bêtes noires avec Maven:

  • La définition XML est super maladroite et verbeuse. N'ont-ils jamais entendu parler des attributs?

  • Dans sa configuration par défaut, il parcourt toujours le filet à chaque opération. Indépendamment du fait que cela soit utile pour quoi que ce soit, il semble extrêmement ridicule d'avoir besoin d'un accès Internet pour «nettoyer».

  • Encore une fois par défaut, si je ne fais pas attention à spécifier les numéros de version exacts, il retirera les toutes dernières mises à jour du net, que ces dernières versions introduisent ou non des erreurs de dépendance. En d'autres termes, vous êtes mis à la merci de la gestion de la dépendance des autres.

  • La solution à tout cet accès réseau est de le désactiver en ajoutant l' -ooption. Mais vous devez vous rappeler de le désactiver si vous voulez vraiment mettre à jour les dépendances!

  • Une autre solution consiste à installer votre propre serveur de «contrôle de source» pour les dépendances. Surprise: la plupart des projets ont déjà un contrôle de source, mais cela fonctionne sans configuration supplémentaire!

  • Les builds Maven sont incroyablement lents. Le fait de jouer avec les mises à jour réseau atténue cela, mais les versions de Maven sont encore lentes. Et horriblement bavard.

  • Le plugin Maven (M2Eclipse) s'intègre le plus mal avec Eclipse. Eclipse s'intègre raisonnablement facilement avec le logiciel de contrôle de version et avec Ant. L'intégration Maven est très maladroite et laide en comparaison. Ai-je mentionné lent?

  • Maven continue de boguer. Les messages d'erreur sont inutiles. Trop de développeurs en souffrent.


2
Je n'ai jamais eu Maven retirer la dernière d'une dépendance à moins que j'utilise une dépendance SNAPSHOT ou que j'aie ajouté une nouvelle fonctionnalité nécessitant quelque chose. Si je demande la version 1.2.3 et que j'ai 1.2.3 dans mon référentiel local, je n'obtiens plus la 1.2.3.
Mike Cornell

1
Vous contrôlez vos dépendances directes, oui. Qui contrôle les dépendances de vos dépendances?
Carl Smotricz

Pour votre premier point, à propos des attributs, qui est censé être abordé dans le prochain, (pendant un temps LONGTEMPS maintenant je l'admets) Maven 3.
mezmo

@mezmo: Ce serait très bienvenu. Merci pour l'info!
Carl Smotricz

4

Bonne question. Je viens de démarrer un grand projet au travail et une partie des projets précédents consistait à introduire la modularité dans notre base de code.

J'ai entendu de mauvaises choses sur maven. En fait, c'est tout ce que j'en ai jamais entendu. J'ai cherché à l'introduire pour résoudre le cauchemar de dépendance que nous vivons actuellement. Le problème que j'ai vu avec Maven est qu'il est assez rigide dans sa structure, c'est-à-dire que vous devez vous conformer à la disposition de son projet pour qu'il fonctionne pour vous.

Je sais ce que la plupart des gens diront - vous n'avez pas à vous conformer à la structure. En effet, c'est vrai, mais vous ne le saurez pas tant que vous n'aurez pas dépassé la courbe d'apprentissage initiale, à partir de laquelle vous avez investi trop de temps pour tout jeter.

La fourmi est beaucoup utilisée ces jours-ci, et j'adore ça. En tenant compte de cela, je suis tombé sur un gestionnaire de dépendances peu connu appelé Apache Ivy . Ivy s'intègre très bien dans Ant et il est rapide et facile d'obtenir la configuration et le fonctionnement de base de la récupération JAR. Un autre avantage d'Ivy est qu'il est très puissant mais tout à fait transparent; vous pouvez transférer des builds en utilisant des mécanismes tels que scp ou ssh assez facilement; Récupération de dépendances en chaîne sur des systèmes de fichiers ou des référentiels distants (la compatibilité des dépôts Maven est l'une de ses fonctionnalités populaires).

Cela dit, j'ai trouvé cela très frustrant à utiliser à la fin - la documentation est abondante, mais elle est écrite en mauvais anglais, ce qui peut ajouter à la frustration lors du débogage ou de la tentative de résolution de ce qui ne va pas.

Je vais revoir Apache Ivy à un moment donné au cours de ce projet et j'espère le faire fonctionner correctement. Il nous a permis en tant qu'équipe de déterminer de quelles bibliothèques nous dépendons et d'obtenir une liste documentée.

En fin de compte, je pense que tout dépend de la façon dont vous travaillez en tant qu'individu / équipe et de ce dont vous avez besoin pour résoudre vos problèmes de dépendance.

Les ressources suivantes relatives à Ivy peuvent vous être utiles:


1
Ivy n'est pas en concurrence avec Maven (peut-être avec Maven Ant Tasks, mais pas avec Maven).
Pascal Thivent

1
Ivy n'est pas en concurrence avec Maven Ant Tasks, il est en concurrence avec la gestion des dépendances Maven.
Damien B

@atc C'était juste !! : "Je sais ce que la plupart des gens diront - vous n'avez pas à vous conformer à la structure. En effet, c'est vrai, mais vous ne le saurez pas tant que vous n'aurez pas dépassé la courbe d'apprentissage initiale à laquelle vous avez investi trop de temps aller tout jeter. "
rk2010

4

J'adore Maven - cela augmente la productivité, et je suis très heureux de ne plus utiliser Ant (ouf!)

Mais si je pouvais changer les choses, ce serait:

  1. Rendre le pom.xmlfichier moins détaillé
  2. Facilitez l'inclusion de fichiers .jars non issus du référentiel.

1
Je pense que les utilisateurs de Maven seraient mieux servis en permettant aux IDE d'importer des fichiers JAR manquants ou tiers dans les référentiels locaux. À quel point serait-il difficile d’avoir une boîte de dialogue «Choisissez le fichier jar, cliquez sur l’importation»?
sal

@sal Je suppose que Maven ne veut pas promouvoir une pratique qui brise la portabilité.
Pascal Thivent

1
Je considère le fait qu'il est difficile d'ajouter des pots à partir d'endroits aléatoires comme une force. Si vous êtes dans un environnement d'équipe et que vous devez utiliser un fichier jar étrange, vous devriez déployer ce fichier dans le référentiel maven de votre équipe. De cette façon, le reste de l'équipe et vos serveurs CI effectueront la même compilation. Tout le monde exécute la même version est le fondement de la philosophie maven.
tunaranch

+1 pour le pot. Apporter vos propres pots pré-construits dans une construction (pour quelque raison que ce soit) est une douleur inutile.
Thorbjørn Ravn Andersen

@tunaranch Personnellement, j'aime que soit les éléments se trouvent dans Maven Central, soit ils soient (jars et tout) dans ce qui est extrait du contrôle de version. Fondamentalement, je veux être en mesure d'apporter mon dépôt git sur une clé USB, de le vérifier, d'exécuter "mvn clean install" et d'aller déjeuner et d'être opérationnel.
Thorbjørn Ravn Andersen

4

Il y a beaucoup de raisons pour lesquelles les gens n'aiment pas Maven, mais admettons-le, ils sont très subjectifs . Maven aujourd'hui avec de bons livres (et gratuits), une meilleure documentation, un ensemble plus complet de plugins et beaucoup de constructions de projets référentiels réussis n'est pas le même Maven qu'il y a un ou deux ans.

Utiliser Maven dans des projets simples est très facile, avec des projets plus grands / compliqués, il faut plus de connaissances et une compréhension plus profonde de la philosophie Maven - peut-être au niveau de l'entreprise un poste pour le gourou Maven comme administrateur de réseau. La principale source des déclarations de haine de Maven est souvent l' ignorance .

Un autre inconvénient pour Maven est le manque de flexibilité comme par exemple dans Ant. Mais rappelez-vous que Maven a un ensemble de conventions - s'y tenir semble être difficile au début, mais en fin de compte souvent épargner des problèmes.

Le succès actuel de Maven prouve sa valeur. Bien sûr, personne n'est parfait et Maven a quelques inconvénients et ses bizarreries, mais à mon avis, Maven balance lentement ses adversaires.


@Pascal. En cas de problèmes avec Maven, il y a un stackoverflow et vous ici :)
cetnar

3

Je ne dirais pas qu'il a une mauvaise réputation tant qu'il a un représentant mixte. Si votre projet suit le paradigme de la «convention sur la configuration» préconisé par Maven, vous pouvez en tirer beaucoup de profit. Si votre projet ne correspond pas bien à la vision du monde de Maven, il peut devenir un fardeau.

À cette fin, si vous avez le contrôle sur le projet, Maven peut être la voie à suivre. Mais si vous ne le faites pas et que la mise en page est déterminée par quelqu'un qui n'est pas fan de Maven, cela peut poser plus de problèmes que cela ne vaut la peine. Les projets Maven les plus heureux sont probablement ceux qui ont commencé comme des projets Maven.


«Je ne dirais pas qu'il a une mauvaise réputation tant qu'il a un représentant mixte» - je dirais que c'est probablement plus précis, seules les opinions négatives ont tendance à ressortir davantage.
Dan

Je suis d'accord que le portage d'un projet vers maven augmente la difficulté expérimentalement par rapport à la taille du projet (plus gros projet à importer = importation plus difficile). utiliser maven pour démarrer un projet est la meilleure approche pour utiliser maven. Sinon, cela ne vaut peut-être pas la peine.
Luigimax

3

Pour moi, il y a autant d'avantages que d'inconvénients à utiliser maven vs ant pour des projets internes. Pour les projets open source cependant, je pense que Maven a eu un grand impact en rendant de nombreux projets beaucoup plus faciles à construire. Il n'y a pas si longtemps, il fallait des heures pour compiler le projet OSS Java (basé sur une fourmi) moyen, devoir définir une tonne de variables, télécharger des projets dépendants, etc.

Vous pouvez faire tout ce que vous pouvez faire avec Maven avec Ant, mais là où Ant n'encourage aucune norme, Maven vous suggère fortement de suivre sa structure, sinon ce sera plus de travail. Certes, certaines choses sont difficiles à mettre en place avec Maven, ce qui serait facile à faire avec Ant, mais le résultat final est presque toujours quelque chose de plus facile à construire du point de vue des personnes qui veulent simplement vérifier un projet et partir.


3

Si vous comptez parier votre entreprise ou votre travail sur un projet de développement, vous voulez être en contrôle des fondations - c'est-à-dire du système de construction. Avec Maven, vous n'avez pas le contrôle. Il est déclaratif et opaque. Les développeurs de maven-framework n'ont aucune idée de la façon de créer un système transparent ou intuitif et cela ressort clairement de la sortie du journal et de la documentation.

La gestion des dépendances est très tentante car elle pourrait vous même un certain temps au démarrage du projet mais attention, elle est fondamentalement cassée et vous causera éventuellement beaucoup de maux de tête. Lorsque deux dépendances ont des dépendances transitoires incompatibles, vous serez bloqué par un nid de complexité qui interrompra la construction de toute votre équipe et bloquera le développement pendant des jours. Le processus de construction avec Maven est également notoirement incohérent pour les différents développeurs de votre équipe en raison des états incohérents de leurs référentiels locaux. Selon le moment où un développeur a créé son environnement ou les autres projets sur lesquels il travaille, les résultats seront différents. Vous constaterez que vous supprimez l'intégralité de votre référentiel local et que Maven télécharge à nouveau les fichiers JAR beaucoup plus souvent que lors de la première configuration pour une branche de développement. Je pense que l'OSGI est une initiative qui tente de résoudre ce problème fondamental. Je dirais que si quelque chose doit être si complexe, la prémisse fondamentale est erronée.

Je suis un utilisateur / victime maven depuis plus de 5 ans maintenant et je dois dire que cela vous fera gagner beaucoup plus de temps pour simplement vérifier vos dépendances dans votre référentiel source et écrire des tâches de fourmis simples et agréables. Avec fourmi, vous savez exactement ce que fait votre système de construction.

J'ai vécu de nombreuses semaines d'homme perdues dans plusieurs entreprises différentes en raison de problèmes de Maven.

J'ai récemment essayé de redonner vie à un ancien projet GWT / Maven / Eclipse et 2 semaines de tout mon temps libre plus tard, je n'arrive toujours pas à le construire de manière cohérente. Il est temps de réduire mes pertes et de me développer en utilisant fourmi / éclipse me pense ...


3

La réponse courte: j'ai trouvé très difficile de maintenir un système de construction Maven, et j'aimerais passer à Gradle dès que possible.

Je travaille avec Maven depuis plus de quatre ans. Je me qualifierais d'expert en systèmes de construction parce que dans les cinq dernières (au moins) dernières entreprises dans lesquelles j'ai été, j'ai effectué des rénovations majeures sur l'infrastructure de construction / déploiement.

Certaines des leçons que j'ai apprises:

  • La plupart des développeurs ont tendance à ne pas passer beaucoup de temps à réfléchir aux systèmes de construction; en conséquence, la construction se transforme en un gâchis spaghetti de hacks, mais ils apprécient quand ce gâchis est nettoyé et rationalisé.
  • Pour gérer la complexité, je préférerais avoir un système transparent qui expose la complexité (comme Ant) plutôt qu'un système qui essaie de simplifier les choses complexes en imposant des restrictions rigides, comme Maven. Pensez à Linux par rapport à Windows.
  • Maven a beaucoup de lacunes dans les fonctionnalités qui nécessitent des solutions de contournement byzantines. Cela conduit à des fichiers POM qui sont incompréhensibles et non maintenables.
  • Ant est super flexible et compréhensible, mais les fichiers Ant peuvent aussi devenir assez gros, car ils sont de si bas niveau.
  • Pour tout projet important, les développeurs doivent créer leur propre structure de construction / déploiement au-delà de ce que l'outil fournit; l'adéquation de la structure au projet a beaucoup à voir avec sa facilité d'entretien. Les meilleurs outils vous aideront à créer une structure et non à vous combattre.

J'ai regardé un peu Gradle et il semble qu'il a le potentiel d'être le meilleur des deux mondes, permettant un mélange de description de construction déclarative et procédurale.


3

C'est plus compliqué que la langue que vous avez utilisée pour écrire votre projet. Le configurer correctement est plus difficile que la programmation réelle.


3

J'ai eu du mal à traverser la plupart / tous les négatifs mentionnés ici, et les objections similaires des coéquipiers, et je suis d'accord avec eux tous. Mais j'ai tenu bon et je continuerai de le faire en me tenant fermement au seul objectif que seul maven (ou gradle peut-être) réalise vraiment.

Si vous optimisez pour des pairs ( développeurs open source ), ant / make / what will do. Si vous fournissez des fonctionnalités à des non-pairs ( utilisateurs ), seul maven / gradle / etc fera l'affaire.

Seul maven vous permet de publier un petit paquet de code source + poms (pas de fichiers de dépendances lib / binaires intégrés avec des noms cryptiques et aucune information de dépendance) avec une mise en page de projet standard bien documentée qui peut être chargée par n'importe quel IDE par quelqu'un qui n'a pas absorbé les conventions de mise en page idiosyncratiques des développeurs. Et il existe une procédure d'installation à un bouton (mvn install) qui construit tout tout en acquérant les dépendances manquantes.

Le résultat est une rampe d'accès facile que les utilisateurs peuvent suivre pour trouver leur chemin dans le code, où les poms peuvent les diriger vers la documentation pertinente.

En dehors de cette exigence (indispensable), je n'aime pas maven autant que quiconque.

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.