search

tbroyer / gradle-errorprone-plugin

Gradle plugin to use the error-prone compiler for Java
Apache License 2.0
366 stars 32 forks source link

locks not being generated when running build #94

Closed xenoterracide closed 4 months ago

xenoterracide commented 6 months ago

This ticket has all the data, but they're pointing the finger here

https://github.com/gradle/gradle/issues/28534#issuecomment-2017606381

tbroyer commented 6 months ago

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.

xenoterracide commented 6 months ago

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.

xenoterracide commented 6 months ago

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.

tbroyer commented 6 months ago

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)

tbroyer commented 4 months ago

Version 4.0.0 makes the errorprone dependency non-resolvable