Vinculación de archivos de compilación Ant

Question

Tengo un cliente y un servidor que estoy compilando con Ant. El cliente confía en que el servidor se construya primero antes de que pueda compilarse. Tengo todas las bibliotecas necesarias, excepto el archivo ear del servidor incluido en el cliente.

Creé 3 archivos de hormiga build.xml, build-client.xml y build-server.xml. (Haga clic en cualquiera de los nombres de archivo para verlos) Los archivos build-client.xml y build-server.xml están incluidos en build.xml para que pueda ejecutar objetivos desde ellos.

El problema que tengo es que la variable basedir cambia de un archivo de compilación a un archivo de compilación. Entonces, si ejecuto objetivos en build-client.xml desde build.xml, la variable basada en es relativa a build.xml.

¿Cómo cambio la variable basada en varias veces dentro de un script Ant?

Además, mirando estos archivos de compilación, ¿ves una mejor manera de hacer lo que estoy tratando de hacer? En este momento estoy pensando que tengo que tener la guerra del cliente y el oído del servidor en la misma ubicación antes de que pueda hacer la última oreja. Sin embargo, mi idea sobre esto puede ser errónea porque estos guiones parecen innecesariamente complejos.

Answer 1

El ant documentation para <import> tarea le proporciona información sobre cómo lograr esto.

Resolución de archivos contra el archivo importado

Supongamos que el archivo principal de acumulación llama importing.xml importa una imported.xml fichero de construcción, que se encuentra en cualquier parte del sistema de archivos, y imported.xml lee un conjunto de propiedades de importados. propiedades:

<!-- importing.xml --> 
<project name="importing" basedir="." default="..."> 
    <import file="${path_to_imported}/imported.xml"/> 
</project> 

<!-- imported.xml --> 
<project name="imported" basedir="." default="..."> 
    <property file="imported.properties"/> 
</project> 

Este fragmento embargo resolverán imported.properties contra el basedir de importing.xml, debido a que el basedir de imported.xml es ignorado por Ant. La forma correcta de usar importadopropiedades es:

<!-- imported.xml --> 
<project name="imported" basedir="." default="..."> 
    <dirname property="imported.basedir" file="${ant.file.imported}"/> 
    <property file="${imported.basedir}/imported.properties"/> 
</project> 

Como se explicó anteriormente ${ant.file.imported} almacena la ruta de acceso de la escritura de la estructura, que define el proyecto llamado importada, (en definitiva se almacena la ruta a imported.xml) y <dirname> toma su directorio. Esta técnica también permite que imported.xml se use como un archivo independiente (sin importar en otro proyecto).

Básicamente, realmente no se puede utilizar la variable ${basedir}, ni el atributo basedir="./../GrahamsProjClient" en su etiqueta del proyecto, pero en su lugar se puede construirlo:

<!-- build-client.xml --> 
<project name="GPClient" default="dist" > 

    <dirname property="client.root.dir" file="${ant.file.GPClient}"/> 
    <property name="real.basedir" value="${client.root.dir}/../GrahamsProjClient"/> 

    <!-- Then from then on, replace ${basedir} with ${real.basedir} --> 
    ... 
</project> 

Usted puede hacer lo mismo para la acumulación de servidor. xml, lo único a tener en cuenta es que el nombre del proyecto aparece en el atributo de archivo ${ant.file.[project name]} para <dirname />.

Answer 2

una cosa que me di cuenta con la hormiga fue que no pude conseguir variables que cambian como quería

la solución era tener ant run desde la línea de comandos para cada objetivo que quería hacer, así que en vez de hacer una declaración de comandos tales como

ant target1 target2

o

<target name="target1"> 
    <antcall target="target2"> 
</target> 

que tenía que hacer en lugar del objetivo llama lentej entially desde la línea de comandos ant target1 ant target2

así que optaron en poner estas llamadas hormigas dentro de un script en Python, que simplemente hace os.system(""); llamadas, donde mis declaraciones de comandos estaría dentro de las comillas. fiesta podría hacer esto también

esta es la única manera de que la hormiga utilizaría las variables adecuadas para cada objetivo, si esas variables tenían los mismos nombres

Answer 3

Mi regla normal es no usar <ant> o <subant> en un proceso de compilación normal porque rompe la comprobación de dependencia. Tuvimos un desarrollador dividir un build.xml en siete archivos de compilación separados, y debido a la constante llamada de <ant> tareas para hacer cosas en otros archivos de compilación, estaba ejecutando el mismo objetivo hasta 14 veces. Y, entonces, se preguntó por qué su construcción tardaba tanto. Al unir los siete archivos de compilación en un solo build.xml y al usar el parámetro depends de <target>, se acorta la construcción en menos de dos minutos.

Sin embargo, lo que tiene en este caso son realmente dos proyectos separados y uno build.xml que está utilizando para llamar a esos dos proyectos por separado. En este caso, es mejor utilizar las llamadas <ant> y <subant> que <import>.

• Estas llamadas no interferirán con ${basedir}.
• Estas llamadas le permiten especificar qué propiedades y recursos desea incluir en estos archivos separados. (La respuesta probable es ninguna).
• No tiene problemas con varios destinos que comparten el mismo nombre. Un compilar objetivo en su compilación de cliente no se superpondrá al objetivo _compile_ en la compilación de su servidor.

Subant es más potente, pero más complicado de implementar. Con Subant, puede hacer que busque los archivos build.xml. La mayor parte del tiempo usando <ant> es simplemente más fácil y hace lo que quiere.

---

Lo que realmente recomendaría es usar Ivy para manejar los problemas de dependencia. Ivy no solo puede manejar la dependencia del servidor en su cliente, sino que también puede manejar todas las dependencias jar de terceros. No más almacenamiento de jarfiles en tus proyectos. Cuando almacena archivos jar en un proyecto, pierde información sobre su versión actual y su historial. Usted ve un commons-io.jar en su proyecto, y no tiene idea de qué versión era o incluso si es el common common-io.jar, o uno de sus desarrolladores lo escribió como un punto.

El problema es que Ivy requiere un poco de trabajo para implementar. Debe usar un administrador de repositorio de Ivy como Nexus, Artifactory o Archiva. (En realidad, estos son los administradores de repositorios de Maven, pero Ivy funciona muy bien con ellos.)

Luego, debe importar ivy.jar en su proyecto y obtener el archivo ivysettings.xml para apuntar a su servidor de repositorio Ivy Maven .

Si utiliza Subversion como su sistema de control de versiones, puede hacer lo siguiente:

• crear un proyecto que incluye la hiedra ivy.jar, y un archivo XML que establece todo para usted. Tengo uno en Github que puedes ver. El archivo XML se llama ivy.tasks.xml.
• Luego en su proyecto, use svn:externals para importar este proyecto.
• En su build.xml, que tiene que hacer dos cosas:
  • añadir el espacio de nombres de la hiedra en su entidad <project>.
  • Utilice la tarea <import> para importar el archivo Ivy XML que tiene todo configurado.

La ventaja es que el cambio de su proyecto Ivy cambiará automáticamente todos los proyectos que interactúan con la hiedra. Por ejemplo, si cambia la URL del servidor de Ivy, o necesita redefinir los directorios de caché de Ivy.

Uno se hace eso, se crea un archivo sencillo ivy.xml que define sus dependencias, y utilizar <ivy:cachepath> y <ivy:retrieve> para recuperar los frascos de terceros que necesita. Esto incluiría el contenedor de servidor que su cliente necesita.