gradle-errorprone-plugin
gradle-errorprone-plugin copied to clipboard
tbroyer
locks not being generated when running build
This ticket has all the data, but they're pointing the finger here
https://github.com/gradle/gradle/issues/28534#issuecomment-2017606381
See https://github.com/tbroyer/gradle-errorprone-plugin/blob/5d9e2a80d37fcdb393ff694f1b02e31f044f17e9/src/main/kotlin/net/ltgt/gradle/errorprone/ErrorPronePlugin.kt#L99
May I ask why you expect the errorprone configuration to be resolved (thus locked) by a build? The configuration is only there to be extended by the annotationProcessor configurations which are the one that are resolved.
Note that I'm not arguing against changing the configuration to no longer be resolvable. I see little to no reason not to do it nowadays, so I'll probably do a v4 with that change when I find time.
the problem is that it's very surprising behavior (that took me days to figure out what I was doing differently locally from remotely) that error prone isn't getting locked when running build --write-locks which means that my dynamic dependency is still updating dynamically every day. I hadn't hit a problem with that yet, but that's probably sheer luck.
The only reason I noticed it was getting unlocked was my fancy dancy auto update script. I can imagine there are people who are getting a dynamic version and don't know (yet).
honestly, I kind of hate how gradle expects us to manage locks, as it seems like an impossible task.
oh, and I'm not the right person to ask about "why resolve", I'm just linking the explanation I got, and then reiterating my problem. I don't fully understand the why.
note: I run dependencies --write-locks locally because build might fail when I need to do an update. I run build --write-locks remotely because I thought it would catch all the things dependencies doesn't (yes there are those too) 😮💨. This is also a case where I would love to not have the output from dependencies but I haven't figured out a good solution for that.
Don't you have the same "problem" with the errorproneJavac configuration? If you're not using JDK 8, it shouldn't be resolved as part of a build, but would be resolved by the dependencies task, and this is unavoidable (until I remove support for JDK 8 and thus remove this configuration entirely).
The same would be true of configurations that are only used for some specific tasks that you don't run as part of a build, this is just how Gradle works.
So while I'll probably make the errorprone configuration non-resolvable in a future version (I have the commit ready), it won't actually "solve the problem" (it might solve your current problem, but only because you're only experiencing that one specific difference between build and dependendencies)