Chiamata di destinazione della formica

Question

Vorrei chiamare il backup di destinazione. Solo se la condizione è vera.

<condition property="directory.found.yes"> 
<equals arg1="${directory.found}" arg2="true"/> 
</condition> 

<antcall target="update.backup"/> 

C'è un modo per farlo.

Answer 1

È possibile effettuare le seguenti

Nella altro obiettivo:

<antcall target="update.back"> 
    <param name="ok" value="${directory.found.yes}"/> 
</antcall> 

E nel target update.backup:

<target name="update.backup" if="ok"> 

Ma penso che si può anche effettuare le seguenti operazioni utilizzando if statement da ant-contrib:

<if> 
    <equals arg1="${directory.found.yes}" arg2="true" /> 
    <then> 
      <antcall target="update.back" /> 
    </then>  
</if> 

Answer 2

Invece di <antcall/>, effettuare le seguenti operazioni:

Immagina che stai chiamando bersaglio foo, e si vuole fare un backup prima, ma solo se esiste tale condizione:

<target name="foo" 
    depends="update.backup"> 
    <..../> 
</target> 

<target name="update.backup.test"> 
    <condition property="directory.found.yes"> 
     <equals arg1="${directory.found}" arg2="true"/> 
    </condition> 
</target> 

<target name="update.backup" 
    depends="update.backup.test" 
    if="directory.found.yes"> 
    <.../> 
</target> 

Il problema con <antcall/> è che viene utilizzato quando la matrice delle dipendenze Ant viene utilizzata e viene utilizzata per forzare un'attività prima che un'altra attività venga completata. Quando viene realmente abusato, finirai per chiamare più volte lo stesso compito. Avevo qui un progetto che letteralmente chiamava ogni obiettivo tra 10 e 14 volte, e c'erano oltre due dozzine di obiettivi. Ho riscritto l'intera build con <antcall/> e utilizzando la configurazione delle dipendenze true, il tempo di compilazione è stato ridotto del 75%.

Dalla mia esperienza, il 90% di <antcall/> è dovuto alla scarsa gestione delle dipendenze di destinazione.

Supponiamo di voler eseguire l'obiettivo foo. (L'obiettivo che l'utente desidera eseguire realmente) e prima che venga chiamato foo, si desidera eseguire il backup, ma solo se la directory esiste effettivamente.

In quanto sopra, viene chiamato foo. Dipende dallo update.backaup. Viene chiamato l'obiettivo update.backup, ma dipende da update.backup.test che verificherà se la directory esiste effettivamente.

Se la directory esiste, la clausola è vera e l'attività verrà effettivamente eseguita. Altrimenti, se la directory non è presente, non verrà eseguita.

Nota che update.backup primi inviti a tutte le dipendenze prima esso verifica se la proprietà sul parametro if o unless per l'entità target sia selezionata. Ciò consente all'obiettivo di chiamare un test prima che tenti di eseguire.

Questo non è un mero effetto collaterale, ma costruito nella progettazione di Ant.In realtà, il manuale Ant sugli obiettivi] (http://ant.apache.org/manual/targets.html) dà espressamente un esempio molto simile:

<target name="myTarget" depends="myTarget.check" if="myTarget.run"> 
    <echo>Files foo.txt and bar.txt are present.</echo> 
</target> 

<target name="myTarget.check"> 
    <condition property="myTarget.run"> 
     <and> 
      <available file="foo.txt"/> 
      <available file="bar.txt"/> 
     </and> 
    </condition> 
</target> 

E afferma:

Importante: il se e meno attributi solo attivare o disattivare il bersaglio a cui sono attaccati. Non controllano se gli obiettivi che un obiettivo condizionale dipende o meno vengono eseguiti. In realtà, non vengono nemmeno valutati fino a quando l'obiettivo sta per essere eseguito e tutti i suoi predecessori sono già stati eseguiti.