2013-06-09 7 views
7

Widzę słoik z zakresem provided w mojej ścieżce klas podczas wykonywania testu. Biorąc pod uwagę definicję zakresu provided, nie spodziewałbym się, że słoik pojawi się w ścieżce klas podczas dowolnej fazy wykonywania.Z wyjątkiem "dostarczanych" zależności zakresu podczas fazy testowej?

Potwierdziłem, że zakres jest prawidłowy, korzystając z widoku "Hierarchia zależności" M2E. Ja już próbowałem za pomocą opcji w maven-surefire-pluginclasspathDependencyScopeExclude utrzymać zależność od pojawiać się, i to nie działa:

<build> 
    <pluginManagement> 
    <plugins> 
     <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-surefire-plugin</artifactId> 
     <version>2.14.1</version> 
     <configuration> 
      <!-- 
      We always want to exclude provided deps. I'm not sure why this 
      isn't the default. 
      --> 
      <classpathDependencyScopeExclude>provided</classpathDependencyScopeExclude> 
     </configuration> 
     </plugin> 
    </plugins> 
    </pluginManagement> 
</build> 

Oto definicja zależność w pytaniu:

POM nadrzędna:

<dependency> 
    <groupId>javax.ws.rs</groupId> 
    <artifactId>jsr311-api</artifactId> 
    <version>1.1.1</version> 
</dependency> 

Moduł POM:

<dependency> 
    <groupId>javax.ws.rs</groupId> 
    <artifactId>jsr311-api</artifactId> 
    <scope>provided</scope> 
</dependency> 

Czy to normalne, że słoik jest? Co mogę zrobić, aby go nie wyświetlać?

EDIT: Uruchomiłem mvn dependency:tree na macierzystym POM. Oto wynik dla danego projektu:

[INFO] ------------------------------------------------------------------------ 
[INFO] Building sibyl.transport.impl.http.server 0.0.1-SNAPSHOT 
[INFO] ------------------------------------------------------------------------ 
[INFO] 
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ sibyl.transport.impl.http.server --- 
[INFO] com.sigpwned.analytics:sibyl.transport.impl.http.server:jar:0.0.1-SNAPSHOT 
[INFO] +- com.sigpwned.analytics:sibyl.transport:jar:0.0.1-SNAPSHOT:compile 
[INFO] +- com.sigpwned.analytics:commons:jar:0.0.1-SNAPSHOT:compile 
[INFO] +- javax.ws.rs:jsr311-api:jar:1.1.1:provided 
[INFO] +- com.sun.jersey:jersey-server:jar:1.17.1:test (scope not updated to compile) 
[INFO] | +- asm:asm:jar:3.1:test 
[INFO] | \- com.sun.jersey:jersey-core:jar:1.17.1:test 
[INFO] +- com.sun.jersey:jersey-servlet:jar:1.17.1:compile 
[INFO] +- org.eclipse.jetty:jetty-servlet:jar:9.0.3.v20130506:test 
[INFO] | \- org.eclipse.jetty:jetty-security:jar:9.0.3.v20130506:test 
[INFO] |  \- org.eclipse.jetty:jetty-server:jar:9.0.3.v20130506:test 
[INFO] |  +- org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:test 
[INFO] |  +- org.eclipse.jetty:jetty-http:jar:9.0.3.v20130506:test 
[INFO] |  | \- org.eclipse.jetty:jetty-util:jar:9.0.3.v20130506:test 
[INFO] |  \- org.eclipse.jetty:jetty-io:jar:9.0.3.v20130506:test 
[INFO] +- com.sigpwned.analytics:sibyl.transport.impl.http.client:jar:0.0.1-SNAPSHOT:test 
[INFO] | \- org.apache.httpcomponents:httpclient:jar:4.2.5:test 
[INFO] |  +- org.apache.httpcomponents:httpcore:jar:4.2.4:test 
[INFO] |  +- commons-logging:commons-logging:jar:1.1.1:test 
[INFO] |  \- commons-codec:commons-codec:jar:1.6:test 
[INFO] \- junit:junit:jar:4.11:test 
[INFO] \- org.hamcrest:hamcrest-core:jar:1.3:test 

Ponownie, słoik z przewidzianym zakresem, że oczekują, aby nie pokazać się na ścieżce klasy, ale nie jest JAX-RS specyfikacji API, jak pokazano powyżej javax.ws.rs:jsr311-api:jar:1.1.1:provided. Wierzę, że to potwierdza, że ​​ta zależność występuje tylko w zakresie provided.

