On 2/25/2020 10:48 AM, Robert Scholte wrote:
For the test sources it is unclear.
One reason to not provide a module descriptor is because it will never
be a requirement for other modules.
And what about its name, as it is actually a required module and at the
same also the same module.
One reason to provide a module descriptor is for the build tool to know
which modules are required, so it can provide the right set of modules.
But how would such descriptor for test sources look like? Well, in the
end it must contain everything from the main module descriptor + the
test requirements.
I assume that copy/pasting the main module descriptor for a new test
module descriptor + adding the extra requirements is not the preferred
solution.
Correct, that is no-one's preferred solution. My preferred solution (and
I think Christian's) is for the test module's descriptor to stay
physically independent of the main module's descriptor. Then, the build
tool (i) FINDS the test module's descriptor and (ii) MERGES it logically
with the main module's descriptor. Suppose the merged descriptor says
that the main module requires org.junit -- the build tool turns that
into an --add-modules command when compiling and running tests. Maven
could be doing this today, helping users to focus on their white-box
test modules rather than asking users to type obscure --add-* commands
in the POM.
Furthermore, from what Christian has posted, the effect of merging is
always the same anyway -- require some JUnit modules, and open the main
module. So, in the common case, people don't even need to write a test
module descriptor; they just need the Maven test scope to inject the
customary --add-* commands when compiling and running code in the main
module.
Alex
