stephan-herrmann
commented
12 months ago the de-facto standard is to define an additional module-info.java file in src/test/java that should be declared open and has a test specific identifier and requires the main module from src/main/java/module-info.java.
It's a pity, that no real standard has emerged, and so we are left with various concepts that cannot easily be reconciled.
If I understand the maven approach correctly, then src/main/java and src/test/java should be seen as two regular modules (JMPS) that just happen to share a common pom (which in itself may have a test-scoped slice that doesn't apply to src/main/java).
This differs from another concept that has been proposed: to consider src/test/java as an overlay, which is merged with src/main/java for compilation and execution of tests and ignored otherwise.
I think it's fair to call the first approach black-box tests whereas the second approach (merging) support white-box testing (of private innards of a module).
Traditionally, in Eclipse the black-box approach most closely corresponds to two separate projects. The key point being: in Eclipse a classpath is defined exactly once per project. Eclipse does not genuinely define any conditional logic in .classpath. There are two backdoors, though:
- JDT leaves it to the implementation of "Classpath Containers", to resolve into an arbitrary set of jars or classpath folders, at the full deliberation of that implementation.
- JDT hardcodes specific semantics for a source folder marked as "test", see https://eclipse.dev/eclipse/news/4.8/jdt.php#jdt-test-sources
Let's briefly dwell on the latter feature. References (in addition to the N&N entry above):
- see comments starting at https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708#c45
- in JDT sources search for references to o.e.j.i.c.CompilationGroup.TEST
- JPMS specific details are in
For a first approximation of the semantics this is what @brychcy wrote:
For test code I implemented the following in my patch:
- production sources see the workspace as if test sources and test dependencies don't exist
- test sources see the workspace as if the whole mechanism doesn't exist - (actually it sees the production sources in the same project only as binaries instead of sources, but this shouldn't make a difference)
And then any dependency can be marked as visible only for the "test" scope. Tada!
With respect to JPMS this feature implements the suggestions from http://openjdk.java.net/jeps/261 (which may be seen as authoritive, no?) as to use options like --add-reads and --patch-module to integrate test code with module main code.
As you can see, the internal semantics of marking folders and dependencies as "test" or not test, is already quite sophisticated, but it seems to solve "the other problem": enabling white box testing while avoiding the need of a secondary module-info.java.
Back to the request to support a two-module black-box approach, the above seems to imply, that we first need to disable parts of the existing solution, viz. we need a mode without any privileges for the test folder. OTOH, we need to retain the ability to compile in two separate invocations for main vs test.
So in the implementation we'd need to extend enum CompilationGroup { MAIN, TEST } with a third option like TEST_MODULE. Then every code location asking for TEST needs to differentiate what needs to be done for the new mode. If requirements at this level can be specified in terms of a compiler command line then tweaking this part accordingly sounds manageable.
In the UI I would prefer not to surface all three modes, so as a quick idea, we could distinguish the two test modes based on existence of src/test/java/module-info.java (not based on the name of the source folder, but based on the classpath attribute "test").
Finally, there is the API perspective, where JDT promises that each modular IJavaProject has exactly one IModuleDescription. It looks like the test module simply can't be accessed via this interface. This will make it very hard to implement any additional support for the test module beyond just compilation. Inspecting the incoming call hierarchy of org.eclipse.jdt.core.IJavaProject.getModuleDescription() will give an impression of the impact.
I should also mention, that JDT is build-tool agnostic, i.e., we can only provide very generic capabilities, so that m2e can setup a project's configuration according to maven rules. For m2e the main concept for communicating with JDT is through classpath entries, where things like "test" are communicated via classpath attributes on those entries. More specifically, m2e can
- create or update
.classpathto affect the general setup (like marking everysrc/test/javaas "test) - resolve dependencies from pom.xml to entries of the Maven Dependencies container, again possibly adorned with classpath attributes, per resolved entry i.e.,
It needs to be determined here, if JDT needs to understand additional classpath attributes to serve m2e right.
_On a personal note: I will continue to discuss this and give hints into the implementation if desired, but I will not actively drive this development, in part because I feel that supporting just another project layout for black box testing (which can already be done by individual Eclipse projects) is not really a huge advance. I think white box testing in the presence of modules is the thing calling for really new concepts, like merging module-info.java from two sources or such._
SentryMan
hohwille
danthe1st
Problem
If a module requires additional modules only for its test cases, the de-facto standard is to define an additional
module-info.javafile insrc/test/javathat should be declared open and has a test specific identifier and requires the main module fromsrc/main/java/module-info.java. Here is an official example from Maven for this use-case: https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.htmlHowever, Eclipse does not support that a single project may have more than one
module-info.java. Therefore you get the following error:Why is this important?
The JPMS is very strict. As soon as I define modules, I need to declare any required module or I can not even import an according class. So in a library project, I might want to have very minimal required module dependencies (e.g. none at all). However, for implementing my JUnit tests, I might need some logging (
java.util.loggingororg.slf4j). I do not want to be forced to require that logging in my main module just to be able to use it only in my tests. But otherwise, I can not even add the import to the Logger in my JUnit test class in Eclipse. The logging is just a famous example - this also applies to whatever else you might need additionally for your tests. With JPMS the entire concept of test scoped dependencies becomes more or less pointless with Eclipse due to this lacking feature.Impact
Developers of JPMS modules are forced to use a different IDE than Eclipse. A workaround may be to create an extra projects only for testing. However this has the following drawbacks:
Related issues
Sources