Looking at the plugin source code, it seems that dependencies are sorted by the project name, which in some cases can be exactly the same.
For instance, almost every time we update any dependency in our app, we get this kind of change in the PR:
Both dependencies espresso-idling-resource and idling-concurrent share the same project name AndroidX Test Library.
Proposed solution
I was thinking, does it make sense to you to have a sorting mechanism based on two keys as fallback?
Something like:
Where it.dependency is just group:module:version, which is supposed to be unique.
This should generate a deterministic result.
I honestly don't understand why the result is non deterministic in the first place, but this should fix the issue.
We're just using the JSON report, but I guess the suggested resolution would be beneficial for every kind of report, given that the sorting here happens at the task level, and not the report level.
Context and description
Looking at the plugin source code, it seems that dependencies are sorted by the project name, which in some cases can be exactly the same. For instance, almost every time we update any dependency in our app, we get this kind of change in the PR:
Both dependencies
espresso-idling-resource
andidling-concurrent
share the same project nameAndroidX Test Library
.Proposed solution
I was thinking, does it make sense to you to have a sorting mechanism based on two keys as fallback? Something like:
Where
it.dependency
is justgroup:module:version
, which is supposed to be unique. This should generate a deterministic result.I honestly don't understand why the result is non deterministic in the first place, but this should fix the issue.
We're just using the JSON report, but I guess the suggested resolution would be beneficial for every kind of report, given that the sorting here happens at the task level, and not the report level.