Discussion :

[fardon57]

Bonjour,

Ayant récemment obtenu un emploi, et étant développeur Java débutant, je dois faire de mon mieux pour intégrer un projet de taille assez conséquente.

Dans le projet, je suis assez surpris, car je vois des fichiers de configurations de toutes sortes : Maven, Ant, Ivy ...

Je ne suis pas du tout habitué à travailler sur des projets à taille d'entreprise, mais cela ne vous paraît-il pas bizarre cette pratique ? Je pensais qu'il s'agissait d'outils plutôt similaire.

[tchize_]

ant et maven2 ont peu de chose à faire ensemble. Maven 2 fait le plus gros du boulot de ant en plus facilement ocnfigurable. Certe il est possible d'appeler du ant depuis maven 2 mais c'est un solution d'aide à la migration, temporaire donc. Je connais pas Ivy, mais il vaut mieux se poser la quesiton sur le projet, à ceux qui travaillent dessus "lequel je dois utiliser". Si ca tombe c'est juste l'historique de tatonnements dans le choix d'un système de compilation

[Chatanga]

Maven permet de mettre en place un processus de build complet tandis qu'Ivy n'est qu'un outil pour gérer les dépendances au sein d'un projet. Même si ce dernier peut être utilisé seul, il est généralement utilisé pour étendre Ant. Donc, en pratique, c'est soit Maven, soit Ant/Ivy (ou encore Ant tout seul). Ca n'exclut pas pour autant un mélange des deux qui, s'il n'est pas idéal, peut être nécessaire pour intégrer des éléments pré-existant à un projet. Il existe d'ailleurs différentes passerelles entre les deux approches : Ivy comprend et peut générer des fichiers pom à la sauce Maven par exemple.

J'ajouterais pour finir que la mise en place d'un processus de build, et par extension d'intégration, n'est pas vraiment une tâche pour un débutant. Même si les outils ne sont pas forcément complexes à mettre en oeuvre, il y a pas mal de chausse-trappes à éviter et de choix à faire qui requiert une certaine expérience.

[fardon57]

Ok, merci pour ces informations.

Soyons clair, ils ne me demandent pas de construire les fichiers de build du projet. J'essai juste de comprendre un peu le projet, en lisant dans les centaines de classes et fichier de configuration que je trouve .

[tchize_]

tu pose la question à tes collègue et en 5 minutes t'as la réponse

[gifffftane]

Et bien moi j'utilise ant+maven et j'en suis trés content. Je ne suis pas du tout d'accord avec tchize_, je ne comprends d'ailleurs pas ce qu'il dit ? chez moi ant et maven ne font du tout le me boulot, gros ou pas. Maven s'occupe de toutes la partie projet, développoment, tandis que ant fait toute la partie déploiement, configuration utilisateur final.

J'ai aussi été tenté par yvi, mais je ne vois pas ce que cela apporterait en plus dans mon schema. Actuellement je suis plutot en train d'étudier ce que pourrait apporter groovy.

[fardon57]

tu pose la question à tes collègue et en 5 minutes t'as la réponse

Je viens d'arriver, je suis débutant, et j'ai pas envi de leur poser des questions toutes les 3 minutes ... Déjà que je les harcèle assez souvent ...

Merci quand même, visiblement ant et maven ne sont pas si incompatible que cela.

[tchize_]

personellement, je préfère avoir un nouveau collègue qui viens me poser 50 questions sur comment est gérer un ou plusieurs projet sur lequel il va travailler, qu'avoir un collègue qui arrive, essaie de comprendre tout seul et fini par passer une semaine à résoudre un problème qui a déjà été résolu ^^

[Akira]

Bonjour fardon57,

DPour moi Ant et Maven sont bel et bien redondant.
Je ne vois pas ce qu'il est impossible de faire avec Maven ou nécessiterait l'utilisation exclusive de Ant, hormis l'intégration d'un existant utilisant déjà Ant bien sur.

gifffftane, peux tu nous en dire un peu plus sur ton environnement s'il te plait?
Et le pourquoi du comment ce que tu fais avec Ant ne peut pas être fait en Maven?

Sinon je suis d'accord avec les autres sur le fait qu'il vaut largement mieux que tu pauses ta question à tes nouveaux collègues.
3 ou 4 questions toutes les 5 minutes au final cela ne fait pas un grosse différence que ça et puis tu es le newbe c'est normal

[lunatix]

il est parfois utile d'utiliser ant a partir de maven pour faire des choses comme copier des fichiers. (maven est d'une rigidité abominable, et faire tenir un vieux projet dedans n'est pas toujours evident)

