eclipse-jdt / eclipse-jdt/eclipse.jdt.core

Support additional module-info.java for tests, if that ends up being de-facto standard

Open
#1,465 27 comments 8 reactions 0 assignees View on GitHub
jpms
Dominant language
Java
Stars
237
Forks
195
Avg merge
1d 12h
Merged PRs (30d)
47

Description

# Problem
If a module requires additional modules only for its test cases, 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`.
Here is an official example from Maven for this use-case: https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html

However, Eclipse does not support that a single project may have more than one `module-info.java`.
Therefore you get the following error:
```
Build path contains duplicate entry: 'module-info.java' for project '«project-name»'
```

# 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.logging` or `org.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:
* It does not fit with common standards and confuses developers trying to understand the project
* It causes lots of clutter and maintenance overhead
* In an extra project I can not access the internals of the actual project, I want to test, so I am limited to black-box-testing. However, I commonly want to write JUnits as white-box tests.

# Related issues
* This issue is a replacement for [bugzilla 559601](https://bugs.eclipse.org/bugs/show_bug.cgi?id=559601).
* It is slightly related to #617

# Sources
* https://github.com/eclipse-jdt/eclipse.jdt.core/blob/aea7697979eae6edc916094f25a716d529c40b68/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/util/messages.properties#L155
* https://github.com/eclipse-jdt/eclipse.jdt.core/blob/aea7697979eae6edc916094f25a716d529c40b68/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/JavaProject.java#L3996

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.