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]
