web-dev-qa-db-fra.com

Quelqu'un peut-il expliquer l'attribut conf de la dépendance ivy.xml?

Je ne trouve aucune explication détaillée de l'attribut conf de la balise de dépendance Ivy:

<dependency org="hibernate" name="hibernate" rev="3.1.3" conf="runtime, standalone -> runtime(*)"/>

Vous voyez cet attribut conf ? Je ne trouve aucune explication (que je peux comprendre) sur le côté droit du -> symbole. VEUILLEZ garder à l'esprit que je ne connais pas la première chose à propos de Maven, veuillez donc expliquer cet attribut avec cette considération.

Oui, j'ai déjà regardé ceci: http://ant.Apache.org/ivy/history/latest-milestone/ivyfile/dependency.html

Merci,
Dan

javaapacheantivy
65
Daniel Kaplan

Tout d'abord, Ivy n'est pas Maven ;)
Maven2 est un outil de gestion et de compréhension de projets logiciels, alors qu'Ivy n'est qu'un outil de gestion des dépendances.

Ivy s'appuie fortement sur un concept unique appelé configuration .
Dans Ivy, une configuration de module est une manière d'utiliser ou de voir le module .
Par exemple, vous pouvez avoir une configuration de test et d'exécution dans votre module. Mais vous pouvez également avoir une configuration MySQL et Oracle. Ou une configuration Hibernate et JDBC.

Dans chaque configuration, vous pouvez déclarer:

  • quels artefacts (pot, guerre, ...) sont nécessaires.
  • vos dépendances sur d'autres modules, et décrivez la configuration de la dépendance dont vous avez besoin. Cela s'appelle le mappage de configuration.

Ainsi, l'attribut conf fait précisément cela: décrit un mappage de configuration pour une dépendance.
Le élément enfant mappé est votre "côté droit du -> symbol "et représente le nom de la configuration de dépendance mappée. '*' le caractère générique peut être utilisé pour désigner toutes les configurations de ce module.

Maven2 de son côté a quelque chose appelé la portée .
Vous pouvez déclarer une dépendance comme faisant partie de l'étendue de test ou de l'étendue de buildtime.
Ensuite, en fonction de cette étendue, vous obtiendrez l'artefact de dépendance (un seul artefact par module dans maven2) avec ses dépendances en fonction de leur étendue. Les étendues sont prédéfinies dans maven2 et vous ne pouvez pas changer cela.

Cela signifie :

Il existe un lot de dépendances inutiles téléchargées pour de nombreuses bibliothèques.
Par exemple, Hibernate télécharge un tas de fichiers JAR JBoss et la balise d'affichage télécharge tous les différents fichiers JAR du cadre Web. Je me suis retrouvé à exclure presque autant de dépendances que j'en ai ajouté.

Le problème est que hibernate peut être utilisé avec plusieurs implémentations de cache, plusieurs implémentations de pool de connexions, ... Et cela ne peut pas être géré avec des étendues, où les configurations Ivy offrent une solution élégante à ce type de problème.
Par exemple, dans Ivy, en supposant que hibernate a un fichier Ivy comme celui-ci , alors vous pouvez déclarer une dépendance comme celle-ci:

<dependency org="hibernate" name="hibernate" rev="2.1.8" conf="default->proxool,oscache"/>

pour obtenir l'hibernation avec ses implémentations proxool et oscache, et comme ça:

<dependency org="hibernate" name="hibernate" rev="2.1.8" conf="default->dbcp,swarmcache"/>

pour mettre en veille prolongée avec dbcp et swarmcache.

En mappant votre configuration master par défaut sur "proxool,oscache" ou pour "dbcp,swarmcache ", vous spécifiez ce dont vous avez besoin exactement à partir du module" hibernate ".

Vous pouvez trouver ces arguments "proxool, ..." en listant la configuration Ivy définie pour chaque module associé à la bibliothèque. Par exemple:

<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>

Exemple :

supposons que modA a deux configurations, default et test.
En pratique, il sera très inhabituel de vouloir laisser de côté l'attribut conf de l'élément de dépendance.
Le ivy.xml pour modA peut avoir une dépendance:

<dependency org="theteam" name="modB" rev="1.0" conf="default->*" />

Vous commencez par défaut, plutôt que par défaut et par test.

L'exemple ci-dessus fait que la valeur par défaut de modA dépend des paramètres conf1, conf2 et conf3 de modB.
Ou vous voudrez peut-être dire que la valeur par défaut de modA ne dépend que de conf1 de modB:

<dependency org="theteam" name="modB" rev="1.0" conf="default->*conf1*" />
74
VonC

J'ai lu ces réponses et franchement, je ne les trouve pas très utiles. Je pense qu'ils pourraient être améliorés, j'ai donc écrit comment j'utilise et comprends les configurations en montrant un exemple pratique:

http://wrongnotes.blogspot.com/2014/02/simplest-explanation-of-ivy.html

Malheureusement, vous devez comprendre un peu Maven et ses dépendances, car Ivy utilise les référentiels Maven pour dérouler ces fichiers jar afin qu'Ivy doive comprendre Maven et qu'il vous en remette la responsabilité. Mais, je pense que je l'ai gardé très simple sans entrer dans trop de détails sur maven.

16
chubbsondubs

Merci VonC!

Cela m'a beaucoup aidé.

En ce qui concerne les options (configurations) tieTYT, vous pouvez les trouver dans le fichier ivy- [numéro de révision] .xml dans votre référentiel Ivy sous: nom de l'organisation -> nom du module.

Un exemple d'élément de configuration de la révision JUnit 4.6 téléchargé depuis http://www.springsource.com/repository/app/ .

<configurations>
    <conf name="compile" visibility="public" description="Compile dependencies"/>
    <conf name="optional" visibility="public" extends="compile" description="Optional dependencies"/>
    <conf name="provided" visibility="public" description="Provided dependencies"/>
    <conf name="runtime" visibility="public" extends="compile" description="Runtime dependencies"/>
</configurations>

Dans le fichier ivy.xml de mon projet, j'ai un test de compilation de configuration. Dans l'élément de dépendances, j'ai la dépendance suivante:

<dependency org="org.junit" name="com.springsource.org.junit"
        rev="4.6.0" conf="compile-test->compile" />

Comme vous pouvez le voir, ma configuration de compilation-test dépend de la configuration de compilation dans le fichier ivy.xml de JUnit.

13
Espen

Cela m'a aidé une fois à comprendre les choses de cette façon:

  1. Une configuration de lierre est simplement un nom pour un sous-ensemble des artefacts du module.
  2. Les dépendances entre les modules sont spécifiées en termes de noms de configuration.
7
Archie