2014-07-04 18 views
5

quando corro "dipendenza mvn: albero" per il mio progetto mostra la seguente:Maven porta "test" dipendenza transitiva come "compilazione"

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ xxxxx --- 
[INFO] com.xxx.xxx:xxxxx:war:3.1.0-SNAPSHOT 
... 
[INFO] +- commons-configuration:commons-configuration:jar:1.5:compile 
[INFO] | \- commons-beanutils:commons-beanutils-core:jar:1.7.0:compile 
[INFO] +- org.seleniumhq.selenium:selenium-api:jar:2.34.0:test 
[INFO] | +- com.google.guava:guava:jar:14.0:test 
[INFO] | \- org.json:json:jar:20080701:test 
[INFO] +- org.seleniumhq.selenium:selenium-htmlunit-driver:jar:2.34.0:test 
[INFO] | +- org.seleniumhq.selenium:selenium-remote-driver:jar:2.34.0:test 
[INFO] | | +- cglib:cglib-nodep:jar:2.1_3:test 
[INFO] | | +- net.java.dev.jna:jna:jar:3.4.0:test 
[INFO] | | \- net.java.dev.jna:platform:jar:3.4.0:test 
[INFO] | \- net.sourceforge.htmlunit:htmlunit:jar:2.12:test 
[INFO] |  +- org.apache.commons:commons-lang3:jar:3.1:test 
[INFO] |  +- org.apache.httpcomponents:httpmime:jar:4.2.3:test 
[INFO] |  +- net.sourceforge.htmlunit:htmlunit-core-js:jar:2.12:test 
[INFO] |  +- xerces:xercesImpl:jar:2.10.0:test 
>>>[INFO] |  | \- xml-apis:xml-apis:jar:1.4.01:compile 
[INFO] |  +- net.sourceforge.nekohtml:nekohtml:jar:1.9.18:test 
[INFO] |  +- net.sourceforge.cssparser:cssparser:jar:0.9.9:test 
[INFO] |  | \- org.w3c.css:sac:jar:1.3:test 
[INFO] |  \- org.eclipse.jetty:jetty-websocket:jar:8.1.9.v20130131:test 
[INFO] +- org.seleniumhq.selenium:selenium-firefox-driver:jar:2.34.0:test 
... 

come si vede sulla linea marcata, XML-apis ha un ambito di "compilazione" e come risultato è impacchettato in un file .war. Perché potrebbe accadere?

Più interessante accade solo durante l'utilizzo di Java5, per Java6 la dipendenza viene visualizzata come "test".

Maven versione: 3.0.4

+0

Non 'xml-api' appare altrove come un'altra dipendenza? Le dipendenze del test –

+0

non saranno mai incluse in una guerra tranne che tu hai fatto qualcosa di strano. Si prega di mostrare il file pom. – khmarbaise

+0

@khmarbaise Lo so, ma per qualche ragione ce l'ho! Il file pom è abbastanza grande, ci sono diversi genitori genitore ... Non ho provato ad estrarre un campione minimo di codice, piuttosto noioso, ma assolutamente niente di speciale sulla dipendenza da 'selenium-htmlunit-driver', dichiarata come al solito. – kan

risposta

3

Se si dà un'occhiata a xercesImpl contiene una dipendenza per xml-apis: XML-API: vaso: 1.4.01: compilare con lo scopo compilare in modo che la visualizzazione di dipendenza il plugin è corretto L'utilizzo di -Dverbose farà le cose come scritto nei documenti:

Se includere nodi omessi nell'albero di dipendenza serializzato.

Oltre a quanto sopra, una dipendenza di test come nel tuo caso non viene mai inserita in un file di guerra.

Ci deve essere un altro fonte della stessa dipendenza che provoca la confezione in guerra

Inoltre il cambiamento di comportamento in relazione con l'aggiunta di esplicite xml-apis al vostro pom è una prova supplementare per questo.

+0

Non penso che tu abbia letto la mia domanda con la massima attenzione. Se dai un'occhiata a qualsiasi altra dipendenza da test, ad es. htmlunit, ha tutte le sue dipendenze come compilate, ma solo xml-apis viene visualizzato come 'compile'. '-Dverbose' dovrebbe includere solo i nodi omessi (sì, succede), ma nel mio caso sta cambiando anche l'ambito. E il '.jar' è impacchettato in guerra. Qualche idea su come trovare l '"altra fonte"? La mia conoscenza di Maven mi dice che non ci sono altre fonti. – kan

+0

Devi iniziare dal tuo artefatto di guerra e vedere tramite la dipendenza da mvn: albero da cui provengono tutti gli artefatti. – khmarbaise

+0

Il frammento dell'output dell'albero è nella mia domanda. L'unica fonte che vedo è il 'selenium-htmlunit-driver'. E se io '' the 'xml-apis' dal driver, il dep scompare dall'albero. – kan

0

Ho avuto un problema simile.

Nel mio caso una voce nel dependencyGestione di un padre gen imposta l'ambito del manufatto dipendente da compilare. In realtà ho omesso il tag scope che effettivamente equivale a impostarlo per la compilazione. Cambiando per fornito aiutato. Sembra che l'ambito in dependencyManagement abbia la precedenza sull'ambito transitivo. Il che ha senso ma può ancora causare confusione quando tutto ciò che si voleva fare è definire la versione.

In realtà non era difficile da individuare: guardando l'efficace pom ha mostrato la voce dependencyManagement.

3

Studiare l'output del seguente comando Maven.

mvn -X dependency:tree -Dverbose 

Questo dovrebbe dirvi perché Maven ha aggiornato lo scope da test a compilazione.

Problemi correlati