In che modo Maven risolve i conflitti di versione delle dipendenze transitive? strategia di conquista più vicina

Question

Mi sono finalmente abituato a non avere alcuna dipendenza dichiarata non dichiarata o non utilizzata nei miei progetti. Anche se è molto difficile tenere traccia delle dipendenze di runtime/test dichiarate non utilizzate elencate nella dipendenza: analizzare ... È sufficiente scrivere loro commenti in pom.xml o in altro modo gestirli per sapere che sono necessari per il test o il runtime.

Ma il modo di risolvere il conflitto di versione non è ancora chiaro. Riguardo alle dipendenze transitive.

Come funziona esattamente la strategia delle vittorie più vicine? Quando una versione viene utilizzata su un'altra versione?

• Se si dichiara la dipendenza non dichiarato Utilizzato con un numero di versione - si vince sempre

• Se uno non specifica versione di dipendenza in modo esplicito, Maven non può risolvere qualsiasi versione conflitti che possono sorgere riguardo a questa dipendenza (strano, ma scritto here)

• Se non si dichiara dipendenza usata non dichiarata, si sceglie una dipendenza transitiva dal livello più vicino (strategia vince più vicino) e se il conflitto è sullo stesso livello, in qualche modo decide B Versione ra A rispetto alla versione B ... Forse il primo si tratta di quando si elaborano le depenencies vince

Answer 1

credo che la risoluzione delle dipendenze funziona esattamente allo stesso modo hai descritto.

Penso anche che la tua vita sarebbe molto più facile se si utilizza il tag <scope> bambino al tuo <dependency>

come citato dal Maven sito ufficiale:

1. di compilazione: Questo è l'ambito predefinito, usato se nessuno è specificato. Le dipendenze di compilazione sono disponibili in tutti i percorsi di classe di un progetto. Inoltre, tali dipendenze vengono propagate a progetti dipendenti.
2. fornito: Questo è molto simile alla compilazione, ma indica che ci si aspetta che il JDK o un contenitore forniscano la dipendenza in fase di esecuzione. Ad esempio, quando si crea un'applicazione Web per Java Enterprise Edition, si imposta la dipendenza sull'API servlet e le API Java EE correlate all'ambito fornito poiché il contenitore Web fornisce tali classi. Questo ambito è disponibile solo sul percorso di classe di compilazione e test e non è transitivo.
3. runtime Questo ambito indica che la dipendenza non è richiesta per la compilazione, ma è per l'esecuzione. È nel runtime e verifica i percorsi di classe, ma non il classpath di compilazione.
test
4. : questo ambito indica che la dipendenza non è richiesta per il normale utilizzo dell'applicazione ed è disponibile solo per la fase di compilazione e di esecuzione del test.
5. sistema: questo ambito è simile a quanto previsto, tranne che è necessario fornire il JAR che lo contiene esplicitamente. L'artefatto è sempre disponibile e non è cercato in un repository.
6. importazione: (disponibile solo in Maven 2.0.9 o successivo) Questo ambito viene utilizzato solo su una dipendenza di tipo pom nella sezione. Indica che il POM specificato deve essere sostituito con le dipendenze nella sezione di quella POM. Dal momento che vengono sostituiti, le dipendenze con un ambito di importazione in realtà non partecipano a limitare la transitività di una dipendenza.

Answer 2

ci sono alcuni link a documentazione di gestione delle dipendenze:

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html (tabella importend nella sezione "ambito delle dipendenze")

ci sono un articolo di dio in un giornale tedesco che descrivono la soluzione di dipendenze - qui ci sono l'arbitro BibTeX dell'articolo: http://www.bibsonomy.org/bibtex/2ef10bb1bc1be7806bc3fba53417bbd5f/funthomas424242

ci sono una sezione sul plugin di dipendenza nel libro Sonatype a: http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependency-plugin.html

Spero sia stato utile.