Console Launcher should let you specify a module path to scan

[bowbahdoe]

Console Launcher should let you specify a module path to scan

[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.