Ivy: Resolución y publicación de JAR localmente

Question

Hemos estado usando Ivy durante unos meses y tenemos nuestro propio "Ivy Repo" alojado en un servidor web aquí en la oficina. Todos nuestros proyectos están configurados para ir a este repositorio para resolver dependencias.

Tenemos varios JAR de tipo "comunes" que son utilizados por muchos de nuestros proyectos. Debido a esto, y porque sólo tenemos 1 repo, estamos encontrando una gran cantidad de fea cabeza procedente de la siguiente escenario:

• Un desarrollador se le da una tarea para agregar una función para el proyecto 1 (que depende de un frasco Común)
• Durante el transcurso del desarrollo del proyecto 1, el desarrollador se da cuenta de que él/ella tiene que realizar cambios en el tarro común
• cambios tarro Común se hizo
• tarro común tiene que pasar por la revisión de código y normal código de promoción
• Build master publica una nueva jar común
• Proyecto 1 puede reanudar el desarrollo ahora que el tarro común ha sido actualizado

Esto se está convirtiendo en ridículo y doloroso para nuestro equipo.

Para mí, la solución obvia es proporcionar objetivos ant en cada proyecto que permitan al desarrollador publicar/resolver localmente (hacia y desde su sistema de archivos). De esa forma, pueden dividir la jarra Common de 9 maneras hasta el domingo, pero sin perder 2 - 4 días mientras esperan que se publique Common. De esta forma, el desarrollador realiza cambios locales tanto en el Proyecto 1 como en Común, y el código pasa por nuestro proceso de promoción de una sola vez.

Sé que esto es posible con Ivy, pero soy tan nuevo que ni siquiera sé por dónde empezar.

Actualmente utilizamos un archivo global ivy.settings para todos los proyectos. En el archivo de configuración, usamos una resolución de cadena que tiene 1 url resolver dentro de ella, que se conecta a nuestro "repo de hiedra".

Yo creo el siguiente es el único cambio que será necesario, pero no estoy 100% seguro:

• En ivy.settings que tendrá que añadir un sistema de archivos local de resolver antes de la url resolver se llama; De esta manera, comprobamos el sistema de archivos local para dependencias antes de pasar a la cesión temporal de hiedra (servidor web)
• Configurar de ivy.xml con una opción de cada proyecto de alguna manera que permite caché local publicación
• Tweak La hormiga construye para tener un objetivo publish-locally que ejerza la opción mencionada anteriormente

I creo estos cambios nos permitirán: (1) siempre buscamos a nivel local para dependencias antes de mirar al servidor web, (2) publicar localmente como una opción de generación (objetivo).

Si esto no es verdad, o si me faltan pasos, por favor avise! De lo contrario, probablemente pueda averiguar cómo agregar un sistema de resolución de archivos desde los documentos de Ivy, pero no tengo idea de cómo lograr que el objetivo publish-locally funcione. ¿Algunas ideas? ¡Gracias por adelantado!

Answer 1

Ivy es compatible con las revisiones dinámicas:

código estable haría referencia a la última versión aprobada de la jarra Commons:

<dependency org="my-org" name="commons" rev="latest.release"/> 

inestable (en desarrollo) código haría referencia a la última versión no autorizada del código

<dependency org="my-org" name="commons" rev="latest.integration"/> 

Por lo tanto, debe cambiar el proceso de compilación para que su módulo de commons tenga dos destinos de publicación. Uno para instantáneas inestables de su código y el otro para lanzamientos formales.

(Véase el atributo de estado de la hiedra publish tarea)

Nota: En Maven tiene dos tipos de depósito, la liberación y la instantánea. El apoyo de Ivy para este concepto es más sutil y más poderoso en mi humilde opinión.

Answer 2

Yo también preferiría el enfoque de Marks.

En cuanto a publish-locally, puede indicar a la tarea de publicación qué sistema de resolución (resolver="local") va a utilizar. De esta forma puede publicar en el sistema de archivos local o en cualquier resolución definida.

<ivy:publish 
     resolver="local" 
     overwrite="true" 
     revision="${project.version}"> 
     <artifacts pattern="dist/[artifact]-[revision].[type]" /> 
    </ivy:publish> 

Y si utiliza un dispositivo de resolución de la cadena debe establecer returnFirst="true" por lo que la solución se detendrá cuando algo se encontró localmente.