https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
m
I have:
Copy code
tasks.withType<Test>().configureEach {
     modularity.inferModulePath.set(false)
}
but it's still using 
--module-path
how can I force it to use good old classpath for tests?
oh man this is so painful
j
🤨 This sounds like a bug. Do the tests themselves have a "module-info.java" in the test sources?
m
no they don't
for context I can't run my tests with module path, because they fail with Spock, which is not module compatible
j
IIRC, test would only run like that if a "module-info.class" is in 
testClassesDirs
Maybe such a file ends up there from somewhere else?
m
I don't think so, the issue disappears if I remove my 
module-info.java
from the main sources
also checked and testClassesDir doesn't have the main sources (as expected)
j
I am surprised by this behavior. Usually it's the other way around. It's difficult to get the tests to run as module, if they don't have "module-info" (and only the main sources have). Like here: https://github.com/gradle/gradle/issues/22506#issuecomment-1301266392
m
I am also surprised, and I must say that's quite annoying 😄
j
Have you tried with a 7.x Gradle version? There were these changes with the test classpath setup....
m
same with 7.6 😞
j
I have no other idea, than debugging into the code that makes the decision to use the "module path" and see what causes this behavior there.
g
Do you effectively have split package with main sources? And is does it work with different source set than 
test
?
m
I have no split package
g
So tests are in different package then, ok
m
the tests are in the same package as the main sources though
but it shouldn't matter: I don't want to run tests with 
module-path
somehow Gradle absolutely wants to do that
g
yeah, it looks like a bug if you turn of jpms for 
Test
task
if you didn't try it earlier, try to move tests to other source set, since 
test
might be "special"
if it still runs it with module path instead of normal class path and you don't have 
main
in deps of course
if you have 
main
in immediate deps it will likely resolve as classes dir and you effectively have module-info visible
m
I'm starting to think it's the org.openjfx.javafxplugin plugin causing this, but not sure yet
j
Yes. That applies "org.javamodularity.moduleplugin.ModuleSystemPlugin" under the hood
g
Not familiar with it, does it call 
modularity.infetModulePath.set
? If so you could try to call 
set
in 
afterEvaluate
despite code smell
j
That one does a lot of moving things around. It's the "old" plugin that does not built on Gradle's native module system support. If you need to keep it, you probably need to configure that plugin.
m
oh man
gradlephant 1
j
Copy code
test {
    moduleOptions {
        runOnClasspath = true
    }
}
m
yup found that too, but configuration doesn't work with Kotln DSL, the extension type isn't found...
oh what fun...
j
You are having fun, right... 🤷
😅 1
m
pfiew, fixed! Thanks guys!
👍 1
4 Views
Open in Slack
PreviousNext
Powered by