Part I - Introduce ModuleUtils with ClassFinder SPI #1061
Conversation
sormuras
changed the title
sormuras
force-pushed
the
module
branch
8 times, most recently
from
f1e959d to
eb40607
Compare
| /** | ||
| * Return list of classes found in the named module that may contain testable methods. | ||
| * | ||
| * @param moduleName name of the module to inspect or {@code ALL-MODULE-PATH} |
There was a problem hiding this comment.
I think having two separate methods, e.g. findAllClassesInModule() and findAllClassesInModulePath(), would be a cleaner. Thoughts?
There was a problem hiding this comment.
Having two methods makes sense here, because we have two different selectors in the launcher part. The blue-print where I took the special module name "ALL-MODULE-PATH" from only has a single command line option, namely: --add-modules. There is no --add-all-module-path or in our world: --scan-module-path.
tl;dr: Two separate methods are good - and remove the special module name "ALL-MODULE-PATH".
| "EXPERIMENTAL: Select single module for test discovery. This option can be repeated.") // | ||
| .withRequiredArg() // | ||
| .describedAs("module name"); | ||
|
|
There was a problem hiding this comment.
Should we also add support in the Vintage engine?
There was a problem hiding this comment.
Mh? Vintage should support both new selectors. If it doesn't then something was lost in rebasing to master.
There was a problem hiding this comment.
Find vintage-affecting changes below, around https://github.com/junit-team/junit5/pull/1061/files#diff-5e437a25c16596592cf66086916f6fed
| List<Class<?>> classes = new ArrayList<>(); | ||
|
|
||
| logger.config(() -> "Loading auto-detected class finders..."); | ||
| int serviceCounter = 0; |
There was a problem hiding this comment.
We could limit the single service implementation to be our own ... by comparing the class name or some other "magic ID". Or is it okay to allow third-party implementations here? Thoughts?
This commit includes the service providing interface `ModuleClassFinder` in package `org.junit.platform.commons.util`. Its default implementation will rely on Java 9 features introduced by the Java Platform Module System. The usage of the new module selection options on Java 8 will result in no-op as there is no module system in place. Summary of changes: * Add ModuleSelector to the Platform discovery package. * Add ModuleSelector to the Jupiter discovery package. * Add ModuleSelector to the Vintage discovery package. * Add ModuleUtils to the platform commons utilities toolbox. * Add option `--select-module` to the console launcher. * Add option `--scan-module-path` to the console launcher. Addresses #425
|
Superseded by #1087 |
ghost
removed
the
Overview
This PR prepares the support for selecting Java 9 modules for test discovery.
Basic idea: publish a
String-based service providing interface for naming module(s) of interest and let an explicit module register a service implementation for actually finding classes in the module graph at runtime. This service implementation should be hosted in a different (sub-) project, likejunit-platform-commons-jpms. See #1057At runtime, using Java 9, the user can add the
org.junit.platform.commons.jpmsmodule to the module-path and specify which module he wants to test. Themodsdirectory contains the JUnit 5 artifacts (loaded as automatic modules), theorg.junit.platform.commons.jpmsmodule, the application modules (tested objects), and the test modules (classes with@Testannotated methods):New Console Launcher Options
--scan-module-pathScan all modules on the runtime boot module-path for test discovery.
See http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-September/013180.html for details.
-oor--select-modulewith single argument<module name>Select single module for test discovery. This option can be repeated.
Same runtime boot module-path as above, but only the test classes of the named modules are selected.
TODO
--scan-module-path [entry1[:entry_n]]and delegates to theModuleFinderSelectorSee http://download.java.net/java/jdk9/docs/api/java/lang/module/ModuleFinder.html
I hereby agree to the terms of the JUnit Contributor License Agreement.
Definition of Done
@APIannotations