[
https://issues.apache.org/jira/browse/LUCENE-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17462220#comment-17462220
]
Uwe Schindler edited comment on LUCENE-10328 at 12/19/21, 3:48 PM:
-------------------------------------------------------------------
bq. True. You can work around this by placing modular tests on a separate
project - then the path is referenced properly.
This is only a work around for *module integration* tests, e.g. tests that
check if you can use the module and its public API, so the test *uses* the
module und therefor has the module as dependency.
bq. I don't have on opinion on maven vs. gradle. They both have pros and cons,
I guess. As much as I liked using maven, it never really fit all the needs for
me in larger/ non-standard lifecycle projects.
This was not against Gradle. But the current module support of gradle is
completely untested and as we have seen broken to hell. I makes assumtions
which are not true and basically we had to disable almost everything provided
by Gradle.
We should fix here the test runner to work like Maven's, because this was
negotiated and lengthly discussed with Alan, Mark and all the other OpenJDK
people. The big difference here is and we need to adapt Lucene to do this:
Unit tests MUST run inside the module. They are not consumers of the module,
they test the module itsself. Of course you can do this like done at the moment
by using classpath, but this also brings problems that you workaround: You
corrently add all modules you find on module path for tests (see your code).
But this is not enogh for Lucene-core: It also needs jdk-internal modules
("jdk.unsupported"): If you start to use module path, the classpath no longer
sees the modules, so jdk.unsupported is no longer added. With the current setup
it work "so naja" (German), but it is far from correct.
To do UNIT testing of a module, the tests must access internal stuff of the
tested modeule, so the tests must be part of the module. So you have a full
module setup and you also have the tested module on module path. The problem is
that you have to trick java to run the tests (residing outside of the module
JAR) as if they were part of module. The negotiation between OpenJDK and Maven
developers was simple: They added the module patching which allows to exactly
do this:
- you compile the module as a modular JAR file
- the test depends on the modular jar file, but the test runner injects the
test classes into that module. The good thing with that is: The tests can
access private stuff and also the tests automatically inherit all dependencies
(like internal JDK modules) from the module-info.class of the modular jar. BTW,
tests inside the JDK are setup the same way.
So we are close, we should do the following:
- fix test-framework to work as module (looks like this is possible), otherwise
add it in the same way to the patcher (häckidihickhack).
- compile the module and package as modular JAR
- run test-runner with {{--patch-module
org,apache.lucene.modulexy=build/test/classes}} to patch the class files in the
test folder into the module to test. The tests are then running inside the
module's sandbox. If you need additional modules at test time, you can also
inject them with {{--add-modules}} (like test framework), so they do not need
to be in module's module-info.
Once we have this setup, we should do Pull Reqests to gradle to fix the
incomplete module support there.
was (Author: thetaphi):
bq. True. You can work around this by placing modular tests on a separate
project - then the path is referenced properly.
This is only a work around for *module integration* tests, e.g. tests that
check if you can use the module and its public API, so the test *uses* the
module und therefor has the module as dependency.
bq. I don't have on opinion on maven vs. gradle. They both have pros and cons,
I guess. As much as I liked using maven, it never really fit all the needs for
me in larger/ non-standard lifecycle projects.
This was not against Gradle. But the current module support of gradle is
completely untested and as we have seen broken to hell. I makes assumtions
which are not true and basically we had to disable almost everything provided
by Gradle.
We should fix here the test runner to work like Maven's, because this was
negotiated and lengthly discussed with Alan, Mark and all the other OpenJDK
people. The big difference here is and we need to adapt Lucene to do this:
Unit tests MUST run inside the module. They are not consumers of the module,
they test the module itsself. Of course you can do this like done at the moment
by using classpath, but this also brings problems that you workaround: You
corrently add all modules you find on module path for tests (see your code).
But this is not enogh for Lucene-core: It also needs jdk-internal modules
("jdk.unsupported"): If you start to use module path, the classpath no longer
sees the modules, so jdk.unsupported is no longer added. With the current setup
it work "so naja" (German), but it is far from correct.
To do UNIT testing of a module, the tests must access internal stuff of the
tested modeule, so the tests must be part of the module. So you have a full
module setup and you also have the tested module on module path. The problem is
that you have to trick java to run the tests (residing outside of the module
JAR) as if they were part of module. The negotiation between OpenJDK and Maven
developers was simple: They added the module patching which allows to exactly
do this:
- you compile the module as a modular JAR file
- the test depends on the modular jar file, but the test runner injects the
test classes into that module. The good thing with that is: The tests can
access private stuff and also the tests automatically inherit all dependencies
(like internal JDK modules) from the module-info.class of the modular jar. BTW,
tests inside the JDK are setup the same way.
So we are close, we should do the following:
- fix test-framework to work as module (looks like this is possible), otherwise
add it in the same way to the patcher (häckidihickhack).
- compile the module and package as modular JAR
- run test-runner with {--patch-module
org,apache.lucene.modulexy=build/test/classes}} to patch the class files in the
test folder into the module to test. The tests are then running inside the
module's sandbox. If you need additional modules at test time, you can also
inject them with {{--add-modules}} (like test framework), so they do not need
to be in module's module-info.
Once we have this setup, we should do Pull Reqests to gradle to fix the
incomplete module support there.
> Module path for compiling and running tests is empty
> ----------------------------------------------------
>
> Key: LUCENE-10328
> URL: https://issues.apache.org/jira/browse/LUCENE-10328
> Project: Lucene - Core
> Issue Type: Sub-task
> Reporter: Dawid Weiss
> Priority: Major
> Attachments: image-2021-12-19-12-29-21-737.png
>
>
> Uwe noticed that the module path for compiling and running tests is empty -
> indeed, the modular configurations we create for the test sourceset do not
> inherit from their main counterparts. This is not a standard thing created
> for a sourceset - the test-main connection link is created by gradle's java
> plugin. We need to do a similar thing for modular configurations.
> !image-2021-12-19-12-29-21-737.png|width=490,height=280!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
