fix: skip deep dependency comparison for Gradle projects

[jjohannes]

This is unnecessary and leads to a long runtime (and possible an infinite loop/recursion) for large dependency graphs as observed in #9763.

[codecov]

Codecov Report

Attention: Patch coverage is 33.33333% with 4 lines in your changes missing coverage. Please review.

Project coverage is 68.19%. Comparing base (48b638f) to head (7229394).

Files with missing lines	Patch %	Lines
...el/src/main/kotlin/utils/DependencyGraphBuilder.kt	20.00%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #9817      +/-   ##
============================================
- Coverage     68.21%   68.19%   -0.02%     
  Complexity     1293     1293              
============================================
  Files           250      250              
  Lines          8849     8853       +4     
  Branches        920      921       +1     
============================================
+ Hits           6036     6037       +1     
- Misses         2424     2426       +2     
- Partials        389      390       +1     

Flag	Coverage Δ
funTest-docker	65.14% <ø> (ø)
funTest-non-docker	33.35% <0.00%> (-0.03%)	⬇️
test-ubuntu-24.04	35.97% <33.33%> (-0.01%)	⬇️
test-windows-2022	35.95% <33.33%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sschuberth]

There are some test differences to inspect.

[sschuberth]

There are some test differences to inspect.

For whatever reason, the change causes a lot of the following differences in the dependency tree:

It basically seems that cycles are now cut too early or so.

[sschuberth]

It basically seems that cycles are now cut too early or so.

Or actually, it seems that runtime dependencies are omitted now. Take a look at e.g. lifecycle-livedata-core:2.5.0:

core-common:2.1.0 and core-runtime:2.1.0 are exactly the omitted direct dependencies.

[sschuberth]

BTW, @oheger-bosch do you recall why the original code uses an "uni-directional" containsAll() here? In other words, why did we continue here if dependencies2 was a superset of dependencies1, instead of also returning false early?

[jjohannes]

@sschuberth in order to make this solution workable, the selected variants need to be tracked. The same component may have a different set of dependencies, depending on which variant was selected. In most cases, it is only one, but Gradle also supports to select multiple in one scope under certain conditions.

I added variants as an additional optional field of the Identifier data class to check if the tests pass with this. It likely works, but you have to check is such an addition is desired.

[jjohannes]

Wit the change in this PR, the problem described in the description of #9763 no longer occurs.

[mnonnenmacher]

I added variants as an additional optional field of the Identifier data class to check if the tests pass with this. It likely works, but you have to check is such an addition is desired.

Changing the Identifier class is indeed problematic as it is used in so many places, so even if no tests are failing there could be unintended side effects. We have discussed to switch to PURL (#8982) which should also make it easier to add such custom properties, but that's a huge refactoring.

However, I wonder if even you even use the new property anywhere in this change? I couldn't find it.

[jjohannes]

Changing the Identifier class is indeed problematic...

Yes I was afraid that it may not be a simple thing to do. Although, the change only adds a new field (variants) that defaults to emptySet(). Therefore, it should/would be non breaking. But I can understand, if you still see it as too risky.

However, I wonder if even you even use the new property anywhere in this change? I couldn't find it.

I is implicitly used by dependencies1 == dependencies2.keys as it adds a new value that is used when the data objects are compared.