When comparing Gradle configurations compare the contents not the reference equality

[lkerford]

When we compare Gradle configurations we are checking for reference equality not the contents. We are missing configuration we should be adding when retrieving the list of extended configurations

[shanman190]

Do the contents of a configuration really need to be compared deeply? All of the marker methods use the same immutable patterns of other LST elements.

[lkerford]

Do the contents of a configuration really need to be compared deeply? All of the marker methods use the same immutable patterns of other LST elements.

I do believe so, we are currently failing to match configurations which should be equivalent. This is resulting in the change dependencies recipes failing to update dependencies which should be updated.

[shanman190]

I'm still not totally convinced here.

The various change recipes act upon the LST itself, then when there is a confirmed change update the GradleProject marker.

Ex:
https://github.com/openrewrite/rewrite/blob/main/rewrite-gradle%2Fsrc%2Fmain%2Fjava%2Forg%2Fopenrewrite%2Fgradle%2FChangeDependency.java#L173-L175

Another piece of potentially relevant information is that we do not update the various extendsFrom configurations transitively when a top-level configuration is modified. Partly because we don't fully resolve the dependency graph like is done with rewrite-maven during a recipe execution. But even with not performing these updates and instead relying upon a new LST generation, it shouldn't impact most change recipe executions.