Console Launcher should let you specify a module path to scan

[bowbahdoe]

Right now, best I can figure, the way to use --scan-modules is to add your application's modules to the module path of the JVM running the console launcher.

I.E.

    java \
        --module-path libs:build/jar \
        --add-modules org.junit.platform.console,web.hello.test,web.util.test \
        --module org.junit.platform.console \
        execute \
          --select-module web.hello.test \
          --select-module web.util.test \
          --reports-dir build/junit

It would be nice if the part where the launching of the console was configured didn't interact with where i was telling it to look for tests.

I.E. I kinda want

 junit execute --module-path libs:build/jar execute --scan-modules

To be an option, but it isn't possible to wrap up java -jar junit-platform-console-standalone.jar into an alias on account of needing to add these options on the jvm.

(similar, but less pressing, concerns about jacoco via the cli)

Deliverables

• [Module Path Can be configured to the right of execute]

[sormuras]

The console launcher already has:

RUNTIME CONFIGURATION

      -cp, --classpath, --class-path=PATH
                             Provide additional classpath entries -- for example, for adding
                               engines and their dependencies. This option can be repeated.

You suggest to add:

      --module-path=PATH
                             Provide additional module-path entries -- for example, for adding
                               engines and their dependencies. This option can be repeated.

Right?

The underlying issue is that java -jar APP.jar always launches applications on the class-path; i.e. in the unnamed module. That's why you need to resort to the long-form version as shown in your initial snippet. Which could be written a bit shorter:

    java --module-path libs:build/jar \
        --add-modules ALL-MODULE-PATH \ // make all modules part of the module graph
        --module org.junit.platform.console \  // root module is added automatically
        execute \
          --scan-modules \ // let junit engines find tests in all modules
          --reports-dir build/junit

Now, starting off on the class-path, some code in JUnit needs to figure out how to create a module layer at runtime in order to match the configuration the user wants: which could be a combination of all module system related options java offers. Which include: --module-path, --add-exports, --add-modules, --add-opens, --limit-modules, --patch-module, --upgrade-module-path``. Thus, when adding--module-path` to the set of JUnit's console options, we should also consider adding some or all others. And this can turn into a maintainance burden.

I'd rather see java to support an optional modular launcher protocol where java --multi-module-jar APP.jar would a) run on the module path and b) support running with multi-module JARs where many named modules are packaged into a single file.

[sormuras]

In addition to the manual and command-line centric "add test module into the graph configuration" above, it would be interesting to explore a programmatic approach using Java's ServiceLoader SPI. Analog to what Testable is for @Test methods - you would make your test modules provide a SelectModuleForTesting implementation which then is loaded by the JUnit Platform via uses SelectModuleForTesting;.

With that in place, no extra configuration is needed on the command-line - not left, nor right of execute.