¿Cómo funciona ivy: publicar?

Question

Estoy completamente en la pérdida de cómo se supone que la hormiga tarea hiedra: publicar funciona.

Supongo que haré mi compilación normal, que crea un montón de archivos jar, y luego los enviaré al repositorio (local).

¿Cómo puedo especificar desde dónde recuperar los archivos jar, y cómo terminarían en el repositorio?

Actualización:

<target name="publish-local" description="--> Publish Local"> 
    <ivy:retrieve /> 
    <ivy:publish resolver="local" pubrevision="${release.version}" status="release" update="true" overwrite="true"> 
     <artifacts pattern="${dist.dir}/[organisation]-[module].[ext]" /> 
    </ivy:publish> 
</target> 

esto funciona en realidad, no incluyó la recupere antes.

Pero todavía tengo algunos problemas, supongo que quiero publicar 3 jarras, openscada-utils.jar, openscada-utils-sources.jar y openscada-utils-javadocs.jar como openscada-utils-0.9.2.jar , openscada-utils-0.9.2-sources.jar y openscada-utils-0.9.2-javadocs.jar

No es completamente claro para mí, cómo se ensamblan los nombres reales, y dónde puedo especificar qué nombres que deberían obtener (Usando el fragmento de arriba, los frascos siempre se llaman solo utils.jar).

Actualización 1:

lo tengo para trabajar (un poco), pero todavía no se siente bien. De alguna manera, todos los tutoriales se centran en las dependencias de proyectos de terceros, pero un punto igualmente importante para mí es manejar las dependencias específicas del proyecto.

Tengo un montón de proyectos secundarios que dependen el uno del otro de varias maneras. Teniendo en cuenta la hiedra: publicar, no me queda claro cómo comenzar.

1. ¿Cómo manejo la primera versión? Tengo un número de versión común para todos los subproyectos para indicar que pertenecen juntos (digamos 0.9). Por lo tanto, la primera revisión debería ser 0.9.0, pero hasta ahora ninguno de mis proyectos está en mi repositorio. ¿Cómo hago para que Ivy asigne este número de revisión?

2. En curso de desarrollo, quiero volver a publicar los archivos compilados, sin cambiar el número de revisión hasta el momento.

3. Si termino con mi trabajo quiero enviarlo a un repositorio compartido (y aumentar el número de revisión digamos desde 0.9.0 a 0.9.1), ¿cuál es el enfoque recomendado para hacerlo?

4. Para una versión real, quiero hacer distribuciones con dependencias y sin, de alguna manera, creo que puedo usar configuraciones diferentes para eso. ¿Cómo puedo usar eso para mi ventaja?

Answer 1

Debe especificar el "resolver". Algo como:

<ivy:publish resolver="local" pubrevision="1.0"/> 

Es controlado por el patrón. Este page lo cubre bastante bien. Parece que usted quiere la suya para ser:

<artifacts pattern="${dist.dir}/[organisation]-[module]-[revision]-[type].[ext]" /> 

Y que necesita para identificar los tres frascos como artefactos en el archivo ivy.xml.Algo como esto:

<publications> 
    <artifact name="utils"/> 
    <artifact name="utils" type="source"/> 
    <artifact name="utils" type="javadocs"/> 
</publications> 

Answer 2

Es importante darse cuenta de lo que la hiedra está haciendo aquí. No se trata simplemente de copiar sus jarras de artefactos en el depósito de ivy; también está generando los archivos ".ivy.xml" relevantes que especifican todos los dependientes de cada uno de sus artefactos.

Debajo de las portadas, la tarea ivy:retrieve está activando también un ivy:resolve. Cuando se produce esa hiedra: resolución, se escribe un archivo en su caché ivy local (en la carpeta .ivy en user.home) que especifica cómo ocurrió la resolución (qué revisiones de qué módulos se necesitaron para completar la resolución). Cuando se encuentra ivy:publish, el registro de resolución se recupera de la memoria caché y se usa para generar el ivy.xml para sus artefactos.

El mayor escollo que he encontrado al hacer esto es el requisito de que las tareas ivy:resolve y ivy:publish sean cargadas por el mismo cargador de clases cuando las ejecuta hormiga. La forma más fácil de asegurarse de que esto ocurra es utilizar loaderRef en las tareas de tu tarea. Por ejemplo (tenga en cuenta las etiquetas loaderRef correspondientes):