EDIT: Gdybym uruchomić test, tutaj jest wiersz polecenia, który pobiera uruchomić (od ps):

sigpwned  11771 0.0 1.2 4019788 100240 ?? S 10:58PM 0:05.92 /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/bin/java -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:59974 -Dfile.encoding=UTF-8 -classpath /Users/aboothe/Documents/workspaces/w2oanalytics/sibyl.transport.impl.http.server/target/test-classes:/Users/aboothe/Documents/workspaces/w2oanalytics/sibyl.transport.impl.http.server/target/classes:/Users/aboothe/Documents/workspaces/w2oanalytics/sibyl/sibyl.transport/target/classes:/Users/aboothe/Documents/workspaces/w2oanalytics/commons/target/classes:/Users/aboothe/.m2/repository/javax/ws/rs/jsr311-api/1.1.1/jsr311-api-1.1.1.jar:/Users/aboothe/.m2/repository/com/sun/jersey/jersey-server/1.17.1/jersey-server-1.17.1.jar:/Users/aboothe/.m2/repository/asm/asm/3.1/asm-3.1.jar:/Users/aboothe/.m2/repository/com/sun/jersey/jersey-core/1.17.1/jersey-core-1.17.1.jar:/Users/aboothe/.m2/repository/com/sun/jersey/jersey-servlet/1.17.1/jersey-servlet-1.17.1.jar:/Users/aboothe/.m2/repository/org/eclipse/jetty/jetty-servlet/9.0.3.v20130506/jetty-servlet-9.0.3.v20130506.jar:/Users/aboothe/.m2/repository/org/eclipse/jetty/jetty-security/9.0.3.v20130506/jetty-security-9.0.3.v20130506.jar:/Users/aboothe/.m2/repository/org/eclipse/jetty/jetty-server/9.0.3.v20130506/jetty-server-9.0.3.v20130506.jar:/Users/aboothe/.m2/repository/org/eclipse/jetty/orbit/javax.servlet/3.0.0.v201112011016/javax.servlet-3.0.0.v201112011016.jar:/Users/aboothe/.m2/repository/org/eclipse/jetty/jetty-http/9.0.3.v20130506/jetty-http-9.0.3.v20130506.jar:/Users/aboothe/.m2/repository/org/eclipse/jetty/jetty-util/9.0.3.v20130506/jetty-util-9.0.3.v20130506.jar:/Users/aboothe/.m2/repository/org/eclipse/jetty/jetty-io/9.0.3.v20130506/jetty-io-9.0.3.v20130506.jar:/Users/aboothe/Documents/workspaces/w2oanalytics/sibyl.transport.impl.http.client/target/classes:/Users/aboothe/.m2/repository/org/apache/httpcomponents/httpclient/4.2.5/httpclient-4.2.5.jar:/Users/aboothe/.m2/repository/org/apache/httpcomponents/httpcore/4.2.4/httpcore-4.2.4.jar:/Users/aboothe/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar:/Users/aboothe/.m2/repository/commons-codec/commons-codec/1.6/commons-codec-1.6.jar:/Users/aboothe/.m2/repository/junit/junit/4.11/junit-4.11.jar:/Users/aboothe/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar:/Users/aboothe/Downloads/eclipse/configuration/org.eclipse.osgi/bundles/350/1/.cp/:/Users/aboothe/Downloads/eclipse/configuration/org.eclipse.osgi/bundles/349/1/.cp/ org.eclipse.jdt.internal.junit.runner.RemoteTestRunner -version 3 -port 59973 -testLoaderClass org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader -loaderpluginname org.eclipse.jdt.junit4.runtime -classNames com.sigpwned.analytics.sibyl.transport.impl.http.server.HttpServerTransportTests 

Jeśli wyciągnąć ścieżkę klas, oto co to wygląda:

