Ivy, ¿cuál es la configuración maestra y por qué no está tirando jvyaml?

Question

tengo el siguiente archivo de hiedra:

<configurations defaultconfmapping="buildtime"> 
    <conf name="buildtime" visibility="private" description="Libraries needed only for compilation" /> 
    <conf name="runtime" description="Libraries only needed at runtime" /> 
    <conf name="test" description="Libraries only needed for testing" /> 
</configurations> 

<dependencies> 
    <dependency org="net.java.dev" name="jvyaml" rev="0.2.1" conf="runtime" /> 
    <dependency org="org.apache.solr" name="solr-core" rev="3.6.0" conf="runtime" /> 

</dependencies> 

y tengo una hormiga recuperar tarea que se ve así:

<target name="retrieve-all" depends="resolve"> 
    <ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]" conf="*" /> 
</target> 

Lo extraño es que, todas las dependencias de solr se descargan en lib/runtime como era de esperar, ¡pero el módulo jvyaml no lo hace! Es resuelve ', pero no se descargará en el directorio lib/tiempo de ejecución a menos que cambie la declaración de dependencias a:

<dependency org="net.java.dev" name="jvyaml" rev="0.2.1" conf="runtime->master" /> 

¿Qué es esta configuración principal y por qué se necesita para sacar el frasco jvyaml, pero no Solr?

Gracias

Answer 1

que sugeriría la reestructuración de las configuraciones de la siguiente manera:

<ivy-module version="2.0"> 
    <info organisation="com.myspotontheweb" module="demo"/> 

    <configurations> 
     <conf name="compile" description="Libraries needed only for compilation" /> 
     <conf name="runtime" description="Libraries only needed at runtime" extends="compile" /> 
     <conf name="test" description="Libraries only needed for testing" extends="runtime" /> 
    </configurations> 

    <dependencies> 
     <dependency org="net.java.dev" name="jvyaml" rev="0.2.1" conf="runtime->default" /> 
     <dependency org="org.apache.solr" name="solr-core" rev="3.6.0" conf="runtime->default" /> 
    </dependencies> 

</ivy-module> 

cambios importantes introducidos:

1. Utilice la configuración de "compilación" más estándar
2. Configuración de la herencia utilizando el atributo "extends". Las dependencias de compilación se pueden incluir automáticamente en las configuraciones de tiempo de ejecución y de prueba.
3. Utilice las asignaciones de configuración, por ejemplo: conf = "runtime-> default". Esto hace que sea obvio qué configuración local está asociada con qué configuración remota.

asignaciones de configuración explicados

configuraciones son una potente característica de hiedra. Cuando descargas hiedra Maven módulos se realiza una traducción interna y asigna un conjunto estándar de configuraciones, se señalan en esta respuesta:

• How are maven scopes mapped to ivy configurations by ivy

Cuando se declara una dependencia que es una buena idea para hacer siempre uso de una mapeo de configuración, por lo que no hay duda de dónde se asignan los artefactos de dependencias.

Por ejemplo:

<dependency org="??" name="??" rev="??" conf="runtime->default" /> 

Aquí estamos diciendo que queremos dependencias predeterminadas del módulo remoto asociados con nuestra configuración de ejecución local.

En la práctica, sólo hay dos asignaciones remotas de configuración que realmente va a necesitar:

• defecto: artefacto del módulo remoto y todas sus dependencias transitivas de tiempo de ejecución
• maestros: el mando a distancia del módulo solo artefacto (sin dependencias transitivas)

En conclusión, creo que su problema fue causado por el hecho de que el remoto del módulo de e Maven alcance "tiempo de ejecución" no incluye el artefacto del módulo Maven, en lugar que estaba recibiendo las dependencias transitivas inexistentes del módulo jvyaml :-(

Algunos consejos adicionales

También me gustaría sugerir que genera una hiedra informe de gestión de la dependencia, de la siguiente manera:

<target name="init" description="Resolve dependencies and populate lib dir"> 
    <ivy:resolve/> 
    <ivy:report todir="${build.dir}/ivy-report" graph="false"/> 
    <ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]"/> 
</target> 

El informe ayudará a explicar cómo termina cada dependencia arriba en diferentes configuraciones. También es realmente útil para determinar cómo se gestionan las dependencias transitivas.

Y, por último, aquí es donde la herencia de configuración vale la pena, la creación de rutas de clases de hiedra logró ANT:

<target name="init" description="Resolve dependencies and set classpaths"> 
    <ivy:resolve/> 
    <ivy:report todir="${build.dir}/ivy-report" graph="false"/> 

    <ivy:cachepath pathid="compile.path" conf="compile"/> 
    <ivy:cachepath pathid="runtime.path" conf="runtime"/> 
    <ivy:cachepath pathid="test.path" conf="test"/> 
</target> 

Answer 2

Aviso de que el original Solr núcleos no se recupera bien. Después de resolverlo, vaya a la caché y verifique los archivos ivy.xml para ambos módulos.

Usted verá que publican sus artefactos en conf = maestro sólo

<artifact name="jvyaml" type="jar" ext="jar" conf="master"/> 

<artifact name="solr-core" type="jar" ext="jar" conf="master"/> 

Lo que significa, que tiene que hacer el mapeo configuración explícita para indicar que la configuración de builtime debe dar lugar a la configuración de 'maestro' de sus dependencias . (ver mapeo de configuración).

Sin embargo, las dependencias de la Solr-núcleo, tienen el mapeo de configuración que se podía ver en el archivo ivy.xml:

<dependency org="org.apache.solr" name="solr-solrj" rev="3.6.0" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/> 

Creo que es esa cosa principal (*).

Lo que suelo hacer es en mi propio archivo ivy.xml cuando declaro dependencias hago el mapeo:

<dependency org="net.java.dev" name="jvyaml" rev="0.2.1" conf="runtime->master" /> 

Éste dice el tiempo de ejecución se evoca la configuración maestra en la dependencia designada.

Usted podría hacer

conf="runtime,test->master" 

así