RE: Surefire includes artifacts with scope 'provided' in the runtime classpath, is this correct?
frodesto wrote: Jörg Schaible wrote: Why is it a problem for you, that it is available in the classpath for the test? - Jörg Hi again. I see your point in that in many (most?) cases you actually would like the artifacts with scope 'provided' to be available in the classpath for the unit tests. However, in my case this causes problems since the javaee-api.jar cannot be used at runtime. It only provides the interface part of the Java EE APIs, but no implementation. If you try to use it at runtime, you will get java.lang.ClassFormatError and other weird exceptions. You have to use a real JavaEE implementation at runtime. In my case I am using the javaee-api to get access to the JMS API (javax.jms). I need the API classes to get my code to compile, but I cannot include this jar as a compile-time dependency since the app-server/JMS provider will provide the real JMS implementation. I my unit tests I need a real JMS implementation, and I am using ActiveMQ. ActiveMQ also bundles the javax.jms package, and this is the one I need to use at test-time. I have included the ActiveMQ jar as scope=test dependency. When I run the unit tests, I get a classpath with two different versions of the javax.jms package (a dummy implementation in javaee-api.jar and a real one in activemq-core.jar), and unfortunately it seems like the JVM chooses the wrong one. I need a way to make Surefire skip the javaee-api.jar from the test-time classpath or a way to control which version the JVM will use. Frode See http://forums.java.net/jive/thread.jspa?threadID=28648tstart=0 In my opinion, it is that the javaee-api.jar that is being used is borked. (At least in terms of use cases with Maven) In the interim, I suggest changing from using the javaee-api.jar with scope provided to using the individual jsr spec api jars with scope provided. (As the individual spec jars do not seem to be borked) -Stephen. -- View this message in context: http://www.nabble.com/Surefire-includes-artifacts-with-scope-%27provided%27-in-the-runtime-classpath%2C-is-this-correct--tf4016962s177.html#a11662554 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Surefire includes artifacts with scope 'provided' in the runtime classpath, is this correct?
frodesto wrote: In my case I am using the javaee-api to get access to the JMS API (javax.jms). I need the API classes to get my code to compile, but I cannot include this jar as a compile-time dependency since the app-server/JMS provider will provide the real JMS implementation. I my unit tests I need a real JMS implementation, and I am using ActiveMQ. ActiveMQ also bundles the javax.jms package, and this is the one I need to use at test-time. I have included the ActiveMQ jar as scope=test dependency. When I run the unit tests, I get a classpath with two different versions of the javax.jms package (a dummy implementation in javaee-api.jar and a real one in activemq-core.jar), and unfortunately it seems like the JVM chooses the wrong one. Most likely is that the javax.jms references one of the classes which should be provided by the container (which it has to pull from javaee-api.jar, which is borked, which causes a classloader error, which [i'm guessing] causes your problem) -- View this message in context: http://www.nabble.com/Surefire-includes-artifacts-with-scope-%27provided%27-in-the-runtime-classpath%2C-is-this-correct--tf4016962s177.html#a11662736 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Surefire includes artifacts with scope 'provided' in the runtime classpath, is this correct?
Frode Stokke wrote on Tuesday, July 03, 2007 10:36 AM:
Hi.
Surefire seems to include dependency artifacts with scope provided
in the classpath when running unit tests. Is this a bug? Shouldn't
such artifacts
only be included in the compile-time classpath?
Yes. Provided means, that the dependency will be available in the target
runtime environment. But you don't run your tests there, so it must be
available in the classpath running the test.
The output from 'mvn -X test' is shown below. The artifact
that is causing
problems for me is the javaee5-api.jar which should not be present in
the runtime classpath (should be substituted with a real Java EE 5
container jar, not shown in the example below).
+ Error stacktraces are turned on.
Maven version: 2.0.7
Java version: 1.6.0_01
OS name: windows xp version: 5.1 arch: x86
...
[DEBUG] Configuring mojo '
org.apache.maven.plugins:maven-surefire-plugin:2.2:test' -- ...
[DEBUG] (f) classpathElements = [...,
...\.m2\repository\javaee\javaee-api\5\javaee-api-5.jar, ...] ...
[DEBUG] (f) projectArtifactMap =
{javaee:javaee-api=javaee:javaee-api:jar:5:provided,
junit:junit=junit:junit:jar:3.8.1:test}
...
[DEBUG] -- end configuration --
...
[DEBUG] Test Classpath :
...
[DEBUG] ...\.m2\repository\javaee\javaee-api\5\javaee-api-5.jar
[DEBUG] ...\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar
Why is it a problem for you, that it is available in the classpath for the test?
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Surefire includes artifacts with scope 'provided' in the runtime classpath, is this correct?
Hi.
Surefire seems to include dependency artifacts with scope provided in the
classpath when running unit tests. Is this a bug? Shouldn't such artifacts
only be included in the compile-time classpath?
The output from 'mvn -X test' is shown below. The artifact that is causing
problems for me is the javaee5-api.jar which should not be present in the
runtime classpath (should be substituted with a real Java EE 5 container
jar, not shown in the example below).
+ Error stacktraces are turned on.
Maven version: 2.0.7
Java version: 1.6.0_01
OS name: windows xp version: 5.1 arch: x86
...
[DEBUG] Configuring mojo '
org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --
...
[DEBUG] (f) classpathElements = [...,
...\.m2\repository\javaee\javaee-api\5\javaee-api-5.jar, ...]
...
[DEBUG] (f) projectArtifactMap =
{javaee:javaee-api=javaee:javaee-api:jar:5:provided,
junit:junit=junit:junit:jar:3.8.1:test}
...
[DEBUG] -- end configuration --
...
[DEBUG] Test Classpath :
...
[DEBUG] ...\.m2\repository\javaee\javaee-api\5\javaee-api-5.jar
[DEBUG] ...\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar
RE: Surefire includes artifacts with scope 'provided' in the runtime classpath, is this correct?
Jörg Schaible wrote: Why is it a problem for you, that it is available in the classpath for the test? - Jörg Hi again. I see your point in that in many (most?) cases you actually would like the artifacts with scope 'provided' to be available in the classpath for the unit tests. However, in my case this causes problems since the javaee-api.jar cannot be used at runtime. It only provides the interface part of the Java EE APIs, but no implementation. If you try to use it at runtime, you will get java.lang.ClassFormatError and other weird exceptions. You have to use a real JavaEE implementation at runtime. In my case I am using the javaee-api to get access to the JMS API (javax.jms). I need the API classes to get my code to compile, but I cannot include this jar as a compile-time dependency since the app-server/JMS provider will provide the real JMS implementation. I my unit tests I need a real JMS implementation, and I am using ActiveMQ. ActiveMQ also bundles the javax.jms package, and this is the one I need to use at test-time. I have included the ActiveMQ jar as scope=test dependency. When I run the unit tests, I get a classpath with two different versions of the javax.jms package (a dummy implementation in javaee-api.jar and a real one in activemq-core.jar), and unfortunately it seems like the JVM chooses the wrong one. I need a way to make Surefire skip the javaee-api.jar from the test-time classpath or a way to control which version the JVM will use. Frode -- View this message in context: http://www.nabble.com/Surefire-includes-artifacts-with-scope-%27provided%27-in-the-runtime-classpath%2C-is-this-correct--tf4016962s177.html#a11421886 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
