On Wed, Sep 5, 2018 at 6:49 PM Tibor Digana <tibordig...@apache.org> wrote:
> >> Yes but the platform and engine are transitive, right? > Yes. We can grab the classpath from the forked jvm via Jconsole and we > should see these artifacts. > > @Christian > what happens when you just add new Engine with another version to the POM's > dependencies or plugin's dependencies. > The old version of JUnit5 Engine is overridden? > > We should decide which way is not error prone from the users perspective. > WDYT? > > What happens in Surefire today needs some investigations... I was sure yesterday and earlier today, but had to partly revert changes in our sample projects to actually force Surefire to find and execute tests. See [1] for the changes I made. I fear that now both versions, 1.2.0 and 1.3.0, do land on the classpath now... [1] https://github.com/junit-team/junit5-samples/commit/6c81972c691a7d055d895953eda5cefead8dc541 There are two debug statements from Surefire I don't understand. They look like: ... [DEBUG] test(compact) classpath: test-classes classes junit-jupiter-api-5.3.0.jar apiguardian-api-1.0.0.jar opentest4j-1.1.0.jar junit-platform-commons-1.3.0.jar junit-jupiter-params-5.3.0.jar junit-jupiter-engine-5.3.0.jar junit-platform-engine-1.3.0.jar ----... T E S T S ----... [DEBUG] boot(compact) classpath: surefire-booter-2.22.0.jar surefire-api-2.22.0.jar surefire-logger-api-2.22.0.jar test-classes classes junit-jupiter-api-5.3.0.jar apiguardian-api-1.0.0.jar opentest4j-1.1.0.jar junit-platform-commons-1.3.0.jar junit-jupiter-params-5.3.0.jar junit-jupiter-engine-5.3.0.jar junit-platform-engine-1.3.0.jar surefire-junit-platform-2.22.0.jar junit-platform-launcher-1.2.0.jar junit-platform-engine-1.2.0.jar junit-platform-commons-1.2.0.jar ... The first one "test" looks good, the second one "boot" doesn't... You may reproduce it by cloning " https://github.com/junit-team/junit5-samples"; and running "mvn clean test -X" in "junit5-jupiter-starter-maven". Now to what should happen: 1. User-defined artifacts always win. 2. Platform and Engines are different products a need to agree on a minimal Platform version. 3. Platform versions are backwards compatible. 4. The highest Platform version "in the stack" wins. 5. The presence of an API may imply an associated Engine artifact and version. (Jupiter API -> 99% Jupiter Engine) 6. The presence of an API may imply running a Surefire provider -- but also could handled by the JUnit Platform (provider). E.g. seeing TestNG artifact could mean that the user wants the JUnit Platform with TestNGine [2] to find and run tests. The list is far from complete. Cheers, Christian [2]
