2010-01-16 15 views
6

Il mio obiettivo è avere il mio script di formica di build costruire un file di guerra e includere i vasi da cui ivy sa che questo progetto dipende. Il codice di meglio che ho potuto venire con in questo momento è la seguenteCome usare ivy per costruire una guerra senza copiare i jar in una directory lib

<mkdir dir="dist/lib"/> 
<ivy:retrieve pattern="dist/lib/[artifact].[ext]" sync="true"/> 
<war destfile="dist/${ivy.module}.war" basedir="build" includes="**/*.class" 
    webxml="${war.webxml}"> 
    <fileset dir="${war.web}"/> 
    <lib dir="dist/lib"/> 
</war> 

Il problema con questo codice è copia i vasetti due volte. Una volta nella mia directory dist/lib e di nuovo nella guerra quando viene creata. Funziona ma non riesco a scuotere la sensazione che ci sia un modo migliore.

Quello che vorrei fare è qualcosa di più simile al seguente

<ivy:cachepath pathid="locpathref.classpath"/> 
<war destfile="dist/${ivy.module}.war" basedir="build" includes="**/*.class" 
    webxml="${war.webxml}"> 
    <fileset dir="${war.web}"/> 
    <lib refid="locpathref.classpath"/> 
</war> 

Il problema è che il tag lib non prende in un refid di qualsiasi tipo. Qualche idea o sono bloccato con un set extra di copie di file?

+0

Usa quindi il tag lib funzionerà come previsto –

risposta

4

Il problema qui è che il lib tag è una consuetudine set di file che prende di mira i suoi file nella directory sub lib dell'archivio guerra. Potrebbe essere possibile scrivere un'operazione personalizzata war ma non penso che ne valga la pena.

Se si desidera migliorare il modo in cui l'edera gestisce le dipendenze della guerra, suggerisco di utilizzare le configurazioni?

Creazione di una configurazione che descrive le dipendenze di run-time:

<ivy-module version="2.0"> 
    <info organisation="apache" module="hello-ivy"/> 
    <configurations> 
     <conf name="build" description="Libraries needed to for compilation"/> 
     <conf name="war" extends="build" description="Libraries that should be included in the war file" /> 
    </configurations> 
    <dependencies> 
     <dependency org="commons-lang" name="commons-lang" rev="2.0" conf="build->*,!sources,!javadoc"/> 
     <dependency org="commons-cli" name="commons-cli" rev="1.0" conf="build->*,!sources,!javadoc"/> 
    </dependencies> 
</ivy-module> 

Successivamente li recupera in una directory dedicata (usando un modello), che possono essere incluse semplicemente utilizzando tag lib il guerra del compito:

<ivy:retrieve pattern="${lib.dir}/[conf]/[artifact].[ext]"/> 

    <war destfile="${war.file}" webxml="${resources.dir}/web.xml"> 
     <fileset dir="${resources.dir}" excludes="web.xml"/> 
     <lib dir="${lib.dir}/war"/> 
    </war> 

il vantaggio di questo approccio è che si utilizza l'edera conf attributo di ogni dipendenza del progetto per decidere in ultima analisi se il vaso viene incluso nel file di guerra o meno. Il file di build non interessa più.

In conclusione, capisco che il punto del tuo post era la preoccupazione per più copie dei tuoi file jar ... Usando il mio approccio suggerito si moltiplicheranno ulteriormente le tue copie, ma vorrei dire che questo non è un problema purché tu abbia un clean target per rimuoverli in seguito.

+0

Sono d'accordo sul fatto che questa è una soluzione migliore di quello che sto facendo, ma non rimuove ancora la copia del file extra come vorrei. Più guardo questo e più penso che, come hai detto tu, l'unico vero modo per risolverlo sia creare un'attività di guerra personalizzata o anche una nuova attività lib personalizzata per l'attività di guerra. In un mondo perfetto questo nuovo compito potrebbe diventare un giorno parte di Ivy o Ant. – AmaDaden

+2

La soluzione che si desidera è utilizzare l'attività ivfile cachefileset invece di cachepath. Quindi il parametro refid del tag lib del warfile funzionerà come previsto –

4

Se stai usando Ant 1.8, è possibile utilizzare la tecnica descritta qui: http://www.beilers.com/2010/06/ivy-dependency-management-lessons-learned-and-ant-1-8-mapped-resources/

ESEMPIO:

<war destfile="${war.full.path}" webxml="WebContent/WEB-INF/web.xml" manifest="${manifest.path}"> 
    <fileset dir="WebContent"> 
    </fileset> 
    <classes dir="${build.dir}"/> 

    <mappedresources> 
     <restrict> 
     <path refid="classpath.CORE"/> 
     <type type="file"/> 
     </restrict> 
     <chainedmapper> 
     <flattenmapper/> 
     <globmapper from="*" to="WEB-INF/lib/*"/> 
     </chainedmapper> 
    </mappedresources> 

    <zipfileset dir="src" prefix="WEB-INF/classes"> 
     <include name="**/resources/**/*.properties" /> 
     <include name="**/resources/**/*.xml" /> 
    </zipfileset> 
</war> 
+0

Molto interessante ... Proverò questo e riferirò! –

Problemi correlati