¿La mejor ubicación para los archivos ant build.xml?

Question

Para aquellos de ustedes que usan Ant con múltiples proyectos, ¿dónde colocan los archivos build.xml? ¿Pones uno en cada proyecto, o los pones en un proyecto separado que contiene todos tus archivos relacionados con Ant?

La recomendación habitual es poner un build.xml en cada proyecto. Pero esto tiene algunos inconvenientes:

• Hace que sea difícil volver a utilizar objetivos comunes en proyectos múltiples.

• A veces se desea usar Ant para exportar un proyecto desde el control de origen y desplegarlo. Obviamente, no puede hacer esto si el archivo de compilación está en el proyecto mismo.

Pero si se ponen todos en un lugar común:

• La gente tiene que ser consciente de su ubicación en su uso; no pueden usar "ant-find" para encontrar el archivo del proyecto actual.

• No puede haber diferentes instrucciones de compilación para las diferentes ramas del proyecto.

¿Qué hacen chicos?

EDIT: Gracias por las buenas sugerencias hasta ahora. En lo que respecta a Maven, estos no son proyectos de Java, y me da la impresión de que Maven solo está pensado para Java.

Answer 1

Coloque los archivos Ant con el proyecto. Esa es la norma de facto y recomendada por el creador de Ant. Voy a tratar de abordar algunas de las cuestiones que ha criado;

• reutilización de objetivos comunes debe hacerse utilizando técnicas como se describe por Eric Hatcher en su libro Java Development with Ant. Básicamente, extrae todas las características comunes en algunos archivos de nivel superior que todos los otros archivos Ant "heredan".

• El uso de Ant para exportar un proyecto desde el control de origen me parece extraño, pero si quieres hacer esto, usa un archivo Ant diferente :-) Puedes hacer un objetivo como ant export -Dproject=foo/bar.

Para Hormiga, recomiendo que agarrar ese libro - que tiene una tonelada de técnicas útiles.

La verdadera recomendación que me gustaría hacer es dejar caer Ant y convertir a Maven, como lo hizo la Apache Software Foundation (mantienen Ant y Maven).

Answer 2

Mi regla de oro es poner el archivo build.xml en el directorio en el que se hace referencia a todos los archivos. En otras palabras, ninguna ruta relativa debe comenzar con "../". Donde vivo, eso generalmente significa ponerlo en el directorio "trunk", que tiene src, lib, build, docs, etc. debajo de él.

Esto hace que las rutas sean mucho más limpias en el archivo, y hace que sea obvio cómo construir el proyecto.

Donde tengo varios proyectos que necesitan compilar, crearé un build.xml por separado para cada proyecto, y un build.xml central en el directorio en el que están todos los proyectos que llama a esos otros archivos build.xml. Eso te da mucha flexibilidad con muy poco trabajo.

Answer 3

Espero que un archivo de construcción Ant esté ubicado en la parte superior de un proyecto (ya es un dolor tener que mirar un archivo de construcción para "descubrir" cómo construir el proyecto, así que si tengo que localizarlo primero, me volverá loco). Ahora, con respecto a todos los inconvenientes que mencionaste, estoy tentado de decir: ¿por qué no usas Maven?

Answer 4

La forma en que he hecho esto está en el pasado (Ahora sólo tiene que utilizar Maven):

• Tener un build.xml en la raíz de cada proyecto
• Crear una build.xml general para todos los proyectos y colocarlo en el tronco de mi repositorio
• El buid.xml general tiene tareas de pago para cada proyecto. Supongo que cuando mencionó exportar del repositorio, usted realmente significó la importación.
• El fichero de construcción general también registra la dependencia, en su caso
• Usted puede actualizar proyectos individuales usando fichero de construcción individual de cada proyecto
• Si usted tiene tareas comunes definidos, puede heredar de un fichero de construcción común, así como alguien más sugirió.

Parece que su conjunto de proyectos podría ser un buen candidato para la migración a Maven, me doy cuenta de que no siempre es posible, pero si tiene tiempo, es posible que desee examinarlo.

Answer 5

Si se trabaja con proyectos independientes, se puede:

• poner su build.xml en el nivel superior
• lugar las definiciones de hormigas comunes (Antlib) en otro proyecto (por ejemplo config)
• uso svn: externos para importar la definición Antlib común (de 'config') en su proyecto

EDITAR el truco con svn: externos es que si enlaza al CABEZAL de algunos archivos comunes, puede suceder que cambien después de un par de meses/años. Por lo tanto, cada vez que etiquete, debe cambiar el svn: externals para que apunte a una versión de reparación del proyecto incluido. Esto puede ser útil cuando un proyecto tiene que reconstruirse años después de su última construcción.