Une tentative d’explication concernant mon choix d’utiliser Ant+Ivy plutôt que Maven… (et ça ne va pas être simple)
De quoi parle t’on là au fait?
- Apache Ant est un outil de “build”. Il permet d’automatiser des tâches récurrentes (compilation, packaging, déploiement, etc.).
- Apache Ivy est un outil de gestion et de résolution des dépendances inter-librairies. C’est un sous-projet de Ant.
- Apache Maven est un outil de “gestion de projet”. Il permet en effet de gérer les dépendances, le build, le reporting, la documentation, etc. depuis un élément central de configuration.
Quels sont les besoins pour NooCodeCommit?
Très honnêtement, voilà ce que j’attends de ce genre d’outil; il faut qu’il soit :
- Simple
- Non-Intrusif
- Facilement adaptable
- Efficace
Comme tout le monde j’ai été séduit par Maven. Ben oui quoi un truc qui te fais tout sans que tu n’ai rien à faire, moi je dis Banco! Sauf qu’il n’en n’est rien. Maven est devenu au fil des années un mastodonte, qui sait tout faire … tant qu’on sait le configurer. Et c’est là que le bât blesse. En effet, on a vite fait de passer plus de temps à s’occuper de la configuration de Maven que de réellement s’occuper de son projet.
Et moi dans un premier temps je n’ai réellement besoin que de la gestion des dépendances. Donc j’ai préféré revenir à mes vieux scripts Ant et de les coupler à Ivy.
Ivy est une réponse simple et élégante à la problématique de gestion des dépendances, qui de plus, est capable de traiter avec les repository de Maven. Nous ne sommes donc pas trop loin du monde de Maven qui est quand même bien positionné.
« Ouai mais d’avoir des scripts Ant partout c’est relou à maintenir… »
La force de Maven est de proposer un cadre standardisé en réponse à des problèmes récurrents, rencontrés depuis des années dans notre métier. Certes, mais d’un certain point de vue, chaque projet est différent.
D’un point de vue très personnel, j’ai préféré revenir à mes scripts Ant, qui au fur et à mesure ont été adapté et peaufiné pour répondre à mes besoins.
Pour ce qui est de la maintenabilité, et bien certes c’est peut être un peu plus lourd à gérer (quoique les fichiers .pom de Maven peuvent vite devenir illisible aussi…), enfin ça demande juste de l’organisation, mais une fois que les choses sont bien faite, ça roule tout seul.
Et puis Ivy est à l’origine un projet français, fait par les gens de Jayasoft à l’époque. Aujourd’hui un des acteurs très actif sur ce projet est Xavier Hanin, une personne très ouverte et disponible. Il est aussi le créateur de l’outil d’intégration continue Xooctory et un ardent défenseur de la cause Wicket…
Je vois que je ne suis pas le seul à avoir une dent contre maven…
http://www.infoq.com/news/2008/01/maven-debate
http://tapestryjava.blogspot.com/2007/11/maven-wont-get-fooled-again.html
http://java.dzone.com/blogs/mrjohnsmart/2008/01/31/maven-and-ant-eternal-debate
Le n@@bs de base que je suis acquiesce humblement :
Ca pour etre relou a configurer correctement … il l’est ^^
Et c’est clair que ca fait tellement de choses qu’au final on arrive pas a en faire grand chose ou alors on y passe du temps ce qui est a l’opposé du but premier.
Encore un article autour de cette question : http://www.leshazlewood.com/?p=44
Ant, Ivy, même combat: à trop vouloir faire spécifique, on en vient à ne plus réussir à maintenir ses scripts. Je travaille sur une plateforme qui rassemble plusieurs dizaine de projet et la build était très difficile à maintenir, justement parce que grâce aux liberté qu’offrait les scripts, les projets était tous différents (même sensiblement) dans leur manière d’être buildé.
Maven est notre solution car justement elle impose un cadre et des contraintes. On peut contourner les contraintes, au prix de hack de conf Maven. Mais Maven est tel qu’il encourage de suivre son cadre. Et finalement c’est mieux comme celà. De plus, les dépendances sont facilement gérables, notamment par le concept de range de version. Enfin, s’il faut vraiment débrailler en Ant (et oui car il présente ses avantages), Maven propose un plugin pour exécuter un script Ant.
Donc +1 à Maven.
Je suis d’accord avec bzion. Maven n’est PAS qu’un outil de gestion de projet. Il a également le mérite d’offrir un cadre objectif et CONVENTIONNEL, ce qu’Ant n’offre pas. Il est également prouvé par expérience de nombreux architectes qu’Ant est un enfer pour la productivité d’une EQUIPE (avec environnements variés, machines différentes, pratiques différentes) alors que Maven est une seule fois dans un cycle projet, lors de sa conception. C’est à dire qu’ensuite, généralement, une poignée de développeurs manipulent les fichiers propres à leurs besoins. De plus, l’héritage des POM offert par Maven permet une flexibilité du besoin et un découplage fort ne rendant finalement pas si complexe que ça sa configuration. En d’autres termes, tous les POM ne sont pas nécessaires en terme de visibilité, seules les parties intéressantes (et généralement spécifiques à un besoin, donc organisées) le sont. Chacun possède SA vue du projet.
Pour finir, Maven est un outil DÉCLARATIF, contrairement à Ant qui est un outil PROCÉDURAL. On ne désire pas, dans un cycle projet, définir les tâches qui vont constituer son cycle. On préférera généralement une généricité du cycle de projet, ce qu’offre Maven. Je répondrai donc à la phrase “Tous les projets sont différents”: oui, en un sens, mais le cadre conventionnel offert par Maven est commun à TOUS LES PROJETS. Et puis, si les choix des conventions ne plaisent pas, c’est configurable. Cependant, on préconise le respect des conventions Maven pour éviter de plonger dans un un sentiment de rébellion inutile, finalement.