Discussion :

[gperlade]

Bonjour,

Je m'intéresses actuellement à l'outil de build EasyAnt. J'ai put trouver ses différents avantages sur le site officiel par exemple, mais je n'ai trouvé aucun inconvénient.

Je viens donc vers vous, pour savoir si certaines personnes on déjà put le tester et on put remarquer ses différents inconvénients.

Grégory

[gboissinot]

EasyAnt fait partie des très bons challenger au système de build Maven.

EasyAnt conserve la séparation des responsabilités comme dans Maven, contrairement à d'autres outils comme Gradle.
Cette séparation des responsabilités est discutable et peut provoquer une certaine lourdeur dans certaines situations.

Aujourd'hui, je dirais que les défauts de EasyAnt sont son manque de maturité. Mais cela est normal car il manque de notoriété et donc d'utilisateurs pour donner les bons et les mauvais feedback des différentes parties de EasyAnt. Et ainsi, il te manquera surement certaines features que les autres outils auront. Cela peut t'être gênant ou pas en fonction de tes besoins.

Mais plus généralement, à chaque outil son contexte d'utilisation et cela vaut pour les systèmes de build.

Donc, pour quels usages envisage-tu EasyAnt?
- Monde Java/JEE?
- Beaucoup de customisation de la chaine de build?
- Utilisé la puissance de Ivy?
- Gestion multi module et Ivy?
- Autres langage?

[gperlade]

Tout d'abord merci de ta réponse.

En fait mon but est d'effectuer une comparaison des outils de build, un peu comme le document que vous avez réalisé avec M Linsolas. Je doit faire cette comparaison dans le cadre d'un stage en entreprise.

L'utilisation final des outils de build évalué sera uniquement le monde java/JEE.
Après le reste dépendra des projets spécifiques à l'entreprise.

Je suis actuellement dans la phase d'étude préalable, je choisit les outils de build qui seront testés durant mon stage. Je fait donc un premier rapport sur le choix des outils de build avec "en gros" les avantages et inconvénients de chacun des outils, afin de me faire une idée de leurs potentiel/possibilités.

J'ai déjà pu noter le manque de notoriété de EasyAnt, puisque justement je ne pouvais trouver aucun feedback(bon ou mauvais). J'ai aussi put noter cela dans ce document sur la CitConf 2009(toujours de vous et M Linsolas)

As-tu déjà eut l'occasion de tester cet outil? Peut être ai-je enfin trouvé un premier feedback

[jboudart]

Bonjour,

En tant que leader du projet d'EasyAnt, je me permet d'intervenir pour apporter quelques éléments.

Tout d'abord, comme l'a souligné Grégory Boissinot, EasyAnt manque aujourd'hui de notoriété.

Ceci est essentiellement dû à notre piètre communication (rire), mais aussi à un historique lié à des valeurs qui font l'essence même d'EasyAnt:

• ne pas réinventé la roue
• être "Open Source" (comme ces concurrents) mais au delà du projet EasyAnt, faire évoluer les outils sur lesquels on s'appuie.

Petit retour sur l'historique :
Après une petite étude (et guidé par des convictions personnels) nous avons choisis de nous appuyés sur deux outils éprouvés, Ant+Ivy.
Très vite (dès le départ en fait) nous avons voulue faire évoluer des choses dans Ant ainsi que dans Ivy.

Nous avons donc tenté de pousser au maximum ces sujets afin qu'il puisse faire partie intégrante des versions officiels.

Parmi ces évolutions on peut citer :

• la notion de "phase"
  Une sorte d'IOC dans ant, en somme une autre manière de réaliser un build générique et extensible. Cette modification à été intégré sous le nom de extentionOf dans ant 1.8
• la notion d'include
  Cette fonctionnalité offre de nouvelles stratégies pour importer des scripts ant avec la possibilité d'alliasé les targets pour éviter les conflits de noms. Cette modification à été intégré dans ant 1.8
• la notion de parent module
  Pouvoir "hériter" de méta donné d'un module parent dans ivy.
  Cette modification n'est toujours pas intégrée dans ivy, car cette fonctionnalité n'est pas entièrement terminer. Elle devrait être finalisée pour le prochain release.

Ces sujets faisant partie de la base d'EasyAnt, il était primordiale d'arriver à statuer sur le fait de les intégré dans EasyAnt ou dans Ant/Ivy.
La communication à donc été restreinte dans les premières versions à la mailing list de dev d'Ant.

Aujourd'hui :
Suite à la récente publication de ant 1.8, ainsi qu’aux nombreuses simplifications apportées sur notre solution, nous avons sortie la version 0.7 qui apporte son lot de nouveautés.
Je pense qu'aujourd'hui nous avons atteint un stade de maturité suffisant pour propager notre communication au reste du monde, et qu'aujourd'hui le projet à besoin de feedback (bon ou mauvais) pour évoluer.

A titre informatif, un plugin eclipse est en cours de réalisation (sous le nom de easyant4e) il devrait être rapidement disponible en version alpha.
Ce plugin sera une extension d'IvyDE et proposera donc :

