I'd go with (1). I expect it will be clear enough why it's failing so
people will pick up the new usage fast enough. Can you mention the
"failIfNoTests=false" flag in the error message? (I assume the true is
a typo below?)
(3) is a possibility, but you can't really detect if tests are run at
"some point" as you say other than externally gathering the info in
surefire by aggregating the results. Sounds like more work than its
worth.
- Brett
On 11/12/2007, at 7:02 AM, Dan Fabulich wrote:
SUREFIRE-350 suggests that "if test parameter is provided, and no
match is found, an error should occur, not a successful build with 0
tests." That made sense to me, so I checked in a fix in revision
597952.
However, I discovered that this broke a certain maybe-standard
usage: if you've got a parent aggregator POM and two children "foo"
and "bar" running in a reactor, you used to be able to say -
Dtest=BarTest; we'd compile foo and run no tests in foo, then run
BarTest in bar.
This usage very convenient, because you don't have to know that
BarTest is in the bar module; you can just kick off the tests from
the root module and run them in whatever module happens to contain
them. You could also run multiple individual tests separated by
commas in multiple projects.
Now, if you try to run that line from the parent, you'll get a build
failure in foo, because BarTest isn't defined in foo.
I can think of a number of different possible options here.
1) Leave the code as is. Just because it's convenient doesn't mean
it's important and we have to preserve it.
2) Go back and "unfix" SUREFIRE-350.
Notably, in order to fix SUREFIRE-350, I added a new plugin
parameter called failIfNoTests, which would fail if no tests were
run. (It seemed imaginable that somebody would want to turn that on
in a variety of cases, not just in the -Dtest case.)
If I were to unfix SUREFIRE-350 it'd still be possible to get a
build failure, if you wanted one really badly, by saying "mvn test -
Dtest=FooTest -DfailIfNoTests=true".
It's not pretty, but perhaps it's an acceptable compromise.
3) Try to add code that detects the reactor case and handles it. I
think it's not that hard to detect whether a given invocation of
SurefirePlugin is running in a reactor (though I don't actually know
how off-hand). But how could I detect the case that this is meant
to help, where you accidentally had a typo? There's no way to
detect whether a test got run *at some point* in the reactor, is
there?
-Dan
