Benjamin Bentmann wrote:
Oleg Gusakov wrote:
Unit tests were using those jars to compile test code.
Just a technical question: Is it actually required/desirable to really
compile code during the tests?
Over in the Maven core ITs, running the Compiler (or Surefire) Plugin
was the classical approach to test dependency resolution. IMHO, this
approach adds
a) unnecessary coupling with external components
b) unnecessary complexity to the tests
not to mention the performance penalty.
To come back to Mercury, you are now about to chase down why the
compiler isn't found (MERCURY-61). But as far as I understand the Ant
tasks are concerned about dependency resolution, i.e. getting JARs,
not compilation.
So, wouldn't it be feasible to
1) Have the Ant tasks resolve the dependencies
2) Dump the resulting class path to a file (<echo>, custom test task)
3) Have the test controller (and not a compiler) verify the
order/contents of the class path by reading that file
?
This will prove only so much. All my previous experience says that if
there is a small crack an error can squeeze through, it will :) This
task is supposed to provide a compiler with a classpath, if I start
interpreting the path - I might do it differently from the compiler and
allow an error.
So - if this is supposed to give compiler a classpath - let compiler be
the judge. I hear your "unnecessary complexity to the tests" argument,
but I think that long term it's s lesser price to pay, compared to a
possibility of an error, undetectable without a compiler.
Test performance: 100s of millis added by the compiler do not add too
much of a delay; the compilation unit is a 2-liner.
Did I sound convincing?
Oleg
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org