You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benjamin Bentmann <be...@udo.edu> on 2008/12/17 18:26:53 UTC
Re: Decoupling from Compilation was: sometimes too much help is not
helping - r725533
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
?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Decoupling from Compilation
Posted by Benjamin Bentmann <be...@udo.edu>.
Oleg Gusakov wrote:
> Test performance: 100s of millis added by the compiler do not add too
> much of a delay; the compilation unit is a 2-liner.
Yep, it's surely of minor concern for the Mercury tests themselves. But
just imagine a penalty of about 1 sec and scale this by 250 and you get
an idea what other test suites are spending their time on...
> Did I sound convincing?
You don't need to, I was merely making a suggestion, you're the
maintainer ;-).
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Decoupling from Compilation
Posted by Oleg Gusakov <ol...@gmail.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Decoupling from Compilation was: sometimes too much help is not
helping - r725533
Posted by Oleg Gusakov <ol...@gmail.com>.
Herve,
Hervé BOUTEMY wrote:
> Le mercredi 17 décembre 2008, Benjamin Bentmann a écrit :
>
>> 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
>> ?
>>
> just for the record, I did such tests:
>
> 1. in Maven Ant Tasks: see sample.build.xml target "test-deps-order", which is
> based on <pathconvert> task
>
> 2. in MNG-1412 IT, with java code getResources( "META-INF/MANIFEST.MF" )
>
>
You suggestion duly noted :)
I think that testing entire workflow end to end at least once in UTs is
crucial. I don't abuse it - in all other unit tests I just resolve
artifacts and check for their presence in the local repository, which is
cleaned before every test. But doing full compile once is essential.
I am exploring the last problem - pgp read validation fails on Vista,
but works everywhere else, including WinXP.
Thanks,
Oleg
> Regards,
>
> Hervé
>
>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
Re: Decoupling from Compilation was: sometimes too much help is not helping - r725533
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mercredi 17 décembre 2008, Benjamin Bentmann a écrit :
> 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
> ?
just for the record, I did such tests:
1. in Maven Ant Tasks: see sample.build.xml target "test-deps-order", which is
based on <pathconvert> task
2. in MNG-1412 IT, with java code getResources( "META-INF/MANIFEST.MF" )
Regards,
Hervé
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org