/Users/sigpwned/Documents/workspaces/siganalytics/sibyl.transport.impl.http.server/target/test-classes 
/Users/sigpwned/Documents/workspaces/siganalytics/sibyl.transport.impl.http.server/target/classes 
/Users/sigpwned/Documents/workspaces/siganalytics/sibyl/sibyl.transport/target/classes 
/Users/sigpwned/Documents/workspaces/siganalytics/commons/target/classes 
/Users/sigpwned/.m2/repository/javax/ws/rs/jsr311-api/1.1.1/jsr311-api-1.1.1.jar 
/Users/sigpwned/.m2/repository/com/sun/jersey/jersey-server/1.17.1/jersey-server-1.17.1.jar 
/Users/sigpwned/.m2/repository/asm/asm/3.1/asm-3.1.jar 
/Users/sigpwned/.m2/repository/com/sun/jersey/jersey-core/1.17.1/jersey-core-1.17.1.jar 
/Users/sigpwned/.m2/repository/com/sun/jersey/jersey-servlet/1.17.1/jersey-servlet-1.17.1.jar 
/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-servlet/9.0.3.v20130506/jetty-servlet-9.0.3.v20130506.jar 
/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-security/9.0.3.v20130506/jetty-security-9.0.3.v20130506.jar 
/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-server/9.0.3.v20130506/jetty-server-9.0.3.v20130506.jar 
/Users/sigpwned/.m2/repository/org/eclipse/jetty/orbit/javax.servlet/3.0.0.v201112011016/javax.servlet-3.0.0.v201112011016.jar 
/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-http/9.0.3.v20130506/jetty-http-9.0.3.v20130506.jar 
/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-util/9.0.3.v20130506/jetty-util-9.0.3.v20130506.jar 
/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-io/9.0.3.v20130506/jetty-io-9.0.3.v20130506.jar 
/Users/sigpwned/Documents/workspaces/siganalytics/sibyl.transport.impl.http.client/target/classes 
/Users/sigpwned/.m2/repository/org/apache/httpcomponents/httpclient/4.2.5/httpclient-4.2.5.jar 
/Users/sigpwned/.m2/repository/org/apache/httpcomponents/httpcore/4.2.4/httpcore-4.2.4.jar 
/Users/sigpwned/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar 
/Users/sigpwned/.m2/repository/commons-codec/commons-codec/1.6/commons-codec-1.6.jar 
/Users/sigpwned/.m2/repository/junit/junit/4.11/junit-4.11.jar 
/Users/sigpwned/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar 
/Users/sigpwned/Downloads/eclipse/configuration/org.eclipse.osgi/bundles/350/1/.cp/ 
/Users/sigpwned/Downloads/eclipse/configuration/org.eclipse.osgi/bundles/349/1/.cp/ 

EDIT: Po zbadaniu dokumentacji classpathDependencyScopeExclude, uznałem, że można jedynie wykluczyć compile, runtime i test zależności, a nie provided. To tłumaczy, dlaczego ta funkcja nie działa. Po wypróbowaniu sugestii z @hello poniżej, ustaliłem, że classpathDependencyExclude działa, gdy działa bezpośrednio z mavenem. Oto ścieżka klasy, że wyrwane z zamanifestować murowany jar za:

