Hi, as Wayne recommended I'ld try to have a look at the utility-jar to see if and where your file gets copied to. Just for the record: >From the Spring-ClasspathResource-constructor javadoc: A leading slash will be removed, as the ClassLoader resource access methods will not accept it. Also, as far as I know, maven resolves dependency-conflicts by an "nearest wins"-strategy, meaning the first resolved dependency(in your case stylesheet) will get preference and gets copied regardless of the conflict and the other resouces in question will just get ignored.
This "eclipse works but maven-build does not" sounds to me like maybe the surefire plugin does not add the utility-jar to the classpath of your test. Maybe your pom declares an exclusion for surefire-classpath? 2012/6/22 Barry Allen <[email protected]> > My apologies, but I'm afraid I spoke too soon.. I was running the test > successfully from Eclipse (Right click, Run As => JUnit) after removing the > duplicated xsl file from my project. Once I ran the Maven build, the test > fails inside the build with: > > java.io.FileNotFoundException: class path resource [myxsl.xsl] cannot be > resolved to absolute file path because it does not reside in the file > system: jar:file:<path...>/myxsl.xsl > > I am using this line in the test case to get the xsl: > > import org.springframework.core.io.ClassPathResource; > import org.springframework.core.io.Resource; > > ... > > Resource xslResource = new ClassPathResource("xslt/myxsl.xsl"); > > I also tried: > > Resource xslResource = new ClassPathResource("/xslt/myxsl.xsl"); > > But got the same error. > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Accessing-an-xsl-in-another-project-from-a-unit-test-case-tp5711637p5711805.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