inversement : on peut utiliser maven a partir de ant juste pour utiliser la gestion de dependances (pratique, un projet ant, mais avec l'utilisation de la gestion des jar de maven) : souvent utile avant une migration d'un projet de ant a maven

par contre, ant + maven + ivy... euh, la je vois pas de bonne raison

[tchize_]

Je ne vois pas ce qu'il est impossible de faire avec Maven ou nécessiterait l'utilisation exclusive de Ant, hormis l'intégration d'un existant utilisant déjà Ant bien sur.

Exactement, d'ailleur j'ai un projet qui a subit du maven1 -> maven2, résultat: un maven2 avec des vrai bout de ant dedans
Mais en pratique on pourrais avoir le même résultat soit en revoyant l'archi d'un projet importé, soit en remplacant le bout de ant par un plugin maven2 custom.

En pratique, on a jamasi eu le temps de migrer, un jour peut être :p

[gifffftane]

Je ne dis pas qu'il y a des choses qu'on pourrait faire avec Ant qu'on ne pourrait pas faire avec Maven (une telle pensée est si horrible ! ), je dis que j'utilise les deux dans les domaines où ils me paraissent le plus adaptés (donc cycle de dévelloppement pour maven, déploiement pour ant).

Ce n'est même pas une question de vieux projet que je n'aurais pas le temps de faire évoluer.

J'en suis arrivé à cette conclusion parce que :

• la complexité du pom.xml et associés explose lorsqu'on y fait entrer une problématique de déploiement,
• les termes de déploiement sont très spécifiques au... déploiement, voire à un utilisateur, quelque fois, même au poste d'un utilisateur particulier, et même les utilisateurs ont leurs propres phases et leur propre logique, et je préfère séparer le dévellopement du déploiement.
• vu la floraison de cas particuliers pour le déploiement, la doc d'usage des outils devient un point clef. Hors la doc de ant est un million de fois mieux que la doc de maven, et 10 millions mieux que les plugins de maven. Mon efficacté est donc de 2 à 3 fois supérieure avec ant, vu mes propres limites intellectuelles.

[lunatix]

et, juste par curiosité : personne n'a testé gradle ? http://www.gradle.org/userguide.html

[ReaM]

Je ne dis pas qu'il y a des choses qu'on pourrait faire avec Ant qu'on ne pourrait pas faire avec Maven (une telle pensée est si horrible ! ), je dis que j'utilise les deux dans les domaines où ils me paraissent le plus adaptés (donc cycle de dévelloppement pour maven, déploiement pour ant).

C'est assez étrange tout de même cette " séparation". Les différents plugins disponible sous maven permettent de réaliser un très large panel de build et deploy différent au cas par cas ( configuration / profils ) . Réellement dans un cas bien précis un script ant serait plus que nécessaire pour effectuer un / des process spécifiques et non réalisable à partir de maven , rien n'empêche le développeur d'utiliser ce script ant et de l'insérer dans le lifecycle de maven ( cfr doc ) .

Et bien moi j'utilise ant+maven et j'en suis trés content. Je ne suis pas du tout d'accord avec tchize_, je ne comprends d'ailleurs pas ce qu'il dit ? chez moi ant et maven ne font du tout le me boulot, gros ou pas. Maven s'occupe de toutes la partie projet, développoment, tandis que ant fait toute la partie déploiement, configuration utilisateur final.

Idem que mon commentaire précédent.

J'ai aussi été tenté par yvi, mais je ne vois pas ce que cela apporterait en plus dans mon schema. Actuellement je suis plutot en train d'étudier ce que pourrait apporter groovy.

Comme dit précédemment par un autre membre, Ivy n'a pas les mêmes scope que Maven.

vu la floraison de cas particuliers pour le déploiement, la doc d'usage des outils devient un point clef. Hors la doc de ant est un million de fois mieux que la doc de maven, et 10 millions mieux que les plugins de maven. Mon efficacté est donc de 2 à 3 fois supérieure avec ant, vu mes propres limites intellectuelles.

Il est vrai que concernant la documentation des plugins sous Maven , c'est la misère pour beaucoup. Il faut vraiment fouiller dans les entrailles du web pour trouver un temps soit peu de documentation avancée ( plus que sur les sites officielles ). Le soucis que je trouve dommage avec Maven & co , c'est justement ce manque de documentation standardisé et bien évidemment aucune DTD ou schema pour la validation .

[ZeRevo]

Autant utiliser maven1

Chez nous on utilise trop maven2, on y passe des jours et des jours à configurer des plugins, à valider des dépendances, ... Maven2 est très bugué et pas assez flexible, j'ai beaucoup d'exemples à donner. Dernièrement je suis tombé sur un plugin qui permettait de faire un mapping de répertoire et pas de possibilité de mapper un fichier. Des fois on passe 4 heures sur maven2 alors qu'en 10 minutes avec un script ça ferait exactement ce qu'on voudrait.

A côté de maven2, on utilise des langages de scripts (bash, perl, python) uniquement pour des tâches de dev, on laisse maven2 gérer tout le process de création de livrable.

[Patriarch24]

Je ne vois pas ce qu'il est impossible de faire avec Maven ou nécessiterait l'utilisation exclusive de Ant, hormis l'intégration d'un existant utilisant déjà Ant bien sur.

Il est possible qu'il existe des tâches ant pour des trucs bien précis, mais pas de plugins maven. Ceci est de moins en moins le cas, mais ça existe sûrement encore (je n'ai pas d'exemples sous la main).
Donc, maven + ant why not, tant que ant reste limité à antrun pour des utilisations exotiques pour lesquelles aucun plugin n'existe (ou existe mais n'est pas pratique). Par contre, maven+Ivy, mis à part une compatibilité pour un ancien projet ant+ivy, je vois pas l'intérêt...

