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]
