Skip to content

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.

Sign up for GitHub

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

Merged
bulldozer-bot merged 5 commits into from
Feb 7, 2024
Merged

Ignore org.immutables:value::annotations when adding Immutable incremental arg #2717

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
140d025
Don't consider transitive dependencies when adding Immutable incremen…
pkoenig10 Feb 7, 2024
6074012
Revert "Don't consider transitive dependencies when adding Immutable …
CRogers Feb 7, 2024
1c79ddf
check classifier
CRogers Feb 7, 2024
32a117b
Add test
CRogers Feb 7, 2024
f571955
Add generated changelog entries
svc-changelog Feb 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 4 additions & 16 deletions gradle-baseline-java/src/main/groovy/com/palantir/baseline/plugins/BaselineImmutables.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,9 +21,7 @@
import java.util.Objects;
import org.gradle.api.Plugin;
import org.gradle.api.Project;
import org.gradle.api.artifacts.component.ComponentIdentifier;
import org.gradle.api.artifacts.component.ModuleComponentIdentifier;
import org.gradle.api.artifacts.result.ResolvedComponentResult;
import org.gradle.api.artifacts.Dependency;
import org.gradle.api.tasks.SourceSet;
import org.gradle.api.tasks.SourceSetContainer;
import org.gradle.api.tasks.compile.JavaCompile;
Expand Down Expand Up @@ -76,22 +74,12 @@ private static boolean hasImmutablesProcessor(Project project, SourceSet sourceS
return project
.getConfigurations()
.getByName(sourceSet.getAnnotationProcessorConfigurationName())
.getIncoming()
.getResolutionResult()
.getAllComponents()
.getAllDependencies()
.stream()
.anyMatch(BaselineImmutables::isImmutablesValue);
}

private static boolean isImmutablesValue(ResolvedComponentResult component) {
ComponentIdentifier id = component.getId();

if (!(id instanceof ModuleComponentIdentifier)) {
return false;
}

ModuleComponentIdentifier moduleId = (ModuleComponentIdentifier) id;

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");
Copy link
Contributor

@CRogers CRogers Feb 7, 2024 •
edited
Loading

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)?

Copy link
Member Author

@pkoenig10 pkoenig10 Feb 7, 2024

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.

Copy link
Contributor

@CRogers CRogers Feb 7, 2024

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.

Copy link
Contributor

@CRogers CRogers Feb 7, 2024 •
edited
Loading

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).

Copy link
Contributor

@CRogers CRogers Feb 7, 2024 •
edited
Loading

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).

}
}