https://gradle.com/ logo
Join Slack
Powered by
anyone know if there's a way to turn gradlex modul...
# community-support
c
anyone know if there's a way to turn gradlex module test suites off for a specific test suite?
v
Don't think so
👍 1
c
Yeah I don't either. I think if I want to get it to do what I need it to do I'm going to have to fork it.
v
What do you need it to do? Is neither Blackbox nor Whitebox testing as the plugin defines it suitable? If there's some use-case maybe Jendrik will add something
c
I have open issues... His white box testing it turns out actually inappropriately detects some of the requirements for my module info and so would force me to change my production code in order to fit his testing module. It also feels like more work than I would want to do for white box testing. Honestly it appears the way I write tests that most of my tests are black box anyways. But when I do want White box tests I'm just fine with them being the way Gradle tests them now... So really all I'd like is to be able to convert a test suite to Black box... The module info detection seems to work fine for that. But I'm left without a good way To avoid the headaches of white box testing.
you know, I don't think the gradlex plugin is needed for blackbox jpms at all. I think that just works
if you add a module-info
v
Are you sure? Does it then really build a jar and use that for testing, not a separate resources and classes folder which then are not a module? For blackbox tests the plugin adds the jar task for the test source set if not present and configures the test task to use the jar. If Gradle already does that ootb, you are probably right.
c
I've not read your full message but I can tell you that I didn't add the gradle plugin to this reproducer and it still reproduces the issue https://github.com/spring-projects/spring-boot/issues/41203#issuecomment-2186798836 and without the module info in the test source set it would pass fine.
v
As long as you only have code in the test sourceset it probably works fine. As I said, unless Gradle now does differently, it contains a directory with the classes and a directory with the resources to the path and so the resources are not considered part of the module defined in the classes. The plugin for blackbox tests fixes this by configuring an according jar task and configuring the test task to use that jar instead.
c
well, my point is that by adding its own module-info to the test source set, the test breaks. So gradle/java seems to be respecting that module-info
but as far as resources, this doesn't test that. feel free to show me code where it would matter, since I'm not certain
all I can say is, delete the module-info in test and the runtime exception goes away
v
Of course the module-info is significant, the plugin also just configures black-box testing when it is found. I told you where it would be relevant. Whether you try this out or not is up to you, I don't have time right now to spoon-feed it. 🙂
c
yeah, but I don't know what circumstances that exactly means... it affects resources, ok then
I guess that's not a priority for me with all of the other jpms breakage in the world
it's not like I'll ever be able to run production with it on, or use jlink
or put another way, if it gets me 80% of the way not using that plugin which would only get me 20% because it's overly aggressive on its application to test suites and seeming requirement of things that don't seem to be actually required...
because it expects you to be using the gradlex stack... where module-info is used to define dependencies instead of gradle...
v
because it expects you to be using the gradlex stack... where module-info is used to define dependencies instead of gradle...
That's total news to me, and probably more a bug. It has support for improving cooperation with that plugin. But it should not require that plugin at all. But sure, if you do not need the plugin / it's effects, don't use it, why should you?
c
well, it's more that the author expects it and seems unwilling to acknowledge there's a bug in his code because he's expecting that usage... of course my code must not be correct in that this library is optional...
IIRC it was forcing me to use requires when requires static was sufficient
because he thinks that gradle dependency scopes are also 1 to 1 with module info scopes
but yeah, for my use case I think it's creating issues
v
Who cares what Jendrik expects as long as his plugin can cope with both decisions, to use the other plugin or to not use it? As I said, it should integrate with it but not require it. Everything else is probably a bug and I also say that to @Jendrik Johannes's face 😄
c
more issues than it solves
feel free to comment on my open issues 😉
I've said it
if I'm wrong, I'm wrong but I'd like someone to do a better job of explaining why if only for my own education
in the meantime I have to go try to figure out why jakarta's module info is declaring deps differently from its pom
v
feel free to comment on my open issues 😉
I've said it
It's in a closed issue. And Jendrik does not expect you to use that plugin or I did not see the comment you mean. He says that your problem is that you are inconsistent in what you declare in the module-info and in the Gradle file which causes your problem. And he said that with the dependencies plugin you can prevent such errors as you do not declare the dependencies twice anymore.
c
and yet... it's inconsistent with what he thinks IIRC, because compile only (? or was it api...) and 
requires static
... I don't think I ever got an explanation for why that was inconsistent.
I think he was forcing an upgrade to compileOnlyApi to a thing that shouldn't, afaik, require it
is that not what I said?
note: using require in that sentence as english not keyword 😉
v
From a cursory look he did explain it. You had in Gradle 
compileOnlyApi
which means it is available at compile time and at compile time of downstream consumers, but no at runtime of either. But in your module info you had 
requires
which means that it needs to be there always at runtime. 
requires static
is like 
compileOnly
, in being an optional dependency that can be there at runtime or missing. And 
requires transitive
means that it is also automatically `require`d for downstream consumers that depend on that module. So the according module info stanza for 
compileOnlyApi
is 
require static transitive
.
c
scratching head well, if I'm wrong 😉 maybe I misunderstood... or misread what he wrote... I'll look later, jakarta now! I still think it should be optional to apply that plugin to a test suite though, even if I'm wrong.
feels unnecessary for whitebox in my mind
v
Well, he said whitebox is the main point of the plugin, so if you don't need it for that, probably don't use it, yeah
c
right, but if blackbox is my need and gradle is not doing all the right things without it and plugin is forcing me to have both or not use the plugin...
finished my spring bug report. Hopefully the option to outright dismiss jpms for dependencies isn't made
v
and plugin is forcing me to have both or not use the plugin
It does not
right, but if blackbox is my need and gradle is not doing all the right things without it
As long as you do not have resources in your test source set, it should do the right enough things. If you do have resources even Jendrik recommended in one of those issues to just do that one configuration for the blackbox tests manually if you do not need the whitebox features.
c
> and plugin is forcing me to have both or not use the plugin
maybe you don't understand what I mean?
v
Possible
Tell me
compileOnlyApi
on Gradle side with 
requires
on module info side is wrong, no matter whether you use any Gradlex plugins or not.
c
I mean I have to have plugins whitebox || blackbox, there's no option to disable it for a jvm test suite and just let gradle do it's normal thing
v
Oh, sorry, indeed misunderstood
I thought you are talking about needing both plugins or not use the testing plugin 😄
👍 1
c
not certain why or how the plugin is validating my stupidity either
it feels like a test that I configured them properly is better left to another module
honestly though I'm moving on for a minute. I'll come back to this stupidity another day
low priority
v
👌
👋
c
no comment on who's stupidity. probably mine 😉
although I'm always in favor of convention with configuration!
unless you have a suggestion for whitebox source set names... since I figure I might default to black box suites
v
Suggestion for what?
c
the name
I should probably just call it 
testWhitebox
but that name feels weird
more important than this is figuring out this javadoc problem 😕
v
Naming is always one of the hardest parts in software development 😄
👍 1
c
yesterday, were you reading this bug? https://github.com/gradlex-org/java-module-testing/issues/51 hint: I know you weren't ;)
v
Interesting what things you think you know even if you don't. The answer is yes
c
But you spent the entire time telling me that he said to use require static transient which at the top of this bug I absolutely said I did
You also said it was closed
So you were reading the closed bug not this one
v
Yes, in that ticket he did not answer yet and I was searching for the comment of him you mentioned, which I found in that closed ticket.
c
right, but that answer didn't work 😉 that wasn't the problem
I didn't remember what I wrote in that ticket, but the repro proved that wasn't the problem. I imagine you prodded him yesterday and so he looked at it and responded. Sounds like there'll be a change to whitebox that will fix it.
👌 1
the bug, if you didn't read his response is that java test compile doesn't extend compile classpath which is a gradle thing. I don't fully grok why that's a problem when using compileOnlyApi ...
v
I did read. That's not what he says. He said the problem is, that 
testCompileOnly
does not extend from 
compileOnly
. He blames Gradle, yes. I'm not sure I agree. It sounds correct to me that this connection is not drawn unless I miss some detail.
c
sure, but I'm using 
compileOnlyApi
... anywhays "I only work here"
v
You wrote in that ticket that with 
compileOnlyApi
it does work
c
oh, lol, derp
now who's not reading the ticket 🤦‍♂️ guess it's me
I'm just plain illiterate though
v
> now who's not reading the ticket 🤦‍♂️ guess it's me Didn't want to play that card, but ... yes 😄
You probably also shouldn't call a tar 
.tar.gz
when it is a plain tar without zip though 😄
c
yeah... hrm... wonder how that's happenning/happened
tar -xvf probably works though....
v
Probably forgot 
z
but still named it like that 🤷‍♂️
Yes it does
c
it's probably git archive doesn't make a gz and I don't think about it
and github inspects extension names but doesn't worry about magic bits
because foolishness !
I for one always upload my malware with the correct file extension
👌 1
I'll have to remember to gzip after git archive...
v
You can tell git-archive which format to use. 
tar
is just the default
But it should usually also get it from the file name
Unless you pipe it to file of course
c
possible I didn't use git archive on that. One of the first I started uploading archives. This is what I've been doing with git archive now.
Copy code
git archive -o repro.tar.gz HEAD
👌 1
v
Ah, now I at least understand the problem. But imho that is not a Gradle shortcoming and not to be fixed in the users of that plugin, but by the plugin. For the whitebox tests 
--patch-module
is used to pretend the test code is part of the production module. By doing so, 
org.jspecify
is needed for compilation as it is 
requires static
in the 
module-info.gradle
. 
requires static
means it is required at compilation time but optional at runtime, so exactly what 
compileOnly
also expresses. The problem is, that by using the 
--patch-module
when compiling the test sources the compilation process then also needs that module in the module path. So imho the plugin when doing such a 
--patch-module
should also add the 
testCompileOnly.extendsFrom(compileOnly)
as it is the plugin that draws that connection after all.
Ah, yeah, he also wrote that he thinks the plugin should do that 🙂 👌
👍 1
c
yeah, I think I'm starting to understand it... maketh my head hurt a little though
2 Views
Open in Slack
PreviousNext
Powered by