<taskdef name="ivy-retrieve" 
    classname="org.apache.ivy.ant.IvyRetrieve" 
    classpathref="ivy.lib" 
    loaderRef="ivy.loader"/> 
<taskdef name="ivy-publish" 
    classname="org.apache.ivy.ant.IvyPublish" 
    classpathref="ivy.lib" 
    loaderRef="ivy.loader"/> 

Answer 3

Primero necesita un archivo ivy.xml.

<ivy-module version="2.0"> 
    <info organisation="com.example.code" module="MyProject" 
     revision="${project.revision}"/> 
    <configurations> 
     <conf name="runtime" description="" /> 
     ... other config elements here... 
    </configurations> 

    <publications defaultconf="runtime"> 
     <artifact name="MyProject" type="jar" ext="jar" conf="runtime" /> 
    </publications> 

    <dependencies> 
     ... 
    </dependencies> 
</ivy-module> 

El elemento de información y publicaciones elementos en ivy.xml permiten omitir varios atributos de los elementos de hiedra en build.xml.

Tenga en cuenta el $ {project.revision} en ivy.xml. La propiedad recibe el valor en build.xml, pero parece que funciona bien. La revisión puede entonces tener fácilmente cualquier valor que se requiera (por ejemplo, compilaciones nocturnas vs. compilaciones locales).

Aquí es una muestra de cómo se puede configurar el archivo build.xml

<property name="project.revision" value="1.0.0"/> 

... 

<target name="ivy"> 
    <ivy:resolve /> 

    <!-- Possible ivy:report, ivy:retrieve and other 
    elements for managing your dependencies go here --> 

    <ivy:deliver conf="*(public)"/> 
</target> 

<target name="publish" depends="clean, ivy, jar"> 
    <ivy:publish resolver="local"> 
     <!-- possible artifacts elements if your artifacts 
     are not in standard location --> 
    </ivy:publish> 
</target> 

... 

Answer 4

Estás supone que debe ejecutar la tarea <ivy:deliver/> primero. Esto crea un archivo ivy.xml que puede ser utilizado por el repositorio de Ivy.

Cuando usa <ivy:publish>, especifica en qué repositorio desea publicar especificando el parámetro resolver. Esto debe coincidir con el nombre del resolutor en su archivo ivy.settings.xml.

Realmente no especifica los artefactos, sino un patrón donde encontrar los artefactos para publicar. Especifique esto a través de la subtarea <artifacts> en la tarea <ivy:publish>. Por ejemplo, si se construye todo bajo el directorio ${basedir}/target/archive como lo hacemos, se puede especificar como esta:

<ivy:publish resolver="public"> 
    <artifacts path="target/archive/[artifact].[ext]"/> 
</ivy:publish> 

Si desea cambiar el número de revisión de su archivo, puede utilizar el pubrevision parámetro de la tarea <ivy:publish>. Esto no actualiza el ivy.xml, pero publicará sus jarras/guerras en la revisión correcta. Prefiero usar el parámetro pubrevision de la tarea <ivy:deliver> y dejar que cree el archivo correcto ivy.xml de todos modos. Luego, <ivy:publish> usará la revisión en mi archivo ivy.xml.

No necesita hacer <ivy:retrieve>.Después de todo, estás ejecutando una compilación para crear nuevas jarras, y deberían estar EN ALGÚN LUGAR de tu construcción. De lo contrario, si no estás creando una jarra o guerra, ¿qué intentas publicar en tu repositorio de Ivy? Y, ciertamente, no desea recuperar algo que ya está en su repositorio de Ivy solo para republicarlo.

---

Mi filosofía siempre ha sido que publicar es una tarea CM y no se debe hacer como parte del procedimiento de compilación. Por lo tanto, no usamos <ivy:deliver> o <ivy:publish>.

Usamos Artifactory como nuestro repositorio Ivy (y nuestro repositorio Maven). Usamos Jenkins como nuestro servidor de compilación continua.

Lo que hago es hacer que los desarrolladores creen un archivo pom.xml en su archivo ivy.xml a través de la tarea <ivy:makepom>. Esto y las jarras/guerras de construcción se guardan como artefactos archivados en Jenkins.

Cuando estamos contentos con una compilación en particular y la queremos en nuestro repositorio público, utilizo la tarea Promote Build de Jenkin para promocionar una jar/war particular con su pom.xml a nuestro repositorio de Artifactory. Usamos la tarea mvn deploy:deploy-file para hacer eso.