• la gestion de classpath dynamique (à l'image de ce que fait IvyDE)
• la notion de project resolver (à l'image de ce que fait IvyDE)
• la complétion sur tous les tags d'easyant
• la complétion sur les valeurs des tags d'easyant :
  
  • complétion sur les plugins (quels sont les plugins disponibles? à quoi servent-ils?)
  • complétion sur les properties (quels sont les properties que je peux surcharger? a quoi servent elle? quel sont leurs valeurs par défaut?)

Je reste à ta disposition si tu a besoins de plus amples informations.

Je t'invite a lire l'article de Stefan Bodewig (un des lead developer de Ant) sur la sortie de Ant 1.8 ou tu pourra avoir de plus ample information concernant les "extensionOf" : http://stefan.samaflost.de/blog/en/A...ew_in_180.html.

[gperlade]

bonjour,

Merci de ces précisions, qui plus est le fait qu'elles viennent de la part du leader du projet est encore plus appréciable.
J'ai bien lu le document que vous m'avez conseillé mais je doit admettre que je ne saisi pas toutes les informations(je n'ai que très peu d'expérience sur les outils de build, mais ça s'améliore de jours en jours, de plus je n'ai pas eu à faire à des cas particuliers pour le moment).

Bien que je me doute qu'il ne soit pas dans votre intérêts de dévoiler les "faiblesses" d'EasyAnt, peut-être pourriez vous me dévoiler certains de ses désavantages (Ant par exemple ne gère pas les dépendances transitives, EasyAnt le fait lui à l'aide d'Ivy).

Le plugin easyant4e dont vous parlez m'intéresse, car dans les critères d'évaluation que j'ai définit il y a une partie consacré à l'intégration avec les IDE.

Merci encore
Grégory

[jboudart]

Selon moi, le majeur problème est celui évoqué précédemment : le manque de notoriété / manque de retour.

Aujourd'hui il est certain qu'EasyAnt ne couvre pas l'intégralité des fonctionnalités fournis par ces concurrents.
Nous nous sommes focalisés sur les "Use Case" les plus simples et les plus standards. Maintenant, il nous faut des retours pour améliorer notre solution.

On pourrait citer d'autres "inconvénients" de la solution comme le fait d'être en XML.

Aujourd'hui beaucoup de personnes deviennent allergique au XML, considèrent que c'est un langage pour les machines pas intuitif, etc... Ils préfèrent en général utiliser des langages maitrisables qui leur offrent plus de souplesse (Groovy par exemple).

Mon avis sur la question?
L'avantage du XML c'est le coté structurant. Le XML permet de cadré "l'utilisateur" dans un contexte bornés ou il ne pourra utiliser que certains <tag>. Le document peut ensuite être validé permettant de guider l'utilisateur s’il n'utilise pas correctement les <tag>s. De plus, avec un éditeur évolué, on peut bénéficier de la complétion. Est il possible d'avoir un tel niveau de complétion avec Groovy (ou autre)?

Je pense qu'il faut distinguer deux choses. Le descripteur de module (ce qui décrit notre projet) et les plugins (les composants utilisés pour fournir des étapes dans le cycle de vie de nos projets).

Le descripteur de module :
L'objectif d'un descripteur de module est de "décrire" son projet :

• décrire les dépendances
• décrire la structure des répertoires
• décrire le type de projets etc...
• les plugins qu'on veut utiliser

En aucun cas (dans EasyAnt), nous souhaitons offrir la possibilité à un utilisateur de pouvoir utiliser toute la puissance d'un langage pour décrire son projet.
Offrir la puissance d'un langage dans le descripteur de module apporterais certes une énorme flexibilité, mais pourrais inciter à écrire plus facilement des usines à gaz et devenir vite inmaintenable.
On a souvent reproché a Ant (par le passé) de ne pas être assez structurant. Pourtant dans ant nous étions bornés à quelques tags XML.
Dans quel état serait nos projets si nous avions eu toutes la puissance d'un langage dans les mains pour gérer le cycle de vie de nos projets?

Selon nous XML semble bien adapter pour ce cas d'utilisation.


Les plugins :
Les plugins contiennent la logique pour répondre à une problématique donnée :

• compiler les sources java
• construire un jar/ear/war
• lancer des tests unitaires
• etc...

Aujourd'hui vu que nous nous appuyons sur Ant, nos plugins sont effectivement en XML. Ceci peut effectivement être une limite. L'utilisation de structure conditionnelle ou de boucle (if/else/for etc...) est assez limitée dans Ant. Et si le but est d'écrire un plugin générique et un peu complexe on pourrait rencontrer quelques difficultés.

Ant sans XML?
Spoilons un peu, le langage natif de Ant est en effet XML. Néanmoins les apis Java certes peut documenter permette de faire beaucoup plus de choses.
Il existe aujourd'hui divers projets qui permettent d'écrire nos "script" ant dans d'autre langage dans d'autre langage (Java/Groovy).
Par exemple :

• Ant en Java : http://stefan.samaflost.de/blog/en/A...javafront.html
• Ant en groovy : https://svn.apache.org/repos/asf/ant...x/groovyfront/

Ceci signifie donc qu'il est possible d'écrire des choses beaucoup plus complexe qu'avec du XML tout en restant utilisable par Ant.

Et le rapport avec EasyAnt?
Aujourd'hui nos "plugins" sont de vrais scripts ant (XML).
Il est prévu avant la version 1.0 d'easyant de pouvoir supporter d'autres langage (Java et probablement groovy, peut être d'autre) basé sur les implémentations mentionnées ci-dessus.
Ainsi lorsque qu'il sera nécessaire d'écrire son propre plugins, nous aurons le choix du langage pour écrire notre plugins.

[gperlade]

Merci de toute ces précisions.

Une fois que j'aurais testé EasyAnt je ferai un retour sur mon expérience(si humble soit-il). Je ne pourrais par contre pas tester toutes les fonctionnalités/particularité/etc. offerte par cet outil(ou les autres), mais je donnerai mon avis en tout cas.