[gifffftane]

C'est assez étrange tout de même cette " séparation". Les différents plugins disponible sous maven permettent de réaliser un très large panel de build et deploy différent au cas par cas ( configuration / profils ) . Réellement dans un cas bien précis un script ant serait plus que nécessaire pour effectuer un / des process spécifiques et non réalisable à partir de maven , rien n'empêche le développeur d'utiliser ce script ant et de l'insérer dans le lifecycle de maven ( cfr doc ) .

Pourquoi l'insérer dans lifecycle de Maven ?

J'ai bien compris, je sais, que Maven permet de TOUT faire ; je suis heureux que l'on reconnaisse que la doc infernale des plugins incompréhensibles puisse être un problème, c'est déjà ça qui va dans mon sens.

Surtout, je pense que les cycles de développement et les cycles de déploiement n'ont rien à voir, sauf peut-être dans les projets Java EE avec leur unique serveur ou presque. Non seulement cela justifie, mais encore il est mieux, plus pratique, d'avoir deux entités séparées.

[tchize_]

Il est possible qu'il existe des tâches ant pour des trucs bien précis, mais pas de plugins maven. Ceci est de moins en moins le cas, mais ça existe sûrement encore (je n'ai pas d'exemples sous la main).

Je peux t'en donner un en production: récuperer le contenu d'un webapp existante (ok, il existe le war overlay) dans le projet tout en
- fusionnant le fichier struts de cette application avec le fichier struts de ton application
- fusionnant d'autre fichiers xml
- patchant tous les liens dans les jsp pour prendre en compte la mise en sous répertoire des jsp de la webapp plutot que sa mise en racine
- ne pas récupérer pas le reste du WEB-INF

La méthode propre aurait été de faire un plugin maven custom plutot qu'un script ant. Mais le script ant existait déjà

Pour ce qui est des deploy au 'cas par cas', je préfère l'option de créer un projet par cible de deploy, projet minuscule qui dépend d'un master project indépendant du deploy et qui ne fait qu'ajouter les règle de configuration. Ainsi on garde une des règles de bon usage de maven: reproductibilité d'un build.

[Mad666]

J'ai bien compris, je sais, que Maven permet de TOUT faire ; je suis heureux que l'on reconnaisse que la doc infernale des plugins incompréhensibles puisse être un problème, c'est déjà ça qui va dans mon sens.

Bonjour bonjour,

Dire que Maven permette de TOUT faire me paraît un peu grossier. C'est peut-être vrai maintenant mais il y a moins d'un an, ça ne l'était pas.

Je n'ai, par exemple, pas trouvé comment faire de la copie de fichiers ou du remplacement de chaîne de caractère dans un fichier sans passer par un plugin Ant.
Je n'ai pas non plus trouvé comment limiter les dépendances communes à différents projets Maven du projet sur lequel je travaille à une seule version identifiée et imposée (avec la version 2.0.8 de Maven, il me semble qu'on peut le faire maintenant).

Pour moi, pour l'instant, Ant et Maven sont juste indiscociables je pense.

[tchize_]

Bonjour bonjour,

Dire que Maven permette de TOUT faire me paraît un peu grossier. C'est peut-être vrai maintenant mais il y a moins d'un an, ça ne l'était pas.

On va dire que maven permet de faire beaucoup de chose, à condition de les faire à la manière maven

Je n'ai, par exemple, pas trouvé comment faire de la copie de fichiers ou du remplacement de chaîne de caractère dans un fichier sans passer par un plugin Ant.

build -> ressources -> filter=true

Je n'ai pas non plus trouvé comment limiter les dépendances communes à différents projets Maven du projet sur lequel je travaille à une seule version identifiée et imposée (avec la version 2.0.8 de Maven, il me semble qu'on peut le faire maintenant).

Ca fait longtemps qu'on peux définir les "managed dependencies" dans le projet parent. Il suffit que tous tes projets héritent du même parent imposant les versions.