Buildr, Gradle ou attendre Maven 3? [fermé]

Question

Je suis vraiment fatigué de lutter avec Maven 2 tout le temps. Construire des outils ne devraient pas être de la manière. Récemment, je l'ai regardé Buildr et Gradle. Maven 3 semble corriger quelques-unes des luttes. Alors, que dois-je faire maintenant? Buildr? Gradle? Ou attendre un an pour Maven 3?

Answer 1

Aucun système de construction est une balle magique. Je trouve Maven résout plus de problèmes qu'elle provoque pour moi, mais je suis plug-ins d'écriture assez confortable pour contourner ses lacunes, je traite aussi des centaines de projets, de sorte que l'héritage de Maven et le traitement des dépendances est très utile pour moi.

Parcourir donc un peu et vous verrez Buildr et Gradle les deux ont des problèmes aussi (même pour Ant et Ivy), vous êtes généralement la négociation d'un ensemble de problèmes pour une autre et son cas de trouver le moins douloureux.

Y at-il quelque chose en particulier qui vous tracasse au sujet de Maven ou est-ce une démangeaison générale? Si c'est un problème particulier, il est intéressant de regarder Maven 3 numéros sur Jira, si le problème n'est pas adressée, vous pouvez soulever, ou bien il peut y avoir peu de point en vous attendant

Answer 2

Je ne me attends pas trop de Maven 3. Les gens derrière le pedigree Maven des outils de construction ont toujours tenu l'hypothèse que projet construit sont homogènes, qui est la suivante: tous les problèmes construire ébullition fondamentalement vers le bas pour le même problème. Cette vision du monde peut être tenu de façon assez constante face à des points de vue opposés, mais a un coût. L'absence de logique de script dans Maven ( « quand vous voulez script que vous savez que vous faites quelque chose de mal »), l'API de plug-in lourd ( « aucun utilisateur Maven ordinaire doit vouloir écrire un plug-in ») et le dépôt central ( «nous tous ont les mêmes dépendances ») sont tous Testaments de cette hypothèse globale.

Dans le monde réel construire des problèmes sont hétérogènes parce que les gens construisent des logiciels pour une grande variété de raisons. Ils ont tous « développer » comme nous l'avons une fois « trous » tous dans un certain temps pour résoudre des problèmes particuliers. Quel que soit votre niveau d'abstraction vous trouverez toujours des similitudes lorsque l'on compare les problèmes de construction arbitraires. Il est le reveration de ces similitudes et la condamnation des différences qui est la chute pour la conception de Maven et la raison pour laquelle il tire tant pare-balles. Fondamentalement, Maven est autoritaire et utopique dans ses perspectives.

PS:. Maven a de bonnes caractéristiques, comme la convention sur l'autre configuration et l'idée d'utiliser des référentiels (la mise en œuvre de cette idée Maven est gênant)

Answer 3

Nous utilisons Maven ici, mais je trouve qu'une fois que vous obtenez en dehors d'un simple projet, le pom.xml commence à devenir de plus en plus complexe. Vous commencez à passer beaucoup de temps comment dans l'estacade pour configurer votre pom faire ce que vous voulez, et comment travailler autour des questions diverses.

La seule chose qui m'a vraiment été l'oreille que nous construisons. Nous avons plusieurs guerres dans ce fichier de l'oreille, et Maven des bâtons les librairies dans les guerres. Cependant, pour réduire la taille des guerres, et de garder les pots tout de même, nous voulions mettre les pots partagés entre les deux guerres dans le répertoire lib de l'oreille.

Malheureusement, Maven ne gère pas très bien. Nous avions besoin de configurer manuellement ce pour chacune des guerres de poms de, puis ajoutez toutes ces dépendances dans la pom de l'oreille.

Dans un autre projet, nous avons des fichiers d'aide HTML. Les gens qui écrivent l'aide pour les écrire dans Microsoft Word puis utilisez un programme pour les traduire en HTML. Un changement de caractère peut se répercuter à travers des centaines de fichiers.

Pour contourner ce problème, notre système d'aide est stocké dans notre référentiel source comme un seul fichier compressé. Lorsque notre équipe de documentation crée un nouvel ensemble de fichiers d'aide, ils zipper et remplacer ce qui est dans le référentiel.

Alors, une partie de ma construction est décompressant ce fichier et en le plaçant dans la guerre. Facile à faire Ant, ne peut pas le faire dans Maven sauf si vous utilisez 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 plug-in complet soufflé.

Je peux voir ce que Maven est en train de faire, mais la théorie de la réalité avant obtenu. Ce que je trouve que Ivy et Ant peuvent faire la plupart de la vérification des dépendances Maven fait sans tous les problèmes de l'écriture et le maintien des poms.

