Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 7.5.2, 7.5.3, 7.5.4, 7.6.0, 7.6.1, 8.0.3, 8.0.4, 8.1.0
-
Component/s: Maven
-
Labels:None
-
Environment:HideApache Maven 3.0.4 (r1232337; 2012-01-17 19:44:56+1100)
Maven home: /usr/local/Cellar/maven/3.0.4/libexec
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.3", arch: "x86_64", family: "mac"ShowApache Maven 3.0.4 (r1232337; 2012-01-17 19:44:56+1100) Maven home: /usr/local/Cellar/maven/3.0.4/libexec Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x", version: "10.7.3", arch: "x86_64", family: "mac"
-
Testcase included:yes
-
Number of attachments :
Description
The 7.5.2 and 8.0.3 releases of the jetty-maven-plugin have broken the useTestClasspath and/or useTestScope options.
The attached sample project illustrates the issue through a couple of JUnit test cases which use httpclient to connect to a jetty instance started through the maven plugin (using Class.forName to resolve classes from different scopes).
I believe the problem is due to using the combination of the following in JettyRunMojo.java:
/* * @requiresDependencyResolution compile+runtime */
and
for ( Iterator<Artifact> iter = projectArtifacts.iterator(); iter.hasNext(); ) { // snip if (((!Artifact.SCOPE_PROVIDED.equals(artifact.getScope())) && (!Artifact.SCOPE_TEST.equals( artifact.getScope()))) || (useTestClasspath && Artifact.SCOPE_TEST.equals( artifact.getScope()))) { } }
It appears that the for loop is assuming all artifacts will be available, and attempting to filter out the test dependencies if useTestScope is specified. However, since the @requireDependencyResolution doesn't include +test, these aren't available.
I haven't had a chance to verify this (hence no patch to offer just yet) - but I'll try and get something sorted out to confirm this in the next few days (unless someone on the other end can verify ahead of time).
Martin,
Which version of maven are you using? I tried your test case and it seems to work for me with no errors produced, so I suspect it is a difference of maven version. My version is 3.0.3.
That said, it may be better if I change the dependencyResolution to "test" instead ... I'll have a read and fiddle with that and get back to you.
Jan