Maven 2.0.8 test resource loading
Hi!
I've read about the class path order changes in Maven 2.0.8 compared to earlier
releases and this is causing some issues in my builds so I wonder if there is a
best approach to this topic.
I've a class needing a resource file loaded from the class path. This file must
be a different one in the test scenario compared to the one when performing a
build.
To simplify, I've set up a small (web-)project simply holding a unitTest,
loading a resource from the classpath like this:
public void testResourceLoading(){
URL resURL =
TestClassLoading.class.getClassLoader().getResource(resource.txt);
assertNotNull(resURL);
System.out.println(ResURL: +resURL);
assertTrue(Haven't found the resource within test-classes!,
resURL.toString().endsWith(/target/test-classes/resource.txt));
}
When performing a mvn test with maven 2.0.7 the test passes, hence the
correct version of the file is loaded.
A test with maven 2.0.8 fails because the file in /target/classes/ is loaded.
I've read about the forkMode of the surefire plugin, so I tried to set this to
never, but then a test with maven 2.0.8 passes and the one with maven 2.0.7
fails!
Could anyone elaborate on how to deal with this situation?
Thanks in advance and best regards,
Kurt
Just for the sake of completeness, here's my pom.xml for this very simple
project:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdat.telbiomed.arc/groupId
artifactIdclassLoaderTest/artifactId
packagingwar/packaging
version1.0-SNAPSHOT/version
nameclassLoaderTest Maven Webapp/name
urlhttp://maven.apache.org/url
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
build
finalNameclassLoaderTest/finalName
resources
resource
directorysrc/main/resources/package//directory
filteringfalse/filtering
includes
includeresource.txt/include
/includes
targetPath//targetPath
/resource
/resources
testResources
testResource
directorysrc/main/resources/test/directory
filteringfalse/filtering
includes
includeresource.txt/include
/includes
targetPath//targetPath
/testResource
/testResources
!-- the test fails with maven 2.0.7 if these settings will be used, otherwise
with 2.0.8
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
forkModenever/forkMode
/configuration
/plugin
/plugins
--
/build
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Maven 2.0.8 test resource loading
Hi!
I've read about the class path order changes in Maven 2.0.8 compared to earlier
releases and this is causing some issues in my builds so I wonder if there is a
best approach to this topic.
I've a class needing a resource file loaded from the class path. This file must
be a different one in the test scenario compared to the one when performing a
build.
To simplify, I've set up a small (web-)project simply holding a unitTest,
loading a resource from the classpath like this:
public void testResourceLoading(){
URL resURL =
TestClassLoading.class.getClassLoader().getResource(resource.txt);
assertNotNull(resURL);
System.out.println(ResURL: +resURL);
assertTrue(Haven't found the resource within test-classes!,
resURL.toString().endsWith(/target/test-classes/resource.txt));
}
When performing a mvn test with maven 2.0.7 the test passes, hence the
correct version of the file is loaded.
A test with maven 2.0.8 fails because the file in /target/classes/ is loaded.
I've read about the forkMode of the surefire plugin, so I tried to set this to
never, but then a test with maven 2.0.8 passes and the one with maven 2.0.7
fails!
Could anyone elaborate on how to deal with this situation?
Thanks in advance and best regards,
Kurt
Just for the sake of completeness, here's my pom.xml for this very simple
project:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdat.telbiomed.arc/groupId
artifactIdclassLoaderTest/artifactId
packagingwar/packaging
version1.0-SNAPSHOT/version
nameclassLoaderTest Maven Webapp/name
urlhttp://maven.apache.org/url
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
build
finalNameclassLoaderTest/finalName
resources
resource
directorysrc/main/resources/package//directory
filteringfalse/filtering
includes
includeresource.txt/include
/includes
targetPath//targetPath
/resource
/resources
testResources
testResource
directorysrc/main/resources/test/directory
filteringfalse/filtering
includes
includeresource.txt/include
/includes
targetPath//targetPath
/testResource
/testResources
!-- the test fails with maven 2.0.7 if these settings will be used, otherwise
with 2.0.8
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
forkModenever/forkMode
/configuration
/plugin
/plugins
--
/build
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.8 test resource loading
In my opinion, the dependency on surefire 2.3.1+ is a required dependency since unit testing is broken when reading from the classpath. Can a Maven committer please add such notes to the 2.0.8 releases notes under Changes that may affect existing builds? Unfortunately referencing MNG-3118 is just not good enough since it doesn't propose how to resolve this common problem. Paul On Dec 7, 2007 3:20 PM, Wayne Fay [EMAIL PROTECTED] wrote: The problem seems to be within surefire. A new release 2.3.1 is being cut soon to address this issue. This is discussed in a few JIRAs: http://jira.codehaus.org/browse/MNG-3118 http://jira.codehaus.org/browse/SUREFIRE-61 http://jira.codehaus.org/browse/MNG-2365 Wayne On 12/7/07, Paul Benedict [EMAIL PROTECTED] wrote: The problem might be within the SureFire plugin? Maybe it requires an update to select the correct classpath for testing. Paul On Dec 7, 2007 2:36 PM, NicholasHall [EMAIL PROTECTED] wrote: I too have had this problem since upgrading to 2.0.8. I actually regressed to 2.0.7 until I can come up with a solution. In my case, I'm using a different hibernate.cfg.xml file in test than in main. In main, I'm expecting a JNDI datasource from the container, but my test version is configured for HSQLDB. I noticed after upgrading to 2.0.8 that my test cases fail because it's trying to get the JNDI datasource. I'm hoping there's a solution in the works out there. There doesn't appear to be much noise about this. MNG-3118 appears to fix this situation, so I find it ironic that it wasn't a problem until now. -- View this message in context: http://www.nabble.com/Maven-2.0.8-test-resource-loading-tf4961073s177.html#a14220128 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.8 test resource loading
The problem seems to be within surefire. A new release 2.3.1 is being cut soon to address this issue. This is discussed in a few JIRAs: http://jira.codehaus.org/browse/MNG-3118 http://jira.codehaus.org/browse/SUREFIRE-61 http://jira.codehaus.org/browse/MNG-2365 Wayne On 12/7/07, Paul Benedict [EMAIL PROTECTED] wrote: The problem might be within the SureFire plugin? Maybe it requires an update to select the correct classpath for testing. Paul On Dec 7, 2007 2:36 PM, NicholasHall [EMAIL PROTECTED] wrote: I too have had this problem since upgrading to 2.0.8. I actually regressed to 2.0.7 until I can come up with a solution. In my case, I'm using a different hibernate.cfg.xml file in test than in main. In main, I'm expecting a JNDI datasource from the container, but my test version is configured for HSQLDB. I noticed after upgrading to 2.0.8 that my test cases fail because it's trying to get the JNDI datasource. I'm hoping there's a solution in the works out there. There doesn't appear to be much noise about this. MNG-3118 appears to fix this situation, so I find it ironic that it wasn't a problem until now. -- View this message in context: http://www.nabble.com/Maven-2.0.8-test-resource-loading-tf4961073s177.html#a14220128 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.8 test resource loading
The problem might be within the SureFire plugin? Maybe it requires an update to select the correct classpath for testing. Paul On Dec 7, 2007 2:36 PM, NicholasHall [EMAIL PROTECTED] wrote: I too have had this problem since upgrading to 2.0.8. I actually regressed to 2.0.7 until I can come up with a solution. In my case, I'm using a different hibernate.cfg.xml file in test than in main. In main, I'm expecting a JNDI datasource from the container, but my test version is configured for HSQLDB. I noticed after upgrading to 2.0.8 that my test cases fail because it's trying to get the JNDI datasource. I'm hoping there's a solution in the works out there. There doesn't appear to be much noise about this. MNG-3118 appears to fix this situation, so I find it ironic that it wasn't a problem until now. -- View this message in context: http://www.nabble.com/Maven-2.0.8-test-resource-loading-tf4961073s177.html#a14220128 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: Maven 2.0.8 test resource loading
I too have had this problem since upgrading to 2.0.8. I actually regressed to 2.0.7 until I can come up with a solution. In my case, I'm using a different hibernate.cfg.xml file in test than in main. In main, I'm expecting a JNDI datasource from the container, but my test version is configured for HSQLDB. I noticed after upgrading to 2.0.8 that my test cases fail because it's trying to get the JNDI datasource. I'm hoping there's a solution in the works out there. There doesn't appear to be much noise about this. MNG-3118 appears to fix this situation, so I find it ironic that it wasn't a problem until now. -- View this message in context: http://www.nabble.com/Maven-2.0.8-test-resource-loading-tf4961073s177.html#a14220128 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
