-
Notifications
You must be signed in to change notification settings - Fork 134
Ignore org.immutables:value::annotations when adding Immutable incremental arg
#2717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
||
| return Objects.equals(moduleId.getGroup(), "org.immutables") && Objects.equals(moduleId.getModule(), "value"); | ||
| private static boolean isImmutablesValue(Dependency dependency) { | ||
| return Objects.equals(dependency.getGroup(), "org.immutables") && Objects.equals(dependency.getName(), "value"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If people bring in the actual immutables processor jar (not ::annotations classifier) transitively and it ends up being used we should still actually apply this? Couldn't we fix this by keeping the code looking at transitives but making sure one of the components has a group org.immutables, artifactId value and no classifier? Might have to use the artifacts rather than components api from Gradle to do this from memory (so you can get the classifiers)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't we fix this by keeping the code looking at transitives but making sure one of the components has a group org.immutables, artifactId value and no classifier?
This is what I tried to do at first, but I couldn't figure out how to get at the classifier here. Although it is just more complexity.
If palantir/conjure-java-runtime-api#1099 doesn't fix the issue I'll play around with this a bit more.
Although I have to imagine that bringing in the immutables processor as a transitive dependencies and then using it is pretty unlikely. Honestly, if you're using an annotation processor and not declaring an explicit dependency, then you have no right to complain if your build is slow because we didn't enable incremental compilation for you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I swear I remember seeing the horror of some annotation processor produce an immutables class that was then compiled by immutables... It was a long time ago, sense may have prevailed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you have no right to complain if your build is slow because we didn't enable incremental compilation for you
I agree with the sentiment but the problem is it just silently becomes slower with no indication why... and devs often just suffer in silence. I guess this is telling me we should probably build something that makes a loud log line or fails the build when it detects an non-incremental annotation processor somehow (in an ideal world).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated it with the version that checks the classifier using the old artifact APIs (Gradle still does not have a configuration cacheable api for maven classifiers 😢: gradle/gradle#23702).
…incremental arg" This reverts commit 140d025.
gradle-baseline-java/src/main/groovy/com/palantir/baseline/plugins/BaselineImmutables.java
Show resolved
Hide resolved
pkoenig10
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Confirmed that this fixes the issue, thanks for the help @CRogers!
|
👍 |
Generate changelog in
|
org.immutables:value::annotations when adding Immutable incremental arg
|
Released 5.38.0 |
palantir/conjure-java-runtime-api#1095 broke consumers who did not themselves use the Immutables annotation processor.
This is not a regression of #2465 - the test added in that PR still passes.