Ant/Ivy para la construcción del proyecto

Question

Estoy pensando en cambiar un proyecto Maven que me las arreglo para Apache Ant/Ivy. Necesito más control sobre el proceso de construcción y estoy muy frustrado con Maven. Por favor, no hay comentarios sobre lo genial que es Maven. Mi pregunta es sobre Ivy.

me gustaría configurar una plantilla "estándar" de generación Ant que luego puede usarse para otros proyectos con cambios mínimos.

Voy a configurar un repositorio "empresarial" central donde podemos ubicar bibliotecas de terceros que no están disponibles en los repositorios públicos de Maven (por ejemplo, bibliotecas comerciales, bibliotecas Sun, bibliotecas propietarias, etc.). Este repositorio empresarial estará disponible en nuestra LAN local, pero puede no estar disponible desde fuera de la oficina.

Cada desarrollador tendrá un depósito privado en ~/.ivy/repository. Me gustaría que Ant build actualice automáticamente este repositorio privado con las versiones modificadas de las bibliotecas del repositorio de la empresa.

En ~/.ivy/ant, planeo colocar módulos "estándar" para incluir en los proyectos individuales build.xml archivos, usando la tarea include en Ant 1.8. Estos módulos proporcionarán objetivos de compilación como Scala y Clojure con diferentes versiones para diferentes versiones de Scala y Clojure (p. Ej .: scala-compile-2.9.1.xml, clojure-compile-1.3.xml, etc.). Los módulos de compilación estarán disponibles en el repositorio empresarial y se actualizarán automáticamente en los repositorios privados. Ellos cambian.

Cada proyecto seguirá una estructura estándar Maven directorio: ${project}/src/main/java, ${project}/target/classes, etc.

En el pasado, he intentado usar la hiedra, pero la hormiga construir archivos tiene que ser muy grande (> 500 líneas para la construcción de plantilla archivo) y difícil de administrar/editar. Espero que al poner objetivos estándar en sus propios módulos de compilación en el directorio ~/.ivy/ant, puedo evitar ese engorro del código.

se puede hacer esto? ¿Estoy fuera de la base? La única documentación que puedo encontrar en Ivy es en el sitio web de Apache (http://ant.apache.org/ivy). ¿Hay alguna otra documentación disponible, incluidos los libros?

Answer 1

idea bastante sensata de dividir fichero de construcción plantilla en los archivos de ayuda includable. Personalmente, ahora estoy cambiando un proyecto realmente grande de hormiga (sin administración de dependencia en absoluto, solo copiando archivos de ftp) a la solución ant/ivy. Así que lo hice de esta manera: tengo un archivo con objetivos de hitos, es decir, listo para compilar, compilado, listo para archivar, archivar, etc. Creo que entendiste la idea. He configurado dependencias de todos estos objetivos (dependencias en términos de hormiga, no me malinterpreten). De esa forma, compilado depende de ready-to-compile, ready-to-compilede depende de initialized-smth así. Estos objetivos no tienen cuerpo: son para incluir en cada archivo de compilación de cada módulo de su proyecto de varios módulos. El único propósito de estos objetivos para mantener el ESTADO de la construcción, debido a estas cosas de importación, las cosas se vuelven bastante complicadas y es difícil saber qué objetivo se anuló y cuándo se ejecutará este objetivo. Pero con este archivo puedo cambiar fácilmente el estado de vy build en cada hito sensible. Quiero en un módulo compilar archivos de ayuda con exe exteran. No hay problema - en este proyecto solo hago esto - listo para archivar depende del objetivo para compilar la ayuda. Y como estos objetivos de hitos están incluidos (solo puedo anular algunos de ellos), todos los demás preserven la forma deseada de construir el proyecto.

Otra parte de mi estrategia - mixins construir archivos - para cada área específica. Entonces tengo un archivo para hiedra. Ahí pongo inicialización, resolución, publicación, etc. Cuando quiero usar ivy, solo incluyo este archivo y administro las depraudes a través de mis objetivos de hitos.Si la compilación es típica, solo incluyo este archivo y tengo una funcionalidad de convención sobre configuración. Todo fuera de la caja. ¿¿Cómo?? Simplemente combinando con otras mixinas. Mixins puede incluir otras mixinas para depender de ellas. Entonces, cada mezcla es una parte reutilizable de mi estrategia de construcción. El material de OOP - Unidad de un solo motivo. En tu caso, es scala mixin con objetivos específicos para scala.

Luego tengo delegate.xml que delega las actividades de construcción comunes de proyectos secundarios. Tengo dist, all, test y lo que quieras para el proyecto multimódulo. El orden de construcción se evalúa con la lista de construcción de tareas ant-ivy.

También hay algunos otros archivos, pero estos son los archivos estratégicamente básicos que me ayudaron a tener una versión reutilizable y mantenible con este proyecto GRANDE y MUY conservador. Entonces, si le interesan los detalles, no sea tímido y contácteme. Estaré encantado de ayudarle, porque los documentos de hiedra son realmente complicados e incompletos.

EDIT: Acerca de los libros - Ant in Action puede ayudarlo, tomé varias ideas de este libro, y realmente lo recomiendo a todos que lo lean. Allí puedes encontrar cosas de hiedra, también. Y sobre los documentos de hiedra, lo siento, es todo lo que está disponible. Pero cuando tuve problemas con esta molesta hiedra + hormiga, encontré varios artículos interesantes en blogs privados. Entonces ... eso puede llenar el vacío de alguna manera.