¿Cómo funciona ivy: publicar trabajo?

votos
24

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

Esperaría que hiciera mi compilación normal, que crea un montón de archivos jar, y luego los enviaría al repositorio (local).

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

Actualizar:

<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 realmente funciona, no incluí la recuperación antes.

Pero todavía tengo algunos problemas, supongamos 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 está del todo claro para mí, cómo se ensamblan los nombres reales, y dónde puedo especificar qué nombres deben 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 publicar los archivos compilados de nuevo, 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?

Publicado el 09/12/2008 a las 17:18
fuente por usuario
En otros idiomas...                            


4 respuestas

votos
9

Necesita especificar el "resolver". Algo como:

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

Está controlado por el patrón. Esta página lo cubre bastante bien. Parece que quieres que el tuyo sea:

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

Y deberá identificar los tres jar 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>
Respondida el 09/12/2008 a las 17:30
fuente por usuario

votos
4

Lo primero que 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>

Los elementos de información de elementos y publicaciones en ivy.xml permitir que salte varios atributos sobre los elementos de hiedra en build.xml.

Tenga en cuenta el $ {} project.revision en ivy.xml. La propiedad se le da valor en build.xml, pero esto parece funcionar muy bien. La revisión a continuación, puede fácilmente tener cualquier valor que se requiere (por ejemplo. Nightly builds vs construye local).

Aquí está 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>

...
Respondida el 13/01/2012 a las 17:28
fuente por usuario

votos
2

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

Cuando se utiliza <ivy:publish>especifica qué repositorio que desea publicar a especificando en el resolverparámetro. Este debe coincidir con la resolución de nombres en su ivy.settings.xmlarchivo.

En realidad, no especifica los artefactos, pero un patrón donde encontrar los artefactos para publicar. Esto se especifica a través de la <artifacts>subtarea de la <ivy:publish>tarea. Por ejemplo, si se construye todo bajo el ${basedir}/target/archivedirectorio, 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 <ivy:publish>tarea. Esto no actualiza el ivy.xml, pero publicará sus tarros / Guerra de la revisión correcta. Yo prefiero usar el pubrevision parámetro de la <ivy:deliver>tarea y dejar que se cree el correcto ivy.xmlarchivo de todos modos. A continuación, <ivy:publish>va a utilizar la revisión en mi ivy.xmlarchivo.

No es necesario hacer <ivy:retrieve>. Después de todo, usted está ejecutando una versión de crear nuevos frascos, y que debe estar en alguna parte en su construcción. De lo contrario, si no está creando un tarro o la guerra lo que estás tratando de publicar en su repositorio de Ivy? Y, desde luego no desea recuperar algo que ya está en su repositorio de Ivy acaba de volver a publicarla.


Mi filosofía ha sido siempre que la publicación es una tarea CM y no debe hacerse como parte del procedimiento de construcción. Por lo tanto, no utilizamos <ivy:deliver>o <ivy:publish>.

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

Lo que hago es tener los desarrolladores hacer un pom.xmlarchivo de su ivy.xmlarchivo a través de la <ivy:makepom>tarea. Esto y los frascos de construcción / guerras se guardan como objetos archivados en Jenkins.

Cuando somos felices con una estructura particular y queremos que en nuestro repositorio público, uso de Jenkin Promover la tarea de construcción de promover un frasco / guerra particular con su pom.xml a nuestro repositorio Artifactory. Usamos la mvn deploy:deploy-filetarea de hacer eso.

Respondida el 28/08/2012 a las 19:07
fuente por usuario

votos
0

Es importante darse cuenta de lo que está haciendo la hiedra 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 ivy:retrievetarea en realidad también está desencadenando un ivy:resolve. Cuando se produce esa hiedra: resolución, se escribe un archivo en su caché ivy (en la .ivycarpeta user.home) que especifica cómo ocurrió la resolución (qué revisiones de qué módulos se necesitaron para completar la resolución). Cuando ivy:publishse encuentra, ese registro de resolución es recuperado de la memoria caché y utilizado para generar el ivy.xml para sus artefactos.

El peligro más grande que he encontrado para hacer esto es el requisito de que el ivy:resolvey ivy:publishtareas tanto ser cargado por el mismo cargador de clases cuando son ejecutadas por las hormigas. 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 coincidentes):

<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"/>
Respondida el 10/12/2008 a las 07:10
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more