dépend de la fourmi vs antcall
Lors de la définition des étapes de construction séquentielles, j'utilise l'attribut depends de l'élément target. J'ai récemment vu un fichier ant, où la séquence de construction a été définie par des éléments antcall à l'intérieur des cibles. Pour illustrer :
<target name="a" depends="b">
...</target>
contre
<target name="a">
<antcall target="b"/>
...</target>
Y a-t-il une réelle différence entre les deux approches? Est-ce que l'un d'eux est préférable?
La principale différence entre les deux approches est que les cibles dans depends sont toujours exécutées, tandis que les cibles dans antcall ne sont exécutées que si la cible contenant l'est.
Un exemple de clarification:
<target name="a" depends="b" if="some.flag">
</target>
Ici, b sera toujours exécuté, tandis que a ne sera exécuté que si some.flag est défini.
<target name="a" if="some.flag">
<antcall target="b" />
</target>
Ici, b ne sera exécuté que si a l'est, c'est-à-dire si some.flag est défini.
La plus grande différence est que Ant s'assurera que les dépendances déclarées via depends sont appelées au plus une fois. Par exemple:
<target name="a" />
<target name="b" depends="a" />
<target name="c" depends="a" />
<target name="d" depends="b, c" />
Si j'appelle la cible d, b et c sont appelés. Cependant, a n'est appelé qu'une seule fois (même si b et c en dépendent).
Supposons maintenant que nous décidions d'utiliser antcall au lieu de dépend pour la cible d:
<target name="d">
<antcall target="b" />
<antcall target="c" />
</target>
L'appel à la cible d appellera désormais les cibles b et c; cependant, la cible a sera appelée deux fois, une fois pour b, puis de nouveau pour c.
En d'autres termes, antcall contourne les règles de dépendance normales qui sont la pierre angulaire d'Ant.
Je ne pense pas que antcall devrait être utilisé comme substitut aux dépendances normales de type Ant; c'est à cela que sert depends. Alors, quand l'utiliseriez-vous? La tâche antcall vous permet de contrôler quelles propriétés et références sont définies (c'est pourquoi un nouvel environnement Ant est créé - et pourquoi il est si lent) afin qu'il puisse être utilisé pour créer des variantes de la même chose; par exemple, peut-être deux bocaux, un avec et un sans symboles de débogage.
Cependant, une utilisation excessive de antcall crée des scripts de génération lents, fragiles et difficiles à maintenir. Considérez-le comme le goto de Ant - c'est mal. La plupart des scripts de construction bien écrits n'en ont tout simplement pas besoin, sauf dans des cas inhabituels.
Antcall est relativement rarement utilisé, car:
Les cibles appelées sont exécutées dans un nouveau projet; sachez que cela signifie que les propriétés, références, etc. définies par les cibles appelées ne persisteront pas dans le projet appelant.
En d'autres termes, antcall est un tout nouveau processus Ant isolé en cours d'exécution.
antcall est le GOTO de la fourmi. C'est terrible. C'est un excellent moyen de faire d'un nid de rats une cruauté impossible à entretenir. À côté de ant-contrib, c'est la meilleure façon de sentir un fichier de fourmi trop compliqué à entretenir. (même un bon antifile est rude)
Si vos dépendances sont définies correctement, vous devriez pouvoir exécuter n'importe quelle cible jusqu'à ce point avec succès, contrairement au modèle antcall.
Une autre raison pour laquelle personne n'a abordé est vizant, la capacité de générer un graphique de vos dépendances cibles est assez douce si c'est une construction compliquée. Si vous utilisez un appel, vous êtes foutu.
Je souhaite que @Vladimir Dyuzhev ait raison de dire que l'antcall est rarement utilisé - je suis allé dans beaucoup de magasins où c'est la norme.
<target name="a" depends="b"> ...</target>
Cela signifie avant d'exécuter une instruction ou une balise de la cible a, ANT s'assure que la cible b est exécutée avec succès
Et vous pouvez appeler n'importe quelle cible en utilisant antcall après l'exécution de certaines instructions ou balises à partir de l'appel de la cible.