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.
>
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 avai
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 tes
Hi.
Surefire seems to include dependency artifacts with 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 ja
Frode Stokke wrote on Tuesday, July 03, 2007 10:36 AM:
> Hi.
>
> Surefire seems to include dependency artifacts with 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 dep
