Replies: 6 comments 4 replies
-
If you where previously using -Dtest=.... on the root level of your build tree it might now be necessary to also include
for your eclipse-plugin packaged project if they do not match anything (the error message is a bit misleading, this is tracked in SUREFIRE-1910). But |
Beta Was this translation helpful? Give feedback.
-
Thanks for the fast reply! I don't get how this Here's the result of executing with
I hope that tells you something that you can tell me then ;-) |
Beta Was this translation helpful? Give feedback.
-
I attach the entire console output file... |
Beta Was this translation helpful? Give feedback.
-
Hmm, that is interesting! Now I notice that these tests have not been executed at all formerly. Unfortunately I'm not Maven'ish enough to see how to fix the problem. Especially since all of this (without any changes in my configs) used to work for ages ;-( If I get you right, you're suggesting that now the Please note that none of my POMs contains the string "maven-surefire"... |
Beta Was this translation helpful? Give feedback.
-
So the 2.4 relnotes say "From now on [...] one is able to execute unit-tests with maven-surefire" which sounds reasonable to me. I don't fully understand the motivation and the consequences because, apparently I've never had the need or desire to use maven-surefire. Again, that string does not occur in any of my POMs, and never did. From that sentence I would expect that I'd have to add some POM markup to use maven-surefire. But it appears that now it kicks in even without asking for it. Is that true? So I understand you're suggesting to disable all maven-surefire tests with this:
Then I get dozens of warnings like "[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing". Kind of makes sense, but I've never asked for maven-surefire. So I've never specified a version for it (even though it appears that currently maven-surefire-plugin:2.22.2 is used). What version should I pick now?
Believe me, it has a good reason ;-) |
Beta Was this translation helpful? Give feedback.
-
Ok, I added another xml block under pluginManagement in the parent pom:
That seems to fix all my problems now. The pleasure of convention over configuration has always been a mystery for me. Now, in the light of changing conventions, it looks even worse to me ;-( But thanks for your help, anyways! |
Beta Was this translation helpful? Give feedback.
-
Recently I had to upgrade the Tycho version that's used in the CDO build and now I notice that failed tests start to make the entire build FAILED (instead of marking it UNSTABLE).
I think that's the default behavior of Maven, but I've always had this option in the parent POM:
It doesn't seem to have the expected effect anymore, though.
Now I also tried the
-fn
command line argument, but it seems to make no difference, either.Any ideas?
Beta Was this translation helpful? Give feedback.
All reactions