Remi Koutcherawy <[EMAIL PROTECTED]> writes:
| - syntaxe XML complexe, difficile � lire et � debugger, (perso j'ai
| du mal � lire le XML dans le texte)
L'avantage du XML est qu'il auto-document�, donc une t�che comme:
<javac srcdir="src"
destdir="tmp"/>
Me semble assez claire.
| - difficilement extensible (il faut d�piauter la doc et coder en
| java)
Ca tombe bien, c'est un outil pour d�veloppeurs Java.
| - il lance tout dans un seul process (une MVJ) donc si l'outil java
| appelle System.exit() t'es mal !
Quel outil Java ? Lorsqu'on lance un programme dans Ant, il est
possible de lui demander de le faire dans une autre VM (attribut fork
de la t�che java).
| - non standard, il n'est pas livr� de base avec Solaris ou
| Microsoft.
Java non plus. D'autre part, il est clairement en train de devenir un
standard (il est maintenant livr� avec des outils Sun comme le pack
XML si ma m�moire est bonne).
| - non portable car d�clin� en multiples versions par les outils qui
| l'int�grent (chacun y ajoute ses extensions, en modifiant le
| code).
D'o� sort cette info, peux tu donner des exemples concrets ? Il ne
faut pas confondre extension et modification du code. Il est possible
d'ajouter ses propres t�che, mais ce n'est pas pour autant que le
projet n'est plus portable.
| Oserais-je rajouter qu'apr�s avoir lu la doc et fait tourner les
| exemples de base, j'ai gal�r� 3 jours pour �crire mon build.xml ?
Franchement, je pense qu'avec une bonne doc d'introduction, c'est
l'affaire d'une heure ou deux.
| En r�sum�, si t'es un pro infatu� il faut que tu maitrises Ant,
| sinon make fait largement l'affaire.
Make est tr�s bien, mais quasiment tous les projets Open Source (et
les autres probablement, mais c'est assez inv�rifiable) passent sous
Ant. Il y a probablement de tr�s bonnes raisons...
--
Michel CASABIANCA
