This message was deleted.
# community-support
s
This message was deleted.
v
Where would you expect them to be applied and why?
c
Build source should be applied automatically? In theory I would think I could still call spotlessApply from the root. I know I forgotten some file or another just not sure which one.
v
No, they are not
They are always on the classpath
But you still need to apply them where you want them
c
oh, derp, my modules don't have build.gradle.kts
😕 I really wish gradle wouldn't silently fail so much
I said look here, so tell me it's not there
v
I don't get you. Gradle never silently fails. Either it fails loudly or it is successful. Having projects wihtout a dedicated build script is perfectly valid. It is bad practice by now. But back in the "good" old times, where you pushed all configuration down from the root build script, having physical build scripts for all projects was totally unnecessary.
And if you prefer to fail if a buid script is missing, you could check for it in the settings script where you also define the projects that are part of the project
c
in the good old times? and yeah I'm sure I could write more code for something that should arguably be the default
I want gradle to catch more of my stupids without me having to add code to do it. If I wasn't stupid I wouldn't need that 😉
things should tell me I'm stupid, and if I'm not I then should be able to change that
just my opinion
v
Well, great power / flexibility comes with great responsibility. 😄
But I'm sure there is some "tell me if I do stupid things" plugin out there 🙂
c
right, but see my above comment, it's like this thing I had to do the other day with java. I had to tell the jdk to allow the sun export. That isn't really a sensible default anymore
but it allowed me to say, no do it anyways
I'm ok with linux distro's making
rm -i
a default alias. which I then unalias
just my opinion, I write too much code telling gradle to do sanity checks...
v
Yeah, well, any backwards-incompatible change needs a deprecation cycle through a major version. And all needs effort to be done and Gradle folks are heavily short on resources anyway it seems. 🤷‍♂️
c
yeah, and made more confusing by this idea, not asking for an API change... rather just a change in the behavior
though I've found that patches welcome for things like this isn't a thing... there are things like this I might send a PR
v
not asking for an API change... rather just a change in the behavior
"just" is funny. 😄 breaking changes that are "just" behavior changes are much worse than breaking changes where the API changes and it is obvious that something breaking happened
I've found that patches welcome for things like this isn't a thing
Not sure what you mean. My PRs were all welcome so far. But it might just be, that I only sent things they thought make sense. 😄
c
I don't send PR's unless the idea is already welcome. I don't care to put my time into things that aren't going to be welcome
👌 1
breaking changes that are "just" behavior changes are much worse than breaking changes where the API changes and it is obvious that something breaking happened
that's my point, although putting the new behavior behind a feature toggle... and emitting warnings. idk
v
Ok, then I got you wrong, sorry. I understood you ask for a behavior change.