|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Paul Gier - 23/Jul/07 10:10 AM
Simple patch that reverses the classpath ordering of classes and test-classes.
Makes sense. One thing I want to review is how this is used - might be better to externalise this from maven-project into surefire.
fixed in trunk at r559042 and 2.0.x branch at 559045
Hi, are you sure of the fix? Because I'm using maven 2.0.7 and test-classes was first in the classpath for almost a year now. I just tried with maven 2.0.8, doesn't work anymore. classes path seems to be first.
Is there a workaround? Because this ordering is indeed extremely useful. Hi, I have a similar problem. I need to mock a dependency library in my maven project, but maven puts the dependencies before the test-classes in the classpath. I see the same behaviour in both 2.0.7 and 2.0.8.
Henri, Andreas, I think you are suffering from problems with Surefire 2.3. The MavenProject.getTestClasspathElements() in Maven 2.0.8 now properly puts test-classes before classes (see code in svn or Maven's debug output when using -X). However, Surefire 2.3 itself causes a reordering of the class path in its SurefireBooter as reported in
I am seeing the following:
in mvn 2.0.7 the test resources are put before the main-resources (src/main/resources) as expected. Is this correct? I wouldnt expect it to happen. This caused my build to fail (connections made to a real environment ie stubs). Is this related to this 'feature'? KlassJan, read the other comments. It seems the problem is coming from Surefire. So you can wait for the fix to be released or build the plugin yourself (if you do so, I would be interested in knowing if it worked)
Henri,
Thanks, I was wondering if it were just the classes or the classes and the resources. So its both, I'll just revert to 2.0.7 and wait for the surefire. The surefire plugin was release today, but now all my tests fail on the 2.0.7. Isnt this a very serious regression?
In 2.0.7 my builds fail cause the surefire plugin is to new, 2.0.8 is not yet feasable ..... This mirroring of bugs in plugins is really really a very good idea. And than to solve it in a patch version. I quit with maven. Well, how should Maven have kept backward compatibility here? There can only be one class path order.
If Surefire 2.3.1 is not usable for you (I feel happy with it and Maven 2.0.8), you can lock your POM to Surefire 2.3 by explicitly specifying <version>2.3</version> in the corresponding <plugin> element. It just didn't feel like a patch version change. The fact that my build failed first with 2.0.8 and a week later with 2.0.7 doesn't feel right.
Backwards compatibility could be accomplished by mvn querying the surefire plugin version and construct the path with respect to that version. FYI, I was using mvn in an environment where upgrades are not allways possible/easy (...and all the dvl'ers had to upgrade), I know how to work around it, which meant a code change or an upgrade. In the end I advised everyone to upgrade to 2.0.8. I'll stop commenting on this issue since this is not really the place for it anyway. Thanks for the reaction though. In my 20 months experience with Maven, the test-classes always came before "classes". This is a feature that I heavily rely on. Could you please kindly document this behavior as part of the Maven/Surefire contract, so that the re-ordering problem does not reoccur? Many thanks in advance, Same to me Ceki. Days of work lost cause this.
Not to mention a regression issue in the surefire 2.3 with testng that only allows me to work with 2.4-SNAPSHOT And although I love maven my only way out is to migrate everything to ant if I don't want to lose the testing options in my C.I. machine. This just sad!! While I agree that having a documentation would be nice, it does not prevent the bugs from reoccurring. What you really want are tests. Therefore, you are invited to vote for MNG-2365 and
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
Test-classes should come before classes in the classpath
