Qualcuno può spiegare l'attributo conf della dependence ivy.xml?

Question

non riesco a trovare alcuna spiegazione approfondita di conf attributi del tag di dipendenza Ivy:

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

Vedi che conf attributo? Non riesco a trovare alcuna spiegazione (che io possa capire) sul lato destro del simbolo ->. PER FAVORE, tieni presente che non conosco la prima cosa su Maven, quindi ti preghiamo di spiegare questo attributo con quella considerazione.

Sì, ho già guardato questo: http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html

Grazie,
Dan

Answer 1

Prima di tutto, Ivy is not Maven;)
Maven2 è uno strumento di gestione e comprensione dei progetti software, mentre Ivy è solo uno strumento di gestione delle dipendenze.

Ivy fa molto affidamento su un concetto unico chiamato configurazione.
In edera, una configurazione modulo è un modo da utilizzare o vedere il modulo.
Ad esempio, è possibile avere una configurazione di test e runtime nel modulo. Ma puoi anche avere un mysql e una configurazione di Oracle. O una configurazione di ibernazione e jdbc.

In ogni configurazione è possibile dichiarare:

• quanto artefatti (vaso, la guerra, ...) sono obbligatori.
• le dipendenze da altri moduli e descrivere quale configurazione della dipendenza è necessaria. Questo è chiamato mappatura della configurazione.

Quindi l'attributo conf fa esattamente questo: Descrive un mapping di configurazione per una dipendenza.
Il mapped child element è il "lato destro del simbolo ->" e rappresenta il nome della configurazione delle dipendenze mappata. Il carattere jolly '*' può essere utilizzato per designare tutte le configurazioni di questo modulo.

---

Maven2 sul suo lato ha qualcosa chiamato ambito.
È possibile dichiarare una dipendenza come parte dell'ambito del test o dell'ambito buildtime.
Quindi, in base a questo ambito, si ottiene l'artefatto di dipendenza (solo un artefatto per modulo in maven2) con le sue dipendenze in base all'ambito. Gli ambiti sono predefiniti in Maven2 e non è possibile cambiarlo.

Ciò significa:

Ci sono un sacco delle dipendenze inutili scaricati per molte biblioteche.
Ad esempio, Hibernate scarica un gruppo di JAR JBoss e il tag di visualizzazione scarica tutti i vari JAR del framework Web. Mi sono ritrovato ad escludere quasi tutte le dipendenze che ho aggiunto.

Il problema è che Hibernate può essere utilizzato con diverse implementazioni di cache, molti implementazione pool di connessioni, ... e questo non può essere gestito con gli ambiti, le configurazioni wheres Ivy offre una soluzione elegante a questo tipo di problema.
Per esempio, edera, assumendo Hibernate ha un file di edera come questo, allora si può dichiarare una dipendenza del genere:

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

per ottenere ibernazione con le sue implementazioni Proxool e OSCache, e così:

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

per ottenere ibernazione con dbcp e swarmcache.

Con la mappatura predefinita master configurazione "proxool,oscache" o per "dbcp,swarmcache", si specifica che cosa avete bisogno esattamente dal modulo "Sospensione".

---

È possibile trovare quelli "Proxool, ..." argomenti di messa in vendita la configurazione edera definito per ogni modulo associato con la libreria. Per esempio:

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

supponiamo modA ha due configurazioni di default, e il test.
In pratica, sarà molto insolito voler omettere l'attributo conf dell'elemento di dipendenza.
Il ivy.xml per modA potrebbe avere una dipendenza:

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

stai partendo dal default, piuttosto che sia di default e il test.

L'esempio precedente rende l'impostazione predefinita di modA dipende da conf1, conf2 e conf3 di modB.
Oppure si potrebbe voler dire che il default di modA dipende solo conf1 di MODB:

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

Answer 2

Grazie VonC!

Mi ha aiutato molto di più.

Quando si tratta di opzioni (configurazioni) tieTY, è possibile trovarli nel file ivy- [numero revisione] .xml nel repository Ivy sotto: nome organizzazione -> nome modulo.

Elemento di configurazione di esempio dalla revisione JUnit 4.6 scaricata da 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> 

Nel file di ivy.xml del mio progetto, ho una configurazione in fase di compilazione di prova.Nella elemento dipendenze Ho la seguente dipendenza:

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

Come si può vedere, la mia configurazione in fase di compilazione di test dipende dalla configurazione di compilazione nel file di ivy.xml del JUnit.

Answer 3

Mi ha aiutato una volta a capire le cose in questo modo:

1. Una configurazione edera è semplicemente un nome per qualche sottoinsieme dei manufatti del modulo.
2. Le dipendenze tra i moduli sono specificate in termini di nomi di configurazione.

Answer 4

Ho letto queste risposte e francamente non le trovo molto utili. Credo che potrebbero essere migliorati quindi ho scritto giù come uso e comprendere le configurazioni, mostrando un esempio pratico:

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

Purtroppo, è necessario capire un po 'esperto di e le sue dipendenze, perché Ivy sta usando i repository Maven per tirare giù quei file jar così Ivy deve capire Maven e ti passa quel dollaro. Ma, penso di averlo tenuto semplice, senza entrare troppo nei dettagli di Maven.