Hi John, You're right! I had thought about doing it this way but discarded it because it was just an extra step. Btu you're completely right, it makes the build more predictable and this is a good thing. Thanks for convincing me! :-)
I was trying to think about other uses case but I was not able to come up with any good one ;-) Let's wait till there's one... -Vincent > -----Original Message----- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: mardi 12 avril 2005 17:16 > To: Maven Developers List > Subject: Re: [M2] Need for 2 test resource dirs? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This is just my 2 cents, but I've always found it pretty easy to do > something similar to: > > ClassLoader cloader = Thread.currentThread().getContextClassLoader(); > URL resource = cloader.getResource("/classpath/relative/path"); > > File theFileIWantToUse = new File(resource.getPath()); > > Since you know that path to be in the test resources, it shouldn't have > a problem resolving it to a file when you need it... > > Is there some reason for explicitly excluding some resources from the > classpath (are they getting in the way of legitimate test/class > resources)? > > As for adding a convenience method to retrieve a file from > external-resources, I'd be a little worried about tethering my test > classes to maven in this case. I've often seen the case where a test > expects to be run from a particular ${user.dir} and will break if it > isn't, due to relative pathing problems. Additionally, I've seen the > case where running a test in an IDE results in a different ${user.dir} > being used than what maven might do. So there is a question of > consistency if you're going to offer that type of method or whatever to > help tests resolve those files. > > I'd also be a little hesitant to offer this type of facility through > surefire, because then you have to approximate it in your IDE if you > want to run the test from there...or any other test harness which would > otherwise be capable of running that test, for that matter. > > Again, this is just some food for thought. If you have a use case where > the aforementioned 3 lines of code wouldn't suffice, can you explain it > a little more? I'm interested in covering the bases here, but don't want > to cross the line into code that's unpredictable if we can avoid that. > > Thanks, > > john > > Vincent Massol wrote: > > Hi, > > > > I'm trying to convert the Cargo build to m2. I have some junit tests > that > > require external resources like WARs, EARs. I have initially put them in > > src/test/resources but I'm wondering if this is the right place. > > > > Indeed, resources put in src/test/resources will get copied to the test > > execution classpath which is not required for my junit tests. They need > a > > reference to the File objects. > > > > Thus I'm wondering if there isn't the need for 2 standard test resource > > dirs: > > > > 1/ src/test/resources > > 2/ src/test/resources-external (or some other name) > > > > 1/ would get copied to the test CP while 2/ would not. > > > > Also, we could add a default system property in the surefire plugin so > that > > tests can easily get a reference object pointing to > > src/test/resources-external. > > > > What's m2 developer's view on this? > > > > Thanks > > -Vincent > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFCW+YtK3h2CZwO/4URAkAKAKCcax9u7Z92vO81I8hK1lm1oF0sBQCgpE/1 > orhZ7bF/6EvDBRsJ1AjZAVw= > =0rvF > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > 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]