file:/Users/sigpwned/.m2/repository/org/apache/maven/surefire/surefire-booter/2.14.1/surefire-booter-2.14.1.jar 
    file:/Users/sigpwned/.m2/repository/org/apache/maven/surefire/surefire-api/2.14.1/surefire-api-2.14.1.jar 
    file:/Users/sigpwned/Documents/workspaces/siganalytics/sibyl/sibyl.transport.impl.http.server/target/test-classes/ 
    file:/Users/sigpwned/Documents/workspaces/siganalytics/sibyl/sibyl.transport.impl.http.server/target/classes/ 
    file:/Users/sigpwned/.m2/repository/com/siggroup/analytics/sibyl.transport/0.0.1-SNAPSHOT/sibyl.transport-0.0.1-SNAPSHOT.jar 
    file:/Users/sigpwned/.m2/repository/com/siggroup/analytics/commons/0.0.1-SNAPSHOT/commons-0.0.1-SNAPSHOT.jar 
    file:/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-server/9.0.3.v20130506/jetty-server-9.0.3.v20130506.jar 
    file:/Users/sigpwned/.m2/repository/org/eclipse/jetty/orbit/javax.servlet/3.0.0.v201112011016/javax.servlet-3.0.0.v201112011016.jar 
    file:/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-http/9.0.3.v20130506/jetty-http-9.0.3.v20130506.jar 
    file:/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-util/9.0.3.v20130506/jetty-util-9.0.3.v20130506.jar 
    file:/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-io/9.0.3.v20130506/jetty-io-9.0.3.v20130506.jar 
    file:/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-servlet/9.0.3.v20130506/jetty-servlet-9.0.3.v20130506.jar 
    file:/Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-security/9.0.3.v20130506/jetty-security-9.0.3.v20130506.jar 
    file:/Users/sigpwned/.m2/repository/com/sun/jersey/jersey-server/1.17.1/jersey-server-1.17.1.jar 
    file:/Users/sigpwned/.m2/repository/asm/asm/3.1/asm-3.1.jar 
    file:/Users/sigpwned/.m2/repository/com/sun/jersey/jersey-core/1.17.1/jersey-core-1.17.1.jar 
    file:/Users/sigpwned/.m2/repository/com/sun/jersey/jersey-servlet/1.17.1/jersey-servlet-1.17.1.jar 
    file:/Users/sigpwned/.m2/repository/com/siggroup/analytics/sibyl.transport.impl.http.client/0.0.1-SNAPSHOT/sibyl.transport.impl.http.client-0.0.1-SNAPSHOT.jar 
    file:/Users/sigpwned/.m2/repository/org/apache/httpcomponents/httpclient/4.2.4/httpclient-4.2.4.jar 
    file:/Users/sigpwned/.m2/repository/org/apache/httpcomponents/httpcore/4.2.4/httpcore-4.2.4.jar 
    file:/Users/sigpwned/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar 
    file:/Users/sigpwned/.m2/repository/commons-codec/commons-codec/1.6/commons-codec-1.6.jar 
    file:/Users/sigpwned/.m2/repository/com/siggroup/analytics/sibyl.transport/0.0.1-SNAPSHOT/sibyl.transport-0.0.1-SNAPSHOT-tests.jar 
    file:/Users/sigpwned/.m2/repository/junit/junit/4.11/junit-4.11.jar 
    file:/Users/sigpwned/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar 

