Pourquoi Maven a-t-il une si mauvaise réputation?
On parle beaucoup sur Internet de la façon dont Maven est mauvais. J'utilise certaines fonctionnalités de Maven depuis quelques années et l'avantage le plus important à mes yeux est la gestion de la dépendance.
La documentation Maven est moins qu'adéquate, mais généralement lorsque je dois accomplir quelque chose, je la découvre une fois, puis tout fonctionne (par exemple lorsque j'ai implémenté la signature des bocaux). 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 espérer à l'avenir? Peut-être y a-t-il 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 pour effacer le FUD.
J'ai examiné Maven il y a environ six mois. Nous commençions un nouveau projet et n'avions aucun héritage à soutenir. Cela dit:
- Maven est tout ou rien. Ou du moins autant que je pourrais dire de la documentation. Vous ne pouvez pas facilement utiliser maven en remplacement immédiat 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 éveillé.
- 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" avec la "tâche 'non valide" 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 " cela suggère que je lance mvn avec -e pour plus d'informations, ce qui signifie qu'il imprimera le même message, puis une trace de pile pour une exception BuildFailureException.
Une grande partie de mon aversion pour Maven peut s'expliquer par l'extrait suivant de Better Builds with Maven:
Lorsque quelqu'un veut savoir ce qu'est Maven, il lui est généralement demandé "Qu'est-ce que Maven?" Et il s'attend à une réponse brève et réaliste. "Eh bien, c’est un outil de compilation ou un cadre de script" Maven contient plus de trois mots ennuyeux et sans intérêt. C'est une combinaison d'idées, de standards et de logiciels, et il est impossible de résumer la définition de Maven simplement en digérant des extraits sonores. Les idées révolutionnaires sont souvent difficiles à exprimer avec des mots.
Ma suggestion: si vous ne pouvez pas exprimer 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.
- Il vous impose dès le départ une structure rigide.
- Il est basé sur XML et est donc aussi difficile à lire qu'ANT.
- Son rapport d'erreur est obscur et vous laisse coincé lorsque les choses tournent mal.
- La documentation est pauvre.
- Cela rend les choses difficiles faciles et les choses simples difficiles.
- Maintenir un environnement de construction Maven prend trop de temps, ce qui rend tout système de construction totalement obsolète.
- 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 insectes existent et dans des endroits surprenants.
- Cela promet beaucoup, mais vous trahit comme un amant beau et séduisant mais émotionnellement froid et manipulateur.
J'ai certainement garce et gémit à propos de Maven dans le passé. Mais maintenant, je ne serais pas sans elle. Je pense que les avantages dépassent de loin tous 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 structure du projet et sait comment le construire et le conditionner.
- Lorsque vous dites que c'est un projet Ant, le développeur devra attendre que vous en expliquiez plus ou devra passer par le fichier build.xml pour comprendre.
- Bien sûr, il est toujours possible d'imposer des normes à l'échelle de l'entreprise avec Ant, mais je pense que le plus souvent, vous réinventerez la roue proverbiale.
- Étant donné qu'un nouveau développeur rejoint un projet:
- Gestion de la dépendance.
- Non seulement avec les bibliothèques externes, mais aussi avec les bibliothèques/modules internes. Veillez à utiliser un serveur proxy de référentiel Maven tel que Nexus ou Artifactory .
- Il est possible de faire cela avec Ivy . En fait, si tout ce dont vous avez besoin est d’une gestion des dépendances, vous feriez probablement mieux d’utiliser Ivy.
- Particulièrement dans un projet. J'ai trouvé très utile de créer de petits sous-projets et Maven s'en occupe bien. C'est beaucoup plus difficile avec ant.
- Gestion normalisée des artefacts (en particulier en liaison avec lien ou artificiel )
- Le release-plugin est merveilleux.
- L'intégration Eclipse & NetBeans est plutôt bonne.
- L'intégration avec hudson est superbe. En particulier les graphiques de tendance pour des choses comme findbugs.
- C'est un point mineur, mais le fait que maven incorpore des détails comme le numéro de version à l'intérieur du fichier jar ou war (pas seulement dans le nom du fichier) par défaut est extrêmement considérable. utile.
Les inconvénients pour moi sont principalement:
- La ligne de commande est plutôt inutile. Cela m'a beaucoup retardé pour commencer.
- Le format XML est très détaillé. Je peux voir pourquoi cela a été fait de cette façon, mais ça reste pénible à lire.
- Cela dit, il possède un XSD pour une édition facile dans un IDE.
- Il est difficile d’avoir la tête au début. Des choses comme le cycle de vie, par exemple.
- Le guide définitif de maven est une bonne introduction cependant.
Je crois vraiment que cela vaut la peine de passer un peu de temps à apprendre à connaître Maven.
Mon expérience pratique de deux grands projets est que nous avons consacré de 1 000 à 1 500 heures à chaque projet sur des problèmes liés aux hommes, excluant un effort de 500 heures pour passer de Maven 1 à Maven 2.
Depuis lors, je dois dire que je déteste absolument maven. Je suis frustré quand j'y réfléchis.
L'intégration Eclipse est terrible. (Nous avons eu des problèmes sans fin avec la génération de code, par exemple, où Eclipse était synchronisé avec le code généré et nécessitait une reconstruction complète, très souvent. Le blâme est à la fois maven et Eclipse, mais Eclipse est plus utile que maven et dit emacs, alors Les séjours Eclipse et Maven doivent partir.)
Nous avions beaucoup de dépendances et, comme nous l'avons découvert, les erreurs de syntaxe sont en fait commises assez souvent dans des référentiels publics, ce qui peut gâcher des heures de votre temps précieux. Chaque semaine. La solution de rechange consiste à disposer d'un référentiel proxy ou régi localement, ce qui a également pris un certain temps.
La structure de projet Mavens n'est pas vraiment adaptée au développement avec Eclipse et le temps de construction d'Eclipse augmente.
Un effet du problème de génération de code et de synchronisation, nous avons dû reconstruire assez souvent, réduisant votre cycle code/compilation/test à un cycle sans fin compilation/websurf/sommeil/matrice/code, vous renvoyant aux années 90 et 40 minutes de compilation.
La seule excuse pour maven est la résolution de dépendance, mais j'aimerais le faire de temps en temps, pas dans chaque version.
En résumé, maven est aussi éloigné de KISS que possible). De plus, les avocats sont généralement le type de personne qui célèbre le jour de son anniversaire de naissance lorsque son âge est primordial. N'hésitez pas à me voter :-)
Maven est génial. La raison de sa réputation a à voir avec la courbe d'apprentissage raide, à mon avis. (que je suis enfin près de finir)
La documentation est un peu rude à parcourir, tout simplement parce qu'il y a beaucoup de texte et de nouvelles choses à comprendre avant que cela ne commence à avoir un sens. Je dis que le temps est tout ce qui est nécessaire pour que Maven soit plus largement salué.
Parce que Maven est un moyen de réduire les hommes adultes à pleurer des masses de terreur absolue.
Avantages:
- Gestion des dépendances. Depuis plusieurs années déjà, mes collègues et moi ne téléchargeons ni ne gérons 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, prendre en charge les configurations simultanées IDE et en ligne de commande est simple, ce qui est bon pour l’intégration continue.
Les inconvénients:
- Devoir investir dans l'apprentissage de Maven. Eh bien, faut le faire. Bonne nouvelle, tous les membres de l'équipe ne doivent pas apprendre.
- Documentation. Autrefois un problème, maintenant grâce à Sonatype et à son 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 obliger Maven à faire les choses qu'il fait le mieux, des constructions simples, ou lorsqu'il existe un mojo stable. Dans d'autres cas, nous abandonnons et faisons des tâches 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 ).
Concurrence:
- Ant: n'a pas de gestion de dépendance. Période.
- Ivy: toujours moins mature que Maven (pas que ce dernier n'ait pas ses bizarreries, aussi). Presque le même ensemble de fonctionnalités, donc aucune raison impérieuse de se déplacer. J'ai essayé plusieurs fois de l'essayer. tous ont échoué.
En résumé: tous nos projets sont réalisés avec Maven depuis plusieurs années déjà.
Je pense qu’il a mauvaise réputation auprès des personnes qui ont les projets les plus simples et les plus compliqués.
Si vous construisez un seul fichier WAR à partir d'une seule base de code, vous devez déplacer la structure de votre projet et répertorier manuellement les deux fichiers JAR dans le fichier POM.
Si vous construisez un fichier EAR à partir d'un ensemble de neuf prototypes de fichiers EAR avec une combinaison de cinq fichiers WAR, trois EJB et 17 autres outils, fichiers de dépendance et configurations nécessitant de peaufiner les fichiers MANIFEST.MF et XML dans les ressources existantes lors de la génération finale; alors Maven est probablement trop restrictif. Un tel projet devient un fouillis de profils imbriqués complexes, de fichiers de propriétés et d’utilisation abusive des objectifs de construction Maven et de la désignation de classificateur.
Donc, si vous êtes dans les 10% inférieurs de la courbe de complexité, sa surexploitation. Au sommet des 10% de cette courbe, vous êtes dans une camisole de force.
La croissance de Maven est due au bon fonctionnement des 80%
Mon expérience fait écho à la frustration de nombreux articles publiés ici. Le problème avec Maven est qu’il cache et cache les détails de la gestion de la construction dans sa quête de la bonté automagique ultime. Cela vous rend presque impuissant s'il se brise.
Mon expérience est que n'importe quel problème avec maven a rapidement dégénéré en une chasse au snipe de plusieurs heures sur des toiles de fichiers xml imbriqués, dans une expérience similaire à celle du traitement de canal.
J'ai également travaillé dans des magasins qui comptaient beaucoup sur Maven, ceux qui l'aimaient (qui l'aimaient pour l'aspect "Poussez un bouton, faites-le tout faire") ne le comprenaient pas. Les builds Maven avaient un million de cibles automatiques, ce qui, j'en suis sûr, serait utile si je voulais prendre le temps nécessaire pour lire ce qu'ils ont fait. Mieux 2 cibles qui fonctionnent que vous comprenez parfaitement.
mise en garde: la dernière collaboration avec Maven il y a 2 ans, il pourrait être mieux maintenant.
Comme Glenn, je ne pense pas que Maven ait une mauvaise réputation, mais une représentante mixte. Cela fait 6 mois que je travaille exclusivement en essayant de migrer un grand projet 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 beaucoup de choses
- très bonne intégration avec des 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 nous ne pouvons pas réparer 5 ans de développement ...)
- cohérence (les versions ne fonctionnent pas partout de la même manière)
- bugs (encore avec les plages de versions)
- des versions reproductibles (à moins que vous ne fixiez le numéro de version de tous les plugins, vous ne pouvez pas être sûr d'obtenir la même version 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 gros projets)
Pour mettre en contexte, une trentaine de développeurs travaillent sur ce projet, et ce projet existe depuis plus de 5 ans, donc: beaucoup d’héritage, de nombreux processus déjà en place, de nombreux 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é.
J'aimerais contrer quelques-unes des plaintes formulées dans ce forum:
Maven est tout ou rien. Ou du moins autant que je pourrais dire de la documentation. Vous ne pouvez pas facilement utiliser maven en remplacement immédiat de la fourmi et adopter progressivement des fonctionnalités plus avancées.
Ce n'est pas vrai La grande victoire de Maven consiste à l'utiliser pour gérer vos dépendances de manière rationnelle. Si vous voulez le faire dans Maven et tout faire autrement, vous pouvez le faire. 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 placer le fichier maven ant tasks dans le répertoire lib de votre fourmi.
Maven rend votre processus de construction dépendant de votre connexion réseau.
La dépendance par défaut et le processus d’extraction de plug-in dépendent d’une connexion réseau, oui, mais uniquement pour la construction initiale (ou si vous modifiez les dépendances ou les plug-ins utilisés). Après cela, tous les pots sont mis en cache localement. Et si vous voulez forcer une connexion sans réseau, vous pouvez dire à Maven d'utiliser le mode hors connexion.
Il vous impose dès le départ une structure rigide.
Ce n'est pas clair s'il s'agit du format de fichier ou du problème 'convention versus configuration'. Pour ces derniers, il y a beaucoup de valeurs par défaut invisibles comme l'emplacement attendu de Java) ou la compatibilité de la source. Mais ce n'est pas la rigidité, sa mise en valeurs par défaut pour vous afin que vous n'ayez pas à les définir explicitement.Tous les paramètres peuvent être remplacés assez facilement (même si pour un débutant, il peut être difficile de trouver dans la documentation comment changer certaines choses).
Si vous parlez du format de fichier, cela est couvert dans la réponse à la partie suivante ...
Il est basé sur XML et est donc aussi difficile à lire qu'ANT.
Tout d’abord, je ne vois pas comment vous pourriez vous plaindre que certains aspects de quelque chose "n’est pas meilleur que la fourmi" pour justifier sa mauvaise réputation. Deuxièmement, bien que XML reste, le format du XML est beaucoup plus défini. En outre, comme il est défini, il est beaucoup plus facile de créer un éditeur de client lourd sensible pour un POM. J'ai vu de longues pages créer des scripts qui sautent partout. Aucun éditeur de script de construction de fourmis ne rendra cela plus acceptable, mais une longue liste de tâches interconnectées présentées de manière légèrement différente.
Cela dit, il y a quelques plaintes que j'ai vues ici qui ont ou ont eu une certaine vailidity, la plus grande étant
- La documentation est mauvaise/manquante
- Constructions reproductibles
- L'intégration Eclipse est mauvaise
- Bogues
A quoi ma réponse est double. Premièrement, Maven est un outil beaucoup plus jeune 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 me plaindre de quelque chose que tout le monde peut aider à résoudre me semble assez asin. Vous n'aimez pas la documentation? Contribuez-le à le rendre plus clair, plus complet ou plus accessible pour un débutant.
Le problème des versions reproductibles se décompose en deux problèmes: les plages de versions et les mises à jour automatiques du plug-in maven. Pour les mises à jour de plug-in, à 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 Ant, il s'agit du 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 en fera une partie intégrante du cycle de vie de la version maven. De cette façon, vos versions générées sont toujours des descriptions exactes de toutes les dépendances.
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 ont jugée appropriée pour chaque projet. C'est tellement inflexible. Et ce qui est 'Pro' pour beaucoup de gens, la gestion de la dépendance, est à mon humble avis son plus gros 'con'. Je ne suis absolument pas à l'aise avec le téléchargement de fichiers java du réseau par maven et la perte de mon sommeil à cause d'incompatibilités (oui, le mode hors connexion existe, mais 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 ont de sérieuses inquiétudes quant aux générations dépendantes d'une connexion réseau.
Pire encore, lorsque les choses ne fonctionnent pas, vous êtes absolument perdu. La documentation est nulle, la communauté est désemparée.
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 séparée.
C'est une réponse très subjective, mais la question concerne les opinions, alors ...
J'aime Maven et je l’aime mieux plus je le connais. Une chose a toutefois affecté mes sentiments à ce sujet: la communauté Maven est largement centrée sur Sonatype ("la société Maven", où travaillent de nombreux honchos Maven), et Sonatype pousse ses produits d'entreprise de manière très agressive sur la communauté.
Un exemple: le flux Twitter "Livre" contient des liens vers une supposée introduction à la gestion de référentiel .
Désolé, mais cette "intro" est à moitié information, moitié argument de vente pour Nexus. Jeu-questionnaire: existe-t-il d'autres gestionnaires de dépôt en plus de Nexus et Nexus Pro? Aussi, qu'est-ce que cela a à voir avec le Maven Book prétendument open-source? Oh, c'est vrai, le chapitre sur la gestion des dépôts a été divisé 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 de Nexus?
Imaginez si vous participiez à un Java forum de développement) et que les employés de Sun qui discutaient Java allaient saisir toutes les occasions possibles pour parler de NetBeans et "NetBeans Pro". Après un moment, il perd un peu de son sentiment de communauté. Je n'ai jamais eu une telle expérience 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, Maven est plus large que cela) pour la configuration du développement logiciel et la gestion de la construction. La gestion des dépendances est parfois une bénédiction et une malédiction, mais c'est rafraîchissant - et ce n'est certainement pas le seul avantage offert par Maven. Je réagis probablement un peu trop fort au shilling Sonatype, mais à mon avis, Maven est blessé par association. Je ne sais pas si cette opinion est partagée par quelqu'un d'autre.
Je pense que Maven est pris au dépourvu parce qu’il impose une structure à votre projet, alors que d’autres outils tels que Ant vous permettent de définir complètement la structure comme vous le souhaitez. Convenu également que la documentation est mauvaise, mais je pense que le mauvais coup que Maven obtient est principalement dû au fait que les gens sont tellement habitués à Ant.
Parce que les personnes insatisfaites se plaignent alors que les personnes satisfaites ne se disent pas satisfaites. Mon point est qu'il y a beaucoup plus d'utilisateurs satisfaits que d'utilisateurs insatisfaits, mais ces derniers font plus de bruit. C’est un schéma courant dans la vie réelle (FAI, opérateur de téléphone, transports, etc.).
Trop de magie.
Quelques unes de mes bévues avec Maven:
La définition XML est super maladroite et prolixe. Ont-ils jamais entendu parler d'attributs?
Dans sa configuration par défaut, il scrute toujours le réseau à chaque opération. Que cela soit utile ou non, il est extrêmement ridicule de requérir un accès Internet "propre".
Encore une fois, par défaut, si je ne prends pas soin de spécifier les numéros de version exacts, les dernières mises à jour seront extraites du réseau, 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 le
-ooption. Mais vous devez vous rappeler de l’éteindre si vous voulez vraiment faire la mise à jour des 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, seul cela fonctionne sans configuration supplémentaire!
Les builds Maven sont incroyablement lents. La manipulation des mises à jour du réseau atténue ce problème, mais les constructions Maven sont encore lentes. Et horriblement prolixe.
Le plugin Maven (M2Eclipse) s’intègre le moins bien à Eclipse. Eclipse s'intègre de manière relativement fluide avec le logiciel de contrôle de version et avec Ant. L'intégration de Maven est très maladroite et moche en comparaison. Ai-je mentionné lent?
Maven continue d'être bogué. Les messages d'erreur sont inutiles. Trop de développeurs en souffrent.
J'aime Maven. Je l'utilise depuis la pré 1.0. C'est un outil puissant qui m'a permis de gagner un temps considérable et d'améliorer mon infrastructure de développement. Mais je peux comprendre la frustration de certaines personnes. Je vois 3 types de frustration:
- où les causes sont de véritables préoccupations (par exemple, des POM verbeux, un manque de documentation),
- certaines sont des informations erronées (par exemple, "vous devez disposer d'une connexion Internet pour construire" - pas vrai - ne peut pas, cela peut être évité),
- une partie est diffusée chez Maven mais quelqu'un d'autre est vraiment coupable ("ne tirez pas sur le messager").
Pour le premier cas, de vrais problèmes - bon, bien sûr, il y a des problèmes, les POM sont verbeux, la documentation pourrait être meilleure. Malgré cela, il est possible d’obtenir de bons résultats avec maven dans Quick Time. Je grince des dents chaque fois que je construis un projet avec ant et essaie de l'importer dans mon IDE. La mise en place de la structure de répertoires peut prendre beaucoup de temps. avec maven, il s’agit simplement d’ouvrir le fichier POM dans l’EDI.
Dans 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 nécessite un investissement considérable, mais selon mon expérience, cet investissement est rapidement rentabilisé.
Pour le dernier point, je pense que le reproche que suscitent 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. DLL Windows, paquets Debian, Java, ensembles 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 du même 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 vous 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 fournit en fait un contrôle absolu sur les dépendances d'un projet.
L'approche consistant à inclure manuellement des dépendances avec chaque projet (un poster dit qu'il vérifie toutes les dépendances dans le contrôle de source) court le risque d'utiliser une dépendance incorrecte, telle que des mises à jour ignorées lorsqu'une bibliothèque est mise à jour sans vérifier les mises à jour de ses dépendances. Pour un projet de toute taille, la gestion manuelle des dépendances va certainement entraîner des erreurs. Avec maven, vous pouvez mettre à jour la version de la bibliothèque que vous utilisez et les dépendances appropriées sont incluses. Pour la gestion des modifications, vous pouvez comparer l’ancien ensemble de dépendances (de votre projet dans son ensemble) avec le nouvel ensemble, et toute modification peut être examinée attentivement, testée, etc.
Maven n'est pas la cause du problème de dépendance, mais le rend plus visible. En s'attaquant aux problèmes de dépendance, maven rend explicites toute modification de dépendance (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. support météo, ils sont la dépendance correcte ou non.
Le problème le plus important pour moi est que, s’il n’est pas configuré correctement, Maven risque de ne pas générer de versions répétables, en raison de:
- référentiels distants non fiables;
- dépendances sur des plugins et des bibliothèques avec des versions SNAPSHOT ou sans version.
Cela contraste avec une construction de fourmi qui - bien que verbeuse et fastidieuse à l’OMI - fonctionne puisque tous les pots sont enregistrés localement.
La bonne partie est que les problèmes sont adressables:
- utilisez votre propre référentiel Maven, qui est devenu tout simple, j'utilise Archiva avec de bons résultats;
- toujours correctement la version de 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 des versions publiées.
bonne 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 je devais utiliser deux versions différentes de maven-Assembly-plugin et de maven-jar-plugin dans le même pom (obtenu deux profils), car ce qui fonctionnait dans une version était cassé dans un autre.
Donc c'était assez mal à la tête. La documentation n'est pas toujours excellente, mais je dois admettre qu'il était relativement facile de chercher des réponses dans Google.
assurez-vous de toujours spécifier les versions des plugings que vous utilisez. Ne vous attendez pas à ce que la nouvelle version soit compatible avec les versions antérieures.
Je pense que la controverse vient du fait que Maven évolue toujours et que le processus est parfois douloureux.
cordialement
v.
Il y a beaucoup de raisons pour lesquelles les gens n'aiment pas Maven, mais ils le sont très subjectif. Maven aujourd'hui avec quelques bons livres (gratuits), une meilleure documentation, un ensemble de plug-ins plus volumineux et de nombreuses constructions de projets à succès référentiels 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 volumineux/compliqués, il est nécessaire de mieux connaître et de mieux comprendre la philosophie Maven. Peut-être qu'au niveau de l'entreprise, un poste pour un gourou Maven comme administrateur réseau. La source principale des déclarations de haine Maven est souvent ignorance.
Un autre problème pour Maven est le manque de flexibilité, comme par exemple. dans Ant. Mais souvenez-vous que Maven a un ensemble de conventions - s'en tenir à cela semble être difficile au début, mais à la fin, souvent à éviter 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.
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:
- Faire
pom.xmlfichier moins détaillé - Facilitez l’inclusion des fichiers .jars non issus du référentiel.
Bonne question. Je viens de commencer 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 à propos de Maven. En fait, c'est tout ce dont j'ai entendu parler. J'ai envisagé de l'introduire pour résoudre le cauchemar de dépendance que nous vivons actuellement. Le problème que j’ai vu avec Maven, c’est que sa structure est assez rigide, c’est-à-dire que vous devez vous conformer à la structure de votre projet pour que cela fonctionne pour vous.
Je sais ce que la plupart des gens vont dire - vous n'êtes pas obligé de vous conformer à la structure. En effet, c'est vrai, mais vous ne le saurez pas avant d'avoir dépassé la courbe d'apprentissage initiale, après quoi vous aurez investi trop de temps pour tout gâcher.
La fourmi est beaucoup utilisée ces jours-ci et j'adore ça. En prenant cela en compte, je suis tombé sur un gestionnaire de dépendance peu connu appelé Apache Ivy . Ivy s'intègre très bien dans Ant et il est facile et rapide d’obtenir une configuration de base de la récupération des fichiers JAR. Un autre avantage de Ivy est qu’il est très puissant et pourtant très transparent; vous pouvez transférer des builds en utilisant des mécanismes tels que scp ou ssh assez facilement; récupération de dépendance 'en chaîne' sur des systèmes de fichiers ou des référentiels distants (la compatibilité Maven repo est l'une de ses fonctionnalités les plus courantes).
Cela dit, j'ai trouvé très frustrant d'utiliser la documentation - la documentation est abondante, mais elle est rédigée dans un mauvais anglais, ce qui peut aggraver la frustration lors du débogage ou de la tentative de résolution du problème.
Je vais revenir sur Apache Ivy à un moment donné au cours de ce projet et j'espère le faire fonctionner correctement. Une des choses que nous avons eues a été de nous permettre en tant qu’équipe de déterminer les bibliothèques dont 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 que vous devez résoudre vos problèmes de dépendance.
Vous pourriez trouver utiles les ressources suivantes relatives à Ivy:
C'est plus compliqué que le langage que vous avez utilisé pour écrire votre projet. La configurer correctement est plus difficile que la programmation réelle.
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 car au cours des cinq dernières (au moins) entreprises dans lesquelles j’ai travaillé, j’ai effectué des rénovations majeures sur l’infrastructure de construction/déploiement.
Quelques leçons que j'ai apprises:
- La plupart des développeurs ont tendance à ne pas consacrer beaucoup de temps à la construction de systèmes; en conséquence, la construction se transforme en un fouillis de spaghettis, mais ils apprécient quand ce fouillis est nettoyé et rationalisé.
- En ce qui concerne la complexité, je préférerais un système transparent qui expose la complexité (comme Ant) à un système qui tente de simplifier les choses complexes en imposant des restrictions rigides, comme Maven. Pensez à Linux vs Windows.
- Maven a beaucoup de failles dans la fonctionnalité qui nécessitent des solutions de contournement byzantines. Cela conduit à des fichiers POM incompréhensibles et impossibles à maintenir.
- Ant est très flexible et compréhensible, mais les fichiers Ant peuvent devenir très volumineux aussi, car ils sont de bas niveau.
- Pour tout projet important, les développeurs doivent créer leur propre structure de construction/déploiement au-delà de celle fournie par l'outil. l'adéquation de la structure au projet a beaucoup à voir avec la facilité d'entretien. Les meilleurs outils vous aideront à créer une structure et non à vous battre.
J'ai un peu examiné Gradle et il semble qu'il pourrait être le meilleur des deux mondes, permettant un mélange de description déclarative et procédurale.
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 beaucoup contribué à rendre beaucoup plus facile la construction de nombreux projets. Il n'y a pas si longtemps, il fallait des heures pour que le projet moyen OSS Java (basé sur Ant)) soit compilé, devant définir une tonne de variables, télécharger des projets dépendants, etc.
Vous pouvez faire n'importe quoi avec Maven que vous pouvez faire avec Ant, mais lorsque 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 à installer avec Maven, ce qui serait facile à faire avec Ant, mais le résultat final est presque toujours plus facile à construire du point de vue des personnes qui souhaitent simplement consulter un projet et y aller.
Si vous pariez votre entreprise ou votre travail sur un projet de développement, vous voulez contrôler les fondations, c’est-à-dire le système de construction. Avec Maven, vous n'êtes pas en contrôle. C'est déclaratif et opaque. Les développeurs de maven-framework n'ont aucune idée de la manière de construire un système transparent ou intuitif, ce qui ressort clairement de la sortie du journal et de la documentation.
La gestion de la dépendance est très tentante car elle pourrait vous prendre un peu de temps au début du projet mais soyez prévenu, elle est fondamentalement brisé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 la complexité d'un nid de rat qui interrompra la construction de toute votre équipe et bloquera le développement pendant plusieurs jours. Le processus de construction avec Maven est également notoirement incohérent pour 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, ses résultats seront différents. Vous constaterez que vous supprimez l'intégralité de votre référentiel local et que Maven retélécharge de nouveau des fichiers jar bien plus souvent que lors de la première installation d'une branche dev. Je crois que OSGI est une initiative qui tente de résoudre ce problème fondamental. Je dirais que peut-être si quelque chose doit être si complexe, la prémisse fondamentale est fausse.
Cela fait plus de 5 ans que je suis un utilisateur/victime invétéré 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 pour écrire de belles et simples tâches ant. Avec ant, vous savez EXACTEMENT ce que fait votre système de compilation.
J'ai vécu de nombreuses semaines perdues dans plusieurs entreprises en raison de problèmes rencontrés par Maven.
J'ai récemment essayé de ramener à la vie un ancien projet GWT/Maven/Eclipse et deux semaines de mon temps libre plus tard, je ne parviens toujours pas à le construire de manière cohérente. Il est temps de réduire mes pertes et de développer en utilisant ant/Eclipse me pense ...
Je ne dirais pas que sa réputation est aussi mauvaise que mixte. Si votre projet suit le paradigme de la "convention sur la configuration" préconisé par Maven, vous pouvez en tirer beaucoup parti. Si votre projet ne cadre pas bien avec la vision du monde de Maven, il peut devenir un fardeau.
À cette fin, si vous avez le contrôle du projet, alors Maven est peut-être la solution. Mais si vous ne le faites pas et que la mise en page est déterminée par quelqu'un qui n'est pas un fan de Maven, cela risque de poser davantage de problèmes. Les projets Maven les plus heureux sont probablement ceux qui ont commencé comme projets Maven.
Je me suis efforcé de trouver la plupart/tous les négatifs mentionnés ici et les objections similaires de mes coéquipiers, et je les partage tous. Mais j’ai persévéré et je continuerai de le faire en restant fidèle à l’objectif que seul maven (ou grade peut-être) peut réellement atteindre.
Si vous optimisez pour les pairs (open source développeurs), ant/make/tout ce que vous ferez. Si vous fournissez des fonctionnalités à des non-pairs (tilisateurs), seul maven/gradle/etc fera l'affaire.
Seul maven vous permet de libérer un petit paquet de code source + poms (pas de jars de dépendances lib/binary incorporés avec des noms cryptés ni d’informations de dépendance) avec une structure de projet standard bien documentée qui peut être chargée par n’importe quel IDE par quelqu'un qui n'a pas assimilé les conventions de mise en page idiosyncratiques des développeurs. Et il y a une procédure d'installation à un bouton (installation mvn) qui construit tout en acquérant les dépendances manquantes.
Le résultat est une facilité d'accès que ces utilisateurs peuvent suivre pour trouver leur chemin dans le code, où les poms peuvent les diriger vers une documentation pertinente.
En dehors de cette exigence (indispensable), je n'aime pas Maven autant que quiconque.
Tout développeur Java peut facilement devenir un utilisateur ANT expert, mais même pas un expert Java ne peut pas devenir un utilisateur MAVEN de niveau débutant.
Maven fera moins peur à vos développeurs pour tout ce qui est lié à la construction et au déploiement.
Ils vont commencer à respecter Maven plus que le fichier War ou le fichier Ear !! ce qui est mauvais méchant!
Ensuite, vous serez laissés à la merci des forums en ligne, où les fan-boys vous reprochent de ne pas faire les choses à la "Maven way".
Je ferais la distinction entre Maven 1 et 2: le premier a une réputation (à juste titre) mauvaise; ce dernier est une amélioration et un "standard" croissant.
Mon opinion personnelle est que Maven 2 est plus complexe et rigide que je ne le souhaite. Le standard d'un homme est la veste droite d'un autre. Je suis d'accord avec le commentaire "trop de magie" ci-dessus. Quand je compare la simplicité de Ant à la complexité de Maven 2, je sais laquelle je préfère.
J'admets que je connais beaucoup mieux Ant. Je suis en train de grogner Maven 2, mais je ne suis pas encore au bout. Ma mauvaise opinion en dira peut-être plus sur moi et sur l'état de mes connaissances que sur la valeur réelle de Maven 2.
Je pense qu'une des principales raisons de la mauvaise réputation est que maven2 résout plusieurs problèmes complexes (automatisation de la construction, dépendances, gestion des référentiels) en une solution unique. Par conséquent, vous devez faire face à ces problèmes difficiles lorsque vous commencez à utiliser Maven. C'est donc une sorte d'effet "tuez le messager".
D'autres approches (par exemple, ant + ivy) ne vous donnent souvent pas la possibilité de blâmer un seul outil pour tous les problèmes que vous rencontrez. Cela ressemble plus à "d'accord, c'est pas facile de commencer, le lierre a quelques problèmes. Mais au moins, nous n'avons pas à lutter avec Maven!" Dire que l'on ne reconnaît pas que tous ces problèmes pris ensemble ne diffèrent pas beaucoup des problèmes que vous rencontrez lorsque vous utilisez Maven. Il est peut-être un peu plus facile de s’en occuper un à la fois. BTW, j'ai mis en place un système de construction basé sur ant + ivy au cours des derniers mois. Et je suis vraiment content de ne pas avoir à utiliser maven2 ;-)
Ma réponse: la plupart des utilisateurs se plaignent de maven parce qu'ils recherchaient ses avantages, mais ils n'ont pas le temps (ou ils ne veulent pas endurer) de configurer leur "environnement d'entreprise". C’est un choix personnel, cela peut dépendre de votre patience personnelle, de l’environnement de travail (les patrons ne comprennent jamais qu’une chose bien faite leur fait perdre moins de temps qu’un éternel cycle de corrections de bugs), etc.
Cependant, dans les cas suivants, vous ne pouvez avoir que Maven sur votre poste de travail sans vous mettre en colère:
- une bibliothèque simple avec des haricots.
- une simple guerre "tout-en-un".
- même un projet multi-module, qui a les dépendances "standard" (Spring, hibernate, Apache et tout ce que vous pouvez trouver dans le référentiel central) mais N'AVEZ PAS DE DÉPENDANCES sur VOS bibliothèques.
Les problèmes commencent à arriver quand vous en voulez plus, comme créer vos wrappers dans des classes de frameworks standard, ou des bibliothèques de composants réutilisables, vous voulez toujours utiliser un ensemble de plugins que vous aimez, etc.
Dans ce cas vous devez investir votre temps dans l'apprentissage: J'ai lu dans des billets précédents que quelqu'un parlait de gaspiller une demi-journée ou deux jours ... cela ne suffisait pas du tout: nous parlons de modifier vos poms continuellement pendant au moins 1 mois.
Si vous voulez utiliser Maven dans des projets complexes, vous devez dans l’ordre:
- avoir votre référentiel interne: ce n'est pas une option, c'est obligatoire. J'ai essayé Artifactory et Nexus, ils peuvent créer des problèmes au début, mais lorsque vous les installez une fois, vous les oubliez.
- créez un "maître pom" contenant tous les plugins (avec la version relative spécifiée) dont vous avez besoin, mais vous devez éviter d'y mettre vos dépendances standard si vous ne voulez pas avoir d'ennuis (pour cela, voir la portée = import dans dependenciesManagement). C’est la partie la plus difficile, mais vous pouvez commencer à copier le maître d’un projet célèbre (printemps, tapisserie, etc.) et supprimer ce dont vous n’avez pas besoin.
- si vous avez un projet complexe, vous devez penser à ce que vous voulez avant de commencer à créer les artefacts. Par exemple, dans un projet qui a (war + WebServices Client) + (Webservice Server + spring + hibernate + Jbpm + whatelse ....), il est conseillé de créer un module "api" référencé à la fois par le client. et le serveur, mais qui ne contient que modèle + interfaces et n'apporte pas les dépendances "côté serveur" du côté client et l'inverse. Si vous échouez là-dedans, Maven deviendra un enfer vivant sur terre.
- si vous utilisez Eclipse, le plug-in m2e est essentiel: ok, cela peut être lent, vous devez parfois actualiser le projet et mettre à jour la configuration du projet, etc., mais trouver le "chemin de construction du projet" déjà défini vaut tout. Et dans le pire des cas, la ligne de commande fonctionnera toujours.
- Bien qu'un serveur d'intégration continue soit facultatif, il est fortement recommandé au moins pour vos bibliothèques communes. Mettre une application Web sur CI peut s'avérer excessif (vous ne réutilisez pas une application Web sur plusieurs projets), mais mettre sur CI vos classes de base standard, vos beans entité "toujours utilisés", etc. n'a pas de prix. N'oubliez pas que ces composants ne sont pas utilisés uniquement par vous, mais qu'ils peuvent également être utilisés par vos collègues lorsque vous êtes occupé par d'autres parties du code et que vous pouvez oublier (je le fais souvent) de les déployer manuellement dans le référentiel de l'entreprise pour les rendre. disponible pour les membres de l'équipe.
Pour que tout cela soit réglé ... eh bien, vous pouvez même passer des mois au début, mais une fois que vous vous y serez habitué, vous accélérerez beaucoup votre développement.
Personnellement, je n'ai pas encore utilisé Gradle, je ne sais pas si c'est meilleur ou pire que Maven.
La principale raison pour laquelle Maven a un mauvais coup dur est IDE intégration. Oui, je connais m2Eclipse. J'aime beaucoup m2Eclipse. J'aime encore davantage l'intégration Netbeans.
Voici le problème. Certains grands magasins ont créé des outils pour forcer Maven à travailler avec des objets tels que RAD 7.0. Cela ne fonctionne pas bien. Ces hackarounds existent pour essayer d'inciter Maven à se comporter à l'intérieur d'un outil auquel il n'est pas autorisé. Pour changer (RAD 7.0). Dans mon cas, les constructions maven arquées ne fonctionnent que dans Netbeans. Eclipse 3.5 avec m2Eclipse étouffe quelque chose d'horrible.
La plupart des développeurs ici détestent Maven. Ils ne détestent pas Maven. Ils n'ont jamais vraiment utilisé Maven.
C'est décevant, mais ce n'est pas vraiment la faute de Maven. Maven a travaillé plus que bien pour moi dans une autre vie. Ici, c'est débilitant à cause du IDE) et les outils destinés à le rendre utilisable échouent.
Il est courant que les défenseurs Maven disent "bon, vous ne comprenez tout simplement pas". Ceci, pensent-ils, est une vraie réplique vive.
Ça va comme ça:
Super programmeur: "hé, je dois garder cette porte ouverte. Quelqu'un a-t-il un butoir?" la porte ouverte! " Maven Programmer (béat, gloussant): "Tu ne comprends tout simplement pas. Je te suggère de lire le manuel et d'étudier vraiment le sujet pendant environ un an !!!"
Mon point de vue ici, basé sur les pièges de la convention sur la configuration:
http://chriswongdevblog.blogspot.com/2011/01/trouble-with-being-conventional.html
Mon problème avec Maven est la difficulté de la découverte et la complexité illimitée. Cela et regarder des collègues perdre une demi-journée de travail à lutter contre les problèmes de construction de Maven. Aussi à mon humble avis, l’intégration de Maven avec Eclipse ne fait qu’aggraver les choses, car vous avez multiplié le nombre de lieux où les choses tournent mal.
D'accord, je ne sais pas grand-chose sur Maven pour entrer dans les détails, mais j'ai essayé de le faire fonctionner plus de fois que je ne veux l'admettre.
Pour moi, utiliser Maven est assez simple à condition que:
. Vous devez "embaucher" un gourou Maven spécial que vous n'avez pas pour fourmi; sinon, demandez à vos développeurs de passer du temps à apprendre à "construire" leur travail au lieu de savoir comment "faire" leur travail
. Vous devez "acheter" le Livre "qu'ils" vendent si vous voulez vraiment le comprendre.
Et alors:
. Cela résout fondamentalement un seul problème réel "les dépendances" Je me demande combien de projets existent qui dépendent de tant d’autres projets qu’ils ont besoin d’un outil spécial pour résoudre les dépendances? Et ANT ne peut pas le faire?
. Personnellement, je ne passe pas aveuglément aux dernières versions des frameworks open source sans en voir le besoin. Si cela fonctionne alors ne le répare pas, non?
Mais alors c'est subjectif est-ce pas?
Maven est un outil de gestion de logiciel pouvant augmenter votre productivité. Je pense qu'un tel outil est essentiel pour le développement de logiciels dans une nouvelle ère.
Cependant, Maven ne convient pas à toutes les bases de code. Si vous devez prendre en charge une grande page de code héritée ou si vous importez du code provenant d'une tierce partie, il est préférable d'éviter de l'utiliser. Maven s'attend à ce que les choses se passent d'une certaine manière (convention sur la configuration). Si vous commencez un nouveau projet, c'est plus que correct. Si, toutefois, vous avez un système complet à prendre en charge, le manque de flexibilité est un cauchemar.
Une autre raison pour laquelle les gens se plaignent de Maven est la courbe d'apprentissage abrupte. Aussi IDE l'intégration n'est pas encore très mature. Apache propose deux plug-ins pour Eclipse. L'un est "mature", l'autre propose une nouvelle approche. Je suppose que le nouveau ne serait pas nécessaire si le premier était adéquat.
Une autre plainte plus sérieuse à propos de Maven est l’utilisation de XML pour la programmation. Peut-être que des outils comme Buildr sont la voie à suivre.
C'est l'approche "tout-ou-rien" déjà mentionnée qui explique que j'utilise généralement Ant à la place ... Bien plus souvent, vous travaillez sur un projet "ancien", qui possède déjà une structure définie que vous ne pouvez pas modifier. juste parce que Maven veut les choses autrement.
Ant peut en revanche être utilisé à tout moment, quelle que soit la désorganisation du projet.
En ce qui concerne les alternatives, j'ai lu de bonnes choses à propos de rake.
(Btw, je parle de Maven 1, n'ont pas encore examiné Maven 2)
Très simplement, Maven veut posséder le monde. Il veut définir des projets, leur disposition sur le système de fichiers, l'emplacement des fichiers dans son cache local Cutesy, comment récupérer des objets, des graphes de dépendance, des plugins de construction, des plugins IDE, etc., etc.
Certaines personnes aiment ce genre de chose, l'admirent. Pour moi, tout est une question de qualité, je me moque bien de vos théories boooooring. Exécutez-le, faites-le parfaitement, puis fondez-vous de préférence jusqu'à ce que je décide de jouer à nouveau avec vous.
Mon message aux adhérents/apologistes de Sonatype et de Maven est que vous ne suez pas encore avec qualité. Le format pom.xml est trop détaillé, académique et fastidieux - corrigez-le. Des constructions complexes et multiprojets sont difficiles à configurer avec Maven - pourquoi si dur? Régler avec précision quand chercher et quand ne pas chercher des pots sous-spécifiés serait une chose intéressante - jusqu'à ce que nous obtenions cela, la stratégie de fouin de chercher quand nous pouvons/pensons que nous voulons est exaspérante. SNAPSHOT est toujours tout en majuscule parce qu'il crie/se moque de moi et me rend fou? Les minutae et goofy/uniques façons cruddy open source plugins maven plug-in dans Poms est exaspérant. Problèmes de classpath sans aucun moyen de les résoudre? Oh oui, et l'héritage Apache commons- * groupId pollue la racine de mon référentiel sont exaspérants dans un "les triangles de fromage ne vont pas de cette façon !!" - une sorte de rage. m2Eclipse est une pure folie concentrée, meurs monstre meurs, tue-les au feu, c’est le seul moyen d’en être sûr.
Maven m'a embarrassé une fois devant un client - il est inexcusable qu'un outil m'empêche d'être productif! Je veux que mes outils (et leurs fabricants) agissent comme les humbles serviteurs qu'ils sont. Quand je demande à Maven qui est le roi, je m'attends à ce que la réponse soit "DAVE" suivi de plaisanteries et de beaucoup de révérence! :)
L'inertie est la vraie histoire avec Maven. Si vous voulez jouer avec Java open source, vous allez extraire d'un référentiel Maven. Donc, si vous voulez jouer à Nice là-bas, vous feriez mieux de pouvoir obtenir vos dépendances à la manière de Maven et d'apprendre à lire les poms ... Dieu merci, Ivy et IvyDE, que je puisse régler mes dépendances de maven à la fois dans Ant et Eclipse et ne pas être coincé avec la chaîne d'outils Maven.
Les logiciels de serveur de référentiel Maven que j'ai utilisés, tels que Nexus et Artifactory, sont des outils nets et futuristes. Ils sont des bijoux scintillants par rapport au reste de l'écosystème Maven.
Mon expérience Maven ressemble à ce que ressentait Eclipse dans la journée. Eclipse voulait aussi posséder le monde avec ses idées stupides, et il a fallu beaucoup de temps pour que la plate-forme mûrisse, des années et des années, avant que je ne permette vraiment à Eclipse de posséder mon monde. Peut-être que dans des années et des années, Maven pourra atteindre ce niveau de qualité? À ce stade, je dis "plus jamais mes yeux ne seront témoins des horreurs", mais je disais cela aussi à propos d'Eclipse 1.0 quand il est sorti. :)
Maven résout les problèmes de travail, il construit Java, et gestion facile des dépendances. Mais il est très différent de Ant et GNU Make, ou autre Unix- comme le système de gestion des paquets, ce qui oblige le nouveau-venu à payer beaucoup pour l’apprendre.
Il y a beaucoup de documents Maven, mais certains d'entre eux en poussant vous écartez, comme ceci de "utiliser m2Eclipse":
En entrant simplement un groupId dans le champ de requête, m2Eclipse interroge les index du référentiel et affiche même une version de l'artefact se trouvant actuellement dans mon référentiel Maven local. Cette option est préférable car elle représente un gain de temps considérable.
Je déteste vraiment comprendre une longue phrase et j'ai trouvé qu'elle ne dit rien. Je me souviens à quel point la lecture de python est un tutoriel officiel, et celle de erlang. Un bon document montrera à l'auteur qu'il a de bons sens.
Maven semble étrange aux nouveaux venus, son style de ligne de commande est différent des traditions de ligne de commande Unix. Si vous payez du temps pour passer en revue "par exemples" ou "Le Guide définitif", cela vous rapportera, vous pouvez le trouver sur http://www.sonatype.com/ . Mais même si vous lisez tous ces documents et pouvez utiliser l'outil avec des confidences, vous pouvez rencontrer des problèmes de temps en temps, certains causés par des bogues logiciels. Et les experts ont les moyens de vivre avec et de rester productifs.
Après tout, Maven est un logiciel open source, il apporte des connaissances aux ingénieurs indépendants. Et cela le rend respectueux. Quand les gens parlent plus de sa mauvaise réputation , ils font du bon travail pour le monde open source.
Donc, comme les personnes qualifiées utilisent tous les outils, utilisez-les simplement et ne vous en fiez pas, dépend de vous .
Maven ne prend pas facilement en charge les opérations non standard. Le nombre de plugins utiles est en augmentation constante. Ni Maven, ni Ant ne supportent facilement/intrinsèquement le concept de dépendance de fichier de Make.
Avantages:
Maven est formidable lorsque vous devez être opérationnel rapidement et que la gestion des dépendances est bonne. Les facilités pour éviter l'enfer ne sont pas mal non plus. Une partie de la théorie sous-jacente à Maven est bonne. Les phases du cycle de vie par défaut sont bien pensées et très instructives pour tous ceux qui souhaitent apprendre les meilleures pratiques en matière d'ingénierie. Malgré la faible documentation, la découvrabilité est excellente, essayez avec mvn help: help -Ddetail = true pour voir ce que je veux dire. Si vous savez lire un document xsd, alors construire un pom n’est pas si difficile.
Inconvénients (le diable est dans les détails):
On ne peut pas spécifier l'ordre des différentes exécutions de plug-in liées à la même phase, et toute forme de non-déterminisme dans la programmation informatique est tout simplement terrible.
Contrairement aux valeurs de la propriété Ant c'est-à-dire) $ {my.property}, les propriétés Maven sont résolues au début de la construction, ce qui est OK si vous connaissez la valeur au début, mais si la valeur de la propriété est déterminée quelque part au milieu. de votre construction, il est trop tard pour y accéder, il a déjà été interprété avant son affectation, donc la valeur sera null ou la chaîne vide. C'est même le cas lorsque l'exécution qui nécessite la propriété est exécutée dans une phase après l'exécution qui attribue la propriété -> me déchirer les cheveux par-dessus celle-ci.
Si vous vous en tenez à la "méthode Maven", tout se passe bien. Dès que votre construction s'éloigne de la "voie Maven", l'enfer se déchaîne -> attendez-vous à devenir très bon en programmant des plugins et des archétypes Maven pour votre projet, car le faire à partir de zéro sera plus efficace que de s'affranchir des contraintes de Maven.
Lorsque vous travaillez sur des projets volumineux contenant de nombreux fichiers pompés utilisant l'agrégation (modules en langage Maven) et l'héritage (parents en langage Maven), il y a beaucoup trop de duplication entre des versions faisant la même chose ou des tâches similaires. La grammaire Maven xml ne fournit aucun moyen clair de distinguer les membres qui seront hérités du parent et ceux qui ne le seront pas. Attendez-vous à courir mvn help:effective-pom toutes les deux minutes pour comprendre celui-ci.
Les constructions complexes avec de nombreuses configurations de plug-ins deviennent gonflées et incompréhensibles. C'est plus un problème avec XML que Maven lui-même. Il existe des manières beaucoup plus claires et plus expressives d'écrire une construction -> telle qu'une DSL interne dans un langage dynamique qui prend en charge la méta-programmation, par exemple Gradle, Buildr
Profils: avec un grand pouvoir vient une grande responsabilité. Il est tout simplement trop facile de coller une configuration qui appartient aux environnements de déploiement respectifs à l'intérieur de la construction elle-même, ce qui enfreint le principe "un binaire". Les profils doivent être conçus de manière à mettre l’accent sur les "rôles" plutôt que sur les environnements, c’est-à-dire le fait de procéder au déploiement de CI à un transfert plutôt qu’à conserver la configuration du transfert lui-même.
Maven est cool.
Arrêtez d'écouter les alternatives, car pour le moment, il n'y en a pas - qui ne sont pas que des jouets.
Hormis la chaîne d’outils de développement Microsoft, c’est la meilleure technologie que l’argent ne puisse pas acheter.
Tous ces groupes qui essaient de pousser "toolchain du jour" - c'est juste une tentative peu coûteuse de semer la confusion et de s'emparer d'une part du marché.
Les haineux se détestent.
- SBT
Le plus mal nommé dans l'histoire de la terre. Votre build peut-il passer un test de Turing? Putain de ridicule, un pas en arrière de 10 ans avec son DSL ridicule. Utilise la gestion des dépendances IVY, le frère moyen de Maven.
- FOURMI
Parfait pour ce premier projet après votre diplôme de développement Shockwave.
Vous comprenez le XML et vous êtes enthousiaste, mais vous ne comprenez pas vraiment les phases de construction. Vous redémarrez un projet 6 mois plus tard. Pourquoi le contrôle de version d'artefacts binaires est-il une fausse panacée ou qu'une autre personne tentera un jour de travailler avec votre projet?.
- MAKE
Si le monde entier fonctionne dans le même terminal UNIX et parle couramment Bash, alors oui. Mais pourquoi ne pas devenir un programmeur C/C++, c’est beaucoup plus amusant que Java de toute façon.
- Ruby (Divers)
Peu importe. Niche, lente. Il suffit de développer Ruby alors, éloignez-vous du Java développement.).
- Python
Les gens utilisent Java où ils ne font pas confiance Python (n'importe où de l'argent est impliqué). Si votre système est en cours d'exécution Python de toute façon, vous ne lirez même pas ceci, à moins bien sûr que vous vouliez l'argent Java - mais êtes en train de développer Python dans une boutique en ligne).
- Clojure (Divers)
En l'honneur de Stallman, j'apprendrai LISP - mais pour Emacs, pas pour que je l'exécute sur ma machine virtuelle. Je pense que cela déprécie l'expérience.
Maven ne respecte pas le principe KISS . Essayez de faire quoi que ce soit en dehors de MVN Clean Install et vous êtes en difficulté. Avec fourmi, vous pouvez faire ce que vous voulez sans aucune douleur.
Nous utilisons maven2 dans tous nos projets et cela décuple le développement (combiné à une plate-forme d'intégration continue de Nice).
Le mécanisme de dépendance transitive est la seule caractéristique de maven2 qui nous a causé beaucoup de maux de tête dans le passé. Dans un monde utopique, ce serait la solution ultime à tous les problèmes de dépendance, mais en pratique, cela tend à vous envoyer directement dans l'enfer de la dépendance.
Notre principal problème provient du fait que divers composants du référentiel par défaut maven2 dépendent de différentes versions de la même bibliothèque (i.e composant1 et composant2 nécessitent tous deux un cadre de journalisation, mais composant1 nécessite v1 et composant2 nécessite v2).
Pour résoudre ce problème, nous avons simplement notre propre référentiel local contenant toutes les bibliothèques dont nous avons besoin. Cela nous permet de nous assurer que toutes les bibliothèques que nous utilisons et qui ont leurs propres dépendances dépendent des mêmes versions d'autres bibliothèques.