En primer lugar, Ivy is not Maven;)
Maven2 es una herramienta de gestión de proyectos de software y comprensión, mientras que Ivy es solo una herramienta de administración de dependencias.
Ivy depende en gran medida de un concepto único llamado configuración.
En hiedra, una configuración de módulo es una forma de usar o para ver el módulo.
Por ejemplo, puede tener una configuración de prueba y tiempo de ejecución en su módulo. Pero también puedes tener una configuración mysql y oracle. O una configuración hibernate y jdbc.
En cada configuración se puede declarar:
- lo artefactos (frasco,, ... la guerra) son obligatorios.
- sus dependencias en otros módulos, y describa qué configuración de la dependencia necesita. Esto se llama mapeo de configuración.
Así que el atributo conf hace precisamente eso: Describe una asignación de configuración para una dependencia.
El mapped child element es su "lado derecho del símbolo ->" y representa el nombre de la configuración de dependencia asignada. El comodín '*' se puede usar para designar todas las configuraciones de este módulo.
Maven2 en su lado tiene algo que se llama la alcance.
Puede declarar una dependencia como parte del alcance de la prueba o del ámbito de tiempo de compilación.
Luego, dependiendo de este alcance, obtendrá el artefacto de dependencia (solo un artefacto por módulo en maven2) con sus dependencias según su alcance. Los ámbitos están predefinidos en maven2 y no puede cambiar eso.
Eso significa:
Hay un montón de dependencias innecesarias descargados para muchas bibliotecas.
Por ejemplo, Hibernate descarga un montón de archivos JAR JBoss y la etiqueta de visualización descarga todos los archivos JAR de varios frameworks web. Me encontré excluyendo casi tantas dependencias como agregué.
El problema es que la hibernación se puede utilizar con varias implementaciones de caché, varios aplicación agrupación de conexiones, ... Y esto no puede ser controlada con alcances, configuraciones Ivy wheres ofrece una solución elegante a este tipo de problema.
Por ejemplo, en la hiedra, hibernación suponiendo que tiene un archivo de hiedra como éste, entonces se puede declarar una dependencia de esa manera:
<dependency org="hibernate" name="hibernate" rev="2.1.8" conf="default->proxool,oscache"/>
conseguir hibernar con sus Proxool y OSCache implementaciones, y al igual que:
<dependency org="hibernate" name="hibernate" rev="2.1.8" conf="default->dbcp,swarmcache"/>
para obtener hibernate con dbcp y swarmcache.
Mediante la cartografía de su configuración por defecto master a "proxool,oscache" o "dbcp,swarmcache", se especifica lo que necesita exactamente desde el módulo "Hibernate".
Puede encontrar a los "Proxool, ..." argumentos haciendo una lista de la configuración de la hiedra definido para cada asociado módulos con la biblioteca. Por ejemplo:
<ivy-module version="2.0">
<info organisation="ssn-src" module="pc"/>
<configurations defaultconfmapping="default->default">
<conf name="default" />
<conf name="provided" description="they are provided by the env." />
<conf name="compile" extends="default,provided" />
<conf name="war" extends="default"/>
</configurations>
<dependencies>
Example:
supongamos modA tiene dos configuraciones, defecto y prueba.
Como cuestión práctica, va a ser muy inusual querer omitir el atributo conf del elemento de dependencia.
El ivy.xml para modA podría tener una dependencia:
<dependency org="theteam" name="modB" rev="1.0" conf="default->*" />
estás empezando desde por defecto, en lugar de tanto de defecto y prueba.
El ejemplo anterior hace que el valor predeterminado de modA dependa de conf1, conf2 y conf3 de modB.
O puede que quiera decir que por defecto de Moda solo depende de conf1 de ModB:
<dependency org="theteam" name="modB" rev="1.0" conf="default->*conf1*" />
Se agregaron más detalles, como se solicitó – VonC