Al definir pasos de compilación secuencial utilizo el atributo depends del elemento target. Recientemente he visto un archivo ant, donde la secuencia de compilación se definió por antcall elementos dentro de los objetivos. Para ilustrar:ant depende contra anticaída
<target name="a" depends="b">
...</target>
vs
<target name="a">
<antcall target="b"/>
...</target>
¿Hay una diferencia real entre los dos enfoques? Es uno de ellos preferible?
La principal diferencia entre ambos enfoques es que los objetivos en dependsson siempre ejecutados, mientras que los objetivos en antcall sólo se ejecutan si el objetivo es que contiene.
Un ejemplo clarificador:
<target name="a" depends="b" if="some.flag">
</target>
Aquí, b siempre será ejecutado, mientras que a será ejecutada sólo si se define some.flag.
<target name="a" if="some.flag">
<antcall target="b" />
</target>
Aquí, b solamente se ejecutará si a es decir, es decir, si se define some.flag.
Para agregar a esto, un objetivo se puede invocar varias veces con '
'depends' no se ejecutan ** siempre **. Un ejemplo es cuando se importa la secuencia de comandos horm desde gradle y se llama al objetivo principal desde gradle. En ese caso, el '' depende '' del objetivo principal no se ejecuta. –
Antcall es relativamente rara vez se utiliza, debido a que:
El objetivo (s) llamada se ejecutan en un nuevo proyecto ; Tenga en cuenta que esto significa propiedades, referencias, etc. establecido por llamado objetivos no persistirá al proyecto que realiza la llamada.
En otras palabras, antcall es un proceso totalmente nuevo aislado de Ant.
¿Esto también significa que las tareas anticaídas se ejecutan en paralelo? – kostja
No, antcall es sincrónico, como cualquier otra tarea. Hay una tarea
Cuando miro la documentación, veo dicha cita: "Por defecto, todas las propiedades del proyecto actual estarán disponibles en el nuevo proyecto. Alternativamente, puede establecer el atributo inheritAll en propiedades falsas y solo" usuario "(es decir, , aquellos pasados en la línea de comando) se pasarán al nuevo proyecto ". https://ant.apache.org/manual/Tasks/antcall.html. Esto es algo diferente de lo que dijiste. – Kamil
<target name="a" depends="b"> ...</target>
Esto significa beforeing ejecutar cualquier declaración o cualquier etiqueta de la meta a, ANT hace que sea seguro de que el objetivo b se ejecuta con éxito
Y usted puede llamar a cualquier destino mediante antcall después de algunas declaraciones o etiquetas es ejecutado desde llamando al objetivo
La mayor diferencia es que Ant se asegurará de que las dependencias declaradas a través de depends se llamen como máximo una vez. Por ejemplo:
<target name="a" />
<target name="b" depends="a" />
<target name="c" depends="a" />
<target name="d" depends="b, c" />
Si llamo objetivo d, bc y son llamados. Sin embargo, a solo se llama una vez (aunque ambos b y c dependen de ello).
Ahora supongamos que decidimos utilizar antcall lugar de destino depende de d:
<target name="d">
<antcall target="b" />
<antcall target="c" />
</target>
la designación de objetivos d ahora llamar a los objetivos y bc; sin embargo, se llamará al objetivo a dos veces, una para b y nuevamente para c.
En otras palabras, antcall elude las reglas de dependencia normales que son la piedra angular de Ant.
No creo que antcall se deba usar como un sustituto de las dependencias normales similares a Ant; para eso es depends. Entonces, ¿cuándo lo usarías? La tarea antcall le permite controlar qué propiedades y referencias se definen (razón por la cual se crea un nuevo entorno Ant y por qué es tan lento) para que pueda usarse para crear variantes de la misma cosa; por ejemplo, tal vez dos jarras, una con y otra sin símbolos de depuración.
La sobreutilización de antcall, sin embargo, crea secuencias de comandos de construcción lentas, frágiles y difíciles de mantener. Piense en ello como el goto de Ant - es malvado. La mayoría de los scripts de compilación bien escritos simplemente no lo necesitan excepto en casos inusuales.
¡Buen punto en "una vez y solo una vez"! Upvoted, por supuesto. –
Gracias, un detalle muy relevante – kostja
Solía usar antcall para configurar objetivos "parametrizados" que podía volver a usar, pero el macrodef agregado en 1.6 hace mucho tiempo hace que sea mucho mejor para este tipo de reutilizar. – Scott
antcall es el GOTO de hormiga. Es terrible. Es una gran manera de hacer un nido de ratas de un cruto inmanejable. Junto a ant-contrib, es la mejor manera de oler un archivo de hormiga difícil de mantener y demasiado complicado. (incluso un buen archivo de antigüedades es áspero)
Si sus dependencias están configuradas correctamente, usted debe poder ejecutar cualquier objetivo hasta ese punto con éxito, a diferencia del patrón de advertencia.
Otra razón por la que nadie ha tocado es visualmente, la capacidad de generar un gráfico de las dependencias de destino es muy agradable si se trata de una compilación complicada. Si usas antcall estás jodido.
Ojalá @Vladimir Dyuzhev estuviera en lo cierto al decir que rara vez se usa la antitarea, he estado en muchas tiendas donde es la norma.
vizant es genial, no sabía nada de esa herramienta, gracias – kostja
Anticall es una forma muy conveniente de extraer pasos repetitivos en una tarea separada y llamarla con diferentes parámetros. Si vizant no puede admitir avisos anticuados, este es un problema de visado, por desgracia. –
no. categóricamente no. el flujo de programa en la hormiga se hace con dependencias, llamada anticapital en el mismo build.xml es una abominación. Si necesita hacer algo similar muchas veces con diferentes entradas, siempre estará mejor utilizando una macro de hormiga. – thekbb
El único momento en que ** antcall ** es necesario es cuando está migrando de hormiga a gradle, y llamando a objetivos antis de gradle. En ese caso, su compilación de hormigas no puede ejecutar los objetivos ** depende **, en cuyo caso deberá usar 'antcall'. –