2018-03-17 16:09 GMT+01:00 Gintautas Grigelionis <[hidden email]>:
> I was wondering why junitlauncher task depended on all jars being present
> in Ant classpath with no possibility to set a separate classpath for the
... especially because ant -f fetch.xml seems to fetch both engines.
JUnit 5 introduces a new set of APIs which separates out the launching
aspects and the test identification and execution of those tests. As
such, the launcher APIs is what the junitlauncher task uses/requires.
Test engines on the other hand are pluggable and aren't necessary for
the junitlauncher task itself to be functional. Of course, the absence
of a test engine implies there won't be any tests that will get run.
However, which test engine to use is up to the users to decide and the
junitlauncher task itself doesn't need those libraries for itself.
As for the ability to have the JUnit 5 libraries, including the platform
launcher API jars, within the classpath element of the junitlauncher
task - it's not straightforward to accomplish for reasons noted in.
The JUnit task has very complex logic (for valid reasons) to support
this specific use case (since 1.7.0 of Ant). So at this point, that's
not something that I wanted to attempt or support. One thing however,
that I do plan to experiment and probably support in a subsequent
release is the ability to have the test engine library jars (and _not_
the JUnit 5 platform launcher API jars) within the classpath element of
the junitlauncher task. I had attempted this in the very first version
of this task, but ran into certain classloader issues which I did not
time to investigate, so decided to push it out for now.