Uwaga, jsr311-api.jar nie jest obecny. Powodzenie! Oto konfiguracja który pracował:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-surefire-plugin</artifactId> 
    <version>${maven-surefire-plugin.version}</version> 
    <configuration> 
    <!-- 
     We never want to include these API deps on an execution classpath. 
     I would think this is how the "provided" scope works - just 
     compile against the jar, and then I'll bring it myself at 
     execution time - but provided is only excluded during the runtime 
     phase, not the testing phase. So, we have to exclude all our 
     API JARs by hand. 
    --> 
    <classpathDependencyExcludes> 
     <classpathDependencyExclude>javax.ws.rs:jsr311-api</classpathDependencyExclude> 
    </classpathDependencyExcludes> 
    <includes> 
     <include>**/*Tests.*</include> 
    </includes> 
    </configuration> 
</plugin> 

Jednak to rozwiązanie ma nie wydają się działać na M2E. Oto ścieżka klasy jakie wyciągnął z ps podczas wykonywania testu przy użyciu M2E:

/Users/sigpwned/Documents/workspaces/siganalytics/sibyl/sibyl.transport.impl.http.server/target/test-classes 
    /Users/sigpwned/Documents/workspaces/siganalytics/sibyl/sibyl.transport.impl.http.server/target/classes 
    /Users/sigpwned/Documents/workspaces/siganalytics/sibyl/sibyl.transport/target/classes 
    /Users/sigpwned/Documents/workspaces/siganalytics/commons/target/classes 
> /Users/sigpwned/.m2/repository/javax/ws/rs/jsr311-api/1.1.1/jsr311-api-1.1.1.jar 
    /Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-server/9.0.3.v20130506/jetty-server-9.0.3.v20130506.jar 
    /Users/sigpwned/.m2/repository/org/eclipse/jetty/orbit/javax.servlet/3.0.0.v201112011016/javax.servlet-3.0.0.v201112011016.jar 
    /Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-http/9.0.3.v20130506/jetty-http-9.0.3.v20130506.jar 
    /Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-util/9.0.3.v20130506/jetty-util-9.0.3.v20130506.jar 
    /Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-io/9.0.3.v20130506/jetty-io-9.0.3.v20130506.jar 
    /Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-servlet/9.0.3.v20130506/jetty-servlet-9.0.3.v20130506.jar 
    /Users/sigpwned/.m2/repository/org/eclipse/jetty/jetty-security/9.0.3.v20130506/jetty-security-9.0.3.v20130506.jar 
    /Users/sigpwned/.m2/repository/com/sun/jersey/jersey-server/1.17.1/jersey-server-1.17.1.jar 
    /Users/sigpwned/.m2/repository/asm/asm/3.1/asm-3.1.jar 
    /Users/sigpwned/.m2/repository/com/sun/jersey/jersey-core/1.17.1/jersey-core-1.17.1.jar 
    /Users/sigpwned/.m2/repository/com/sun/jersey/jersey-servlet/1.17.1/jersey-servlet-1.17.1.jar 
    /Users/sigpwned/Documents/workspaces/siganalytics/sibyl/sibyl.transport.impl.http.client/target/classes 
    /Users/sigpwned/.m2/repository/org/apache/httpcomponents/httpclient/4.2.4/httpclient-4.2.4.jar 
    /Users/sigpwned/.m2/repository/org/apache/httpcomponents/httpcore/4.2.4/httpcore-4.2.4.jar 
    /Users/sigpwned/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar 
    /Users/sigpwned/.m2/repository/commons-codec/commons-codec/1.6/commons-codec-1.6.jar 
    /Users/sigpwned/Documents/workspaces/siganalytics/sibyl/sibyl.transport/target/test-classes 
    /Users/sigpwned/.m2/repository/junit/junit/4.11/junit-4.11.jar 
    /Users/sigpwned/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar 
    /Users/sigpwned/Downloads/eclipse/configuration/org.eclipse.osgi/bundles/350/1/.cp/ 
    /Users/sigpwned/Downloads/eclipse/configuration/org.eclipse.osgi/bundles/349/1/.cp/ 

Niestety jsr311-api.jar jest nadal.To prowadzi mnie do przekonania, że ​​odpowiedź na to pytanie (z tą odpowiedzią brzmi: "użyj classpathDependencyExcludes"), ale jest błąd w M2E. Uruchomiłem "Sprawdź aktualizacje" w Eclipse i nie znalazłem aktualizacji dla M2E, więc powinienem uruchomić najnowszą stabilną wersję. Zgłoszę błąd w M2E i zaktualizuję ten problem, aby każdy, kto znajdzie ten problem, mógł go śledzić.

EDIT: Ten problem był already raised z M2E, a odpowiedź wydaje się być „Murowany integracja jest poza zakresem M2E w tej chwili.” Niezbyt zachęcające. :/

+0

Być może zależność jest uwzględniona w innym miejscu jako zależność środowiska wykonawczego, a może coś innego importuje tę samą bibliotekę. Czy próbowałeś uruchomić polecenie drzewa zależności i wyszukać nazwę artefaktu w nim? –

+0

@EngineerDollery Nie wierzę, że tak jest. Dodałem kilka dodatkowych informacji do pytania, które wyjaśniają, dlaczego. Dziękuję za sugestię! – sigpwned

+0

@sigpwned Dlaczego nie publikujesz swoich cennych zmian jako odpowiedzi i akceptujesz? Dla mnie wyglądają one jak rozwiązanie problemu zamiast obecnie akceptowanej odpowiedzi. – fnt

Odpowiedz

7

Biorąc pod uwagę definicję zakresu provided, nie będę oczekiwać, że słoik pojawiać się na ścieżce klasy w każdej fazie realizacji.

To nie do końca zachowanie zakresu provided; patrz Dependency Scope. Zakres provided, wspólny z compile, dotyczy klas, które są niezbędne do kompilowania i testowania twoich zajęć. Gdyby ich brakowało podczas test, miałbyś NoClassDefFoundError.

Różnica pojawia się podczas pakowania i wdrażania, gdzie te artefakty są pomijane z war s przy założeniu, że twoje docelowe środowisko (na przykład kontener serwletu) dostarczy własną kopię tych samych klas.

+0

Najwyraźniej tak! Jak jednak wskazać mavenowi, że zależność jest przeznaczona tylko do kompilacji i nigdy nie powinna pojawiać się w ścieżce klas podczas dowolnej fazy wykonywania (w tym testu)? – sigpwned

+1

Znalazłem, że 'classpathDependencyScopeExclude' nie działa, ale [' classpathDependencyExcludes'] (http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#classpathDependencyExcludes) zrobiło: javax.ws.rs:jsr311-api Generalnie, nie ma możliwości, że odpowiada co jesteś po. Musisz wykluczyć go dla każdego celu. – Joe

+1

To działa! (Zauważ, że składnia to ' groupId: artifactId'). Przyjąłem twoją odpowiedź i zmieniłem moje pytanie. Dziękuję Ci! – sigpwned

Powiązane problemy