Si vous n'êtes pas déjà en utilisant Maven, Ant essayez avec Ivy premier. Puis, quand, Maven 3 sort, essayer. Je me souviens du passage de Maven 1 à Maven 2. Ils étaient tout à fait incompatibles les uns avec les autres et tout ce que vous ont appris à utiliser Maven 1 était obsolète. Il serait stupide d'apprendre et de refaire vos projets Maven 2 pour trouver soudainement vous refaire tout pour Maven 3.

Answer 4

3.x Maven est déjà intégré dans IDEs (au moins sur NetBeans, consultez ce lien pour plus infomration). Vous pouvez jouer aujourd'hui avec 3.x maven simplement la construction d'un projet Maven avec NetBeans.

Une autre nouvelles intéressante est que Maven a plus de soutien « entreprise » à l'intégration dans des projets IDE EJB / WS (encore une fois, au moins sur NetBeans).

Je tiendrais Maven 2.x pour la production construit et jouer avec 3.x maven pour le développement.

Answer 5

Maven 2 et 3 ont tous deux travaillent parfaitement pour moi sur divers projets. Je suis actuellement en utilisant Maven 3 alpha 7 qui fonctionne très bien, en particulier en conjonction avec le plugin Eclipse Maven.

Maven intègre de façon transparente avec Ant - dans les deux sens. Dans mon projet actuel, nous invoquons Maven plusieurs fois Ant afin d'effectuer un test d'intégration complexe. De même, nous utilisons Ant via le plug-in AntRun Maven, et nous avons également écrit nos propres plugins Maven. Ceci, par ailleurs, est une question de minutes et se résume à écrire un Pojo annoté.

Maven reçoit beaucoup de critiques parce que de nombreux développeurs n'aiment pas les règles ou conventions. Tout simplement, personne ne vous oblige à utiliser Maven. Si vous voulez la liberté ultime - par tout moyen - réécrivez votre propre processus de construction pour chaque projet que vous rejoignez. Cependant, si vous voulez créer un logiciel plutôt que de réinventer la roue avec un processus de construction sur mesure sur chaque projet, allez Maven.

Answer 6

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 les 2/3 milieu de projets. Pour la très simple, fourmi est toujours ok. Pour le très complexe, un hybride de maven-2 et d'autres outils (comme antrun) devient inévitable.

Je ne sais pas pourquoi vous rencontrez des problèmes avec maven-2.

Il diffère de fourmi et Buildr en ce qu'elle est un outil pour décrire votre processus de construction, pas les scripts il. Complexe construit, avec les multiples parties dynamiques et dépendances imbriquées et / ou transitoires sont difficiles à construire, car ils sont difficiles à décrire.

Answer 7

Donner Lattice https://github.com/hackingspirit/Lattice essayer. Je suis l'auteur. Voici le scoop:

Dans Lattice construire des fichiers sont écrits pas en XML, mais dans le langage Python. Les tages avan- sont beaucoup meilleure lisibilité et puissant script de compilation impératif pris en charge par Python. Pour les projets multi-modules. Lattice utilise le tri topologique pour décider de l'ordre de construire chaque module. Il est également prévu que Lattice analysera la dépendance du module afin de déterminer comment la compilation du module peut être parallélisé. Le code source de treillis est extrêmement maigre, actuellement il se compose d'environ 500 lignes de code source Python.

Answer 8

Je pense que les gens se plaignent de Maven devraient passer un peu de temps d'instruction plug-ins disponibles. En réponse aux commentaires se plaindre que Maven est rigide et rend difficile d'utiliser la construction personnalisée logique / fournir un contrôle fin sur le processus de construction - Je recommande à la recherche dans le plug-in Ant pour Maven (il y a en fait plusieurs, mais voici un : http://maven.apache.org/plugins/maven-antrun-plugin). J'ai eu un grand succès avec la personnalisation de Maven construit au fil des années. Fondamentalement, il vous permet d'exécuter une commande Ant dans le cadre de la construction Maven, et vous pouvez faire quoi que ce soit à peu près avec Ant;)

Answer 9

Ant avec Ivy fait la même Maven de gestion de la dépendance ne (en fait, il utilise toute l'infrastructure de gestion des dépendances de Maven, y compris les mêmes référentiels d'URL), mais sans tout le désordre de configuration POM.

Ant avec Ivy pourrait être une façon de traiter les problèmes de dépendance pour les personnes qui ne veulent vraiment pas utiliser Maven. Il permet de résoudre 90% des choses que Maven était censé résoudre.