Buildr, Gradle ou attendre Maven 3?
Je suis vraiment fatigué de lutter constamment contre Maven 2. Les outils de construction ne devraient pas gêner. Récemment, j'ai regardé Buildr et Gradle. Maven 3 semble résoudre certains des problèmes. Alors, que dois-je faire maintenant? Buildr? Gradle? Ou attendre un an pour Maven 3?
Aucun système de construction n'est une solution miracle. Je trouve que Maven résout plus de problèmes que cela ne me cause, mais je suis assez à l'aise pour écrire des plugins pour contourner ses lacunes, je traite également des centaines de projets, donc le traitement de l'héritage et des dépendances de Maven est très utile pour moi.
Parcourir SO un peu et vous verrez que Buildr et Gradle ont tous les deux des problèmes aussi (même pour Ant et Ivy), généralement vous échangez un ensemble de problèmes pour un autre et c'est un cas de trouver le moins douloureux.
Y a-t-il quelque chose en particulier qui vous dérange chez Maven ou est-ce une démangeaison générale? S'il s'agit d'un problème particulier, il vaut la peine de regarder les Maven 3 issues on Jira , si le problème n'est pas résolu, vous pouvez le soulever, sinon il peut être inutile d'attendre
Je n'attendrais pas trop de Maven 3. Les personnes derrière le pedigree Maven des outils de construction ont toujours pensé que les constructions de projet 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 opinions opposées, mais elle a un prix. L'absence de logique de script dans Maven ("lorsque vous voulez créer un script, vous savez que vous faites quelque chose de mal"), la lourde API du plugin ("aucun utilisateur Maven ordinaire ne devrait vouloir écrire un plug-in") et le référentiel central ("nous tous ont les mêmes dépendances ") sont tous des témoignages de cette hypothèse globale.
Dans le monde réel, les problèmes de construction sont hétérogènes car les gens créent des logiciels pour une grande variété de raisons. Ils se "développent" tous comme nous "forons" de temps en temps pour résoudre des problèmes uniques. Quel que soit votre niveau d'abstraction, vous trouverez toujours des similitudes lorsque vous comparez des problèmes de construction arbitraires. C'est la révérence de ces similitudes et la condamnation des différences qui sont la chute du design de Maven et la raison pour laquelle il attire autant de critiques. Fondamentalement, Maven est autoritaire et utopique dans ses perspectives.
PS: Maven a de bonnes fonctionnalités, comme la convention sur la configuration et l'idée d'utiliser des référentiels (l'implémentation Maven de cette idée est gênante).
Nous utilisons Maven ici, mais je trouve qu'une fois que vous sortez d'un projet simple, le pom.xml commence à devenir de plus en plus complexe. Vous commencez à passer beaucoup de temps à déterminer comment diable configurer votre pom pour faire ce que vous voulez, et comment contourner les différents problèmes.
Ce qui m'a vraiment attiré, c'est l'oreille que nous construisons. Nous avons plusieurs guerres dans ce fichier d'oreille, et Maven colle normalement les bibliothèques dans les guerres. Cependant, pour réduire la taille des guerres et garder les pots tout de même, nous voulions mettre les pots partagés entre les guerres dans le répertoire lib de l'oreille.
Malheureusement, Maven ne gère pas très bien cela. Nous devions configurer manuellement cela pour chacun des poms des guerres, puis ajouter toutes ces dépendances dans le pom de l'oreille.
Dans un autre projet, nous avons des fichiers d'aide HTML. Les personnes qui rédigent l'aide les écrivent dans Microsoft Word puis utilisent un programme pour les traduire en HTML. Un changement de caractère unique peut se répercuter sur des centaines de fichiers.
Pour contourner ce problème, notre système d'aide est stocké dans notre référentiel source sous la forme d'un fichier zippé unique. 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 en guerre. Facile à faire dans Ant, ne peut pas le 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 fait Maven, mais la théorie a devancé la réalité. Ce que j'ai trouvé, c'est qu'Ivy et Ant peuvent faire la plupart des vérifications de dépendance que Maven fait sans tous les problèmes d'écriture et de maintenance des poms.
Si vous n'utilisez pas déjà Maven, essayez d'abord Ant avec Ivy. Puis quand Maven 3 sortira, essayez ça. Je me souviens de la transition de Maven 1 à Maven 2. Ils étaient totalement incompatibles et tout ce que vous avez appris en utilisant Maven 1 était obsolète. Il serait stupide d'apprendre et de refaire vos projets dans Maven 2 pour vous retrouver soudainement à tout refaire pour Maven 3.
maven 3.x est déjà intégré dans les IDE (au moins sur les netbeans, consultez ce lien pour plus d'informations). Vous pouvez jouer aujourd'hui avec maven 3.x en construisant simplement un projet Maven avec des netbeans.
Une autre bonne nouvelle est que maven a obtenu plus de support "d'entreprise" avec l'intégration d'EJB/WS dans les projets IDE (encore une fois, au moins sur les netbeans).
Je m'en tiendrai donc à maven 2.x pour les versions de production et je jouerais avec maven 3.x pour le développement.
Maven 2 et 3 ont tous deux parfaitement fonctionné 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 Eclipse Maven.
Maven s'intègre parfaitement avec Ant - dans les deux sens. Dans mon projet actuel, nous invoquons Maven de Ant plusieurs fois afin d'effectuer un test d'intégration complexe. De même, nous utilisons Ant via le plugin AntRun de Maven, et nous avons également écrit nos propres plugins Maven. Soit dit en passant, cela ne prend que quelques minutes et se résume à l'écriture d'un Pojo annoté.
Maven reçoit beaucoup de critiques car de nombreux développeurs n'aiment pas les règles ou les conventions. Tout simplement, personne ne vous oblige à utiliser Maven. Si vous voulez une liberté ultime - par tous les moyens - réécrivez votre propre processus de construction pour chaque projet que vous rejoignez. Cependant, si vous aimez créer un logiciel plutôt que de réinventer la roue avec un processus de construction personnalisé sur chaque projet, optez pour Maven.
Gardez votre code bien entretenu et divisé en modules bien définis et le portage entre les systèmes de construction devient un problème mineur.
Pour l'instant, maven-2 est un bon choix pour le milieu 2/3 des projets. Pour le très simple, la fourmi est toujours ok. Pour les très complexes, un hybride de maven-2 et d'autres outils (comme antrun) devient inévitable.
Vous ne savez pas pourquoi vous rencontrez des problèmes avec maven-2.
Il diffère de ant et buildr en ce qu'il est un outil pour décrire votre processus de construction, pas pour l'écrire. Les constructions complexes, celles avec plusieurs parties dynamiques et les dépendances imbriquées et/ou transitoires sont difficiles à construire car elles sont difficiles à décrire.
Essayez Lattice https://github.com/hackingspirit/Lattice essayez. Je suis l'auteur. Voici le scoop:
Dans Lattice, les fichiers de construction ne sont pas écrits en XML, mais dans le langage Python. Les avantages sont une meilleure lisibilité et un puissant script de construction impératif pris en charge par Python. Pour les projets multi-modules. Lattice utilise tri topologique pour décider de l'ordre correct de construction de chaque module. Il est également prévu que Lattice analyse la dépendance du module pour déterminer comment la compilation du module peut être parallélisée. Le code source de Lattice est extrêmement léger, il se compose actuellement d'environ 500 lignes de Python.
Je pense que les gens qui se plaignent de Maven devraient passer un peu plus de temps à enquêter sur les plugins disponibles. En réponse aux commentaires se plaignant que Maven est rigide et rend difficile l'utilisation d'une logique de construction personnalisée/offre un contrôle précis sur le processus de construction - je recommanderais d'examiner le plug-in Ant pour Maven (il y en a plusieurs, mais en voici un) : http://maven.Apache.org/plugins/maven-antrun-plugin ). J'ai eu beaucoup de succès à personnaliser les builds Maven avec lui au fil des ans. Fondamentalement, cela vous permet d'exécuter n'importe quelle commande Ant dans le cadre de la construction Maven, et vous pouvez faire à peu près n'importe quoi avec Ant;)
Ant avec Ivy fait la même gestion des dépendances que Maven (en fait, il utilise toute l'infrastructure de gestion des dépendances de Maven, y compris les mêmes référentiels URL), mais sans tout le désordre de configuration POM.
Ant with Ivy pourrait être un moyen de gérer les problèmes de dépendance pour les personnes qui ne veulent vraiment pas utiliser Maven. Il résout 90% des problèmes que Maven était censé résoudre.