Buildr, Gradle ou attendre Maven 3 ?

Question

Je suis vraiment fatigué de me débattre sans cesse avec Maven 2. Les outils de construction ne devraient pas être un obstacle. Récemment, je me suis penché sur Buildr et Gradle. Maven 3 semble résoudre certains problèmes. Alors, que dois-je choisir maintenant ? Buildr ? Gradle ? Ou attendre un an pour Maven 3 ?

Answer 1

Aucun système de construction n'est une solution miracle. Je trouve que Maven résout plus de problèmes qu'il n'en cause pour moi, mais je suis tout à fait à l'aise pour écrire des plugins pour contourner ses défauts. Je m'occupe aussi de centaines de projets, donc l'héritage et le traitement des dépendances de Maven me sont très utiles.

Parcourez un peu SO et vous verrez que Buildr et Gradle ont tous deux des problèmes (de même pour Ant et Ivy), généralement vous échangez un ensemble de problèmes contre un autre et il s'agit de trouver le moins douloureux.

Y a-t-il quelque chose de particulier qui vous dérange dans Maven ou est-ce une démangeaison générale ? S'il s'agit d'un problème particulier, cela vaut la peine d'examiner le fichier Problèmes de Maven 3 sur Jira si le problème n'est pas abordé, vous pouvez le soulever, sinon il est inutile d'attendre.

Answer 2

Je n'attendrais pas grand chose de Maven 3. Les personnes à l'origine des outils de construction Maven ont toujours supposé que les constructions de projets sont homogènes, c'est-à-dire que tous les problèmes de construction se résument fondamentalement au même problème. Cette vision du monde peut être maintenue de manière assez cohérente face à des points de vue opposés, mais elle a un coût. L'absence de logique de script dans Maven ("quand vous voulez script, vous savez que vous faites quelque chose de mal"), la lourdeur de l'API des plugins ("aucun utilisateur ordinaire de Maven ne devrait vouloir écrire un plugin") et le référentiel central ("nous avons tous les mêmes dépendances") sont autant de témoignages de cette hypothèse générale.

Dans le monde réel, les problèmes de construction sont hétérogènes car les gens construisent des logiciels pour une grande variété de raisons. Ils se " développent " tous comme nous " forons des trous " de temps en temps pour résoudre des problèmes uniques. Quel que soit votre niveau d'abstraction, vous trouverez toujours des similitudes en comparant des problèmes de développement arbitraires. C'est la réverbération de ces similitudes et la condamnation des différences qui constituent l'écueil de la conception de Maven et la raison pour laquelle elle suscite tant de critiques. Fondamentalement, Maven est autoritaire et utopique dans ses perspectives.

PS : Maven possède de bonnes fonctionnalités, comme la convention sur la configuration et l'idée d'utiliser des dépôts (la mise en œuvre de cette idée par Maven est problématique).

Answer 3

Nous utilisons Maven ici, mais je trouve que dès que l'on sort d'un projet simple, le pom.xml commence à devenir de plus en plus complexe. Vous commencez à passer beaucoup de temps à chercher comment configurer votre pom pour faire ce que vous voulez, et comment contourner les différents problèmes.

Ce qui m'a vraiment interpellé, c'est l'oreille que nous construisons. Ce fichier ear contient plusieurs wars, et Maven place normalement les bibliothèques dans les wars. Cependant, pour réduire la taille des wars, et pour garder les jars identiques, nous voulions placer les jars partagés entre les wars dans le répertoire lib de l'ear.

Malheureusement, Maven ne gère pas très bien cette situation. Nous avons dû le configurer manuellement pour chacun des pom de la guerre, puis ajouter toutes ces dépendances dans le pom de l'oreille.

Dans un autre projet, nous avons des fichiers d'aide en HTML. Les personnes qui rédigent l'aide l'écrivent dans Microsoft Word puis utilisent un programme pour les traduire en HTML. Un seul changement de caractère peut se répercuter sur des centaines de fichiers.

Pour contourner ce problème, notre système d'aide est stocké dans notre dépôt de sources sous la forme d'un seul fichier zippé. Lorsque notre équipe de documentation crée un nouvel ensemble de fichiers d'aide, elle le zippe et remplace ce qui se trouve dans le référentiel.

Donc, une partie de ma construction consiste à décompresser ce fichier et à le placer dans la guerre. Facile à faire dans Ant, impossible à faire dans Maven à moins d'utiliser le plugin Antrun qui vous permet d'écrire du code Ant pour gérer les problèmes que Maven ne peut pas gérer sans un plugin complet.

Je peux voir ce que Maven fait, mais la théorie a pris le pas sur la réalité. Ce que j'ai trouvé, c'est qu'Ivy et Ant peuvent faire la plupart des vérifications de dépendances que Maven fait sans tous les problèmes d'écriture et de maintenance des poms.

Si vous n'utilisez pas encore Maven, essayez d'abord Ant avec Ivy. Puis, quand Maven 3 sortira, essayez-le. Je me souviens de la transition de Maven 1 à Maven 2. Ils étaient totalement incompatibles entre eux et tout ce que vous aviez appris avec Maven 1 était obsolète. Il serait idiot d'apprendre et de refaire vos projets dans Maven 2 pour vous retrouver soudainement à tout refaire pour Maven 3.

Answer 4

maven 3.x est déjà intégré dans les IDEs (au moins sur netbeans, vérifiez ce lien pour plus d'informations). Vous pouvez jouer aujourd'hui avec maven 3.x en construisant simplement un projet Maven avec netbeans.

Une autre bonne nouvelle est que maven a obtenu plus de support 'entreprise' avec l'intégration d'EJB/WS dans les projets IDE (encore une fois, au moins sur netbeans).

Je m'en tiendrais donc à maven 2.x pour les constructions de production et je jouerais avec maven 3.x pour le développement.

Answer 5

Maven 2 et 3 ont tous deux fonctionné parfaitement pour moi sur une variété de projets. J'utilise actuellement Maven 3 alpha 7 qui fonctionne très bien, surtout en conjonction avec le plugin Maven d'Eclipse.

Maven s'intègre parfaitement à Ant - dans les deux sens. Dans mon projet actuel, nous invoquons Maven depuis Ant plusieurs fois afin d'effectuer des tests d'intégration complexes. De même, nous utilisons Ant via le plugin AntRun de Maven, et nous avons également écrit nos propres plugins Maven. Ceci, soit dit en passant, est une question de minutes et se résume à écrire un Pojo annoté.

Maven est souvent critiqué parce que de nombreux développeurs n'aiment pas les règles ou les conventions. Tout simplement, personne ne vous oblige à utiliser Maven. Si vous voulez la liberté ultime - par tous les moyens - réécrivez votre propre processus de construction pour chaque projet auquel vous participez. Cependant, si vous aimez créer des logiciels plutôt que de réinventer la roue avec un processus de construction sur mesure pour chaque projet, optez pour Maven.