How to deal with such warnings? visible is not use...
# community-support
k
How to deal with such warnings? visible is not used in any project related code
m
It's probably in one of your plugins
If you really want to, you can set a breakpoint here and get the full stacktrace (if not available somewhere in that report already)
k
isn't it just a test case?
m
What do you mean by test case?
k
Such class is not available for breakpoint in a project, that looks like a test scope of gradle's build. DeprecationMessageBuilder is not called, or idea didn't follow breakpoint
m
Yea, I've had mixed results from the main build. You can also run your main build with
-Dorg.gradle.debug=true
, open the Gradle soruce code in IJ, and start a remote debugging run configuration from there.
It's not as difficult as it look, the Gradle source code is quite well organized, if you have a M-something macbook, it can deal with the codeabse
k
now error disappeared, tried to run a lot of tasks, but found only other 🪄
m
It probably depends the state of your build
Well maybe not
I was going to say if your build is up-to-date, it does a lot less things but this would probably happen in configuration anyways
In all cases, I wouldn't worry too much about those warnings
k
or that's some kind of caching for 9.0 -> 9.1.0version
v
Hm, I wonder about two things. 1. that the stacktrace is found nowehere in the report, not even with
--stacktrace
2. that only
isVisible()
triggers a build deprecation but
setVisible()
not, while the method itself is also deprecated Anyway, if you run again with
--warning-mode all --stacktrace
, you at least get the deprecations including stacktrace on the commandline and can then exactly see where the
isVisible()
call is made from to report it accordingly.
🔥 1
k
weird that it marked as 9.3.X, as user i would expect 9.1.X fixes
v
Why? There is not even any 9.1.x announced and even if one comes it usually only contains very important backports like security fixes, not minor things like a missing deprecation warning. And ,9.2.0 is already in RC phase, so also too late for such a minor thing. So 9.3.0 is indeed the only sensible choice.
k
I'm developing a lot of build things, i want to have it configuration cache compatible, but i'm getting this report and forced to open it every time.
v
Yeah, well, feel free to try to convince the Gradle folks to fix that ticket in a 9.1.1 patch or to bring it into 9.2.0 release. But I highly doubt they will do it as it is not a security issue (for the former) and most probably not important enough for the broad mass to shove that in while 9.2 is already in RC phase. 🤷‍♂️
k
maybe you know what to cherrypick into 9.1 and what task (from hundreds of tasks) to run, maybe i can build gradle-distribution for personal usage... Really tired infinitely opening this report
v
How to build a local distribution is documented at https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md#install-gradle-locally What to pick, well, the issue is still open, so there is nothing you could pick, you can just fix the code yourself.