dependencyUpdates for example projects

[Jolanrensen]

Helps #1661

Adapts dfbuild.dependencyUpdates convention plugin:

• Makes versionsToSync type safe
  • (Note, we always need to format versions with -, but we already do this)
• Added every missing dependency from our examples in the main gradle/libs.versions.toml
• Created exampleDependencyUpdates configuration that consumes every dependency from our examples, so the dependencyUpdate task is aware of them.
  • (I would have liked this to be automatic, but I cannot find a way to do that in a transparent manner, unfortunately...)
  • (If you know a better way, or if I missed a dependency, please let me know!)

As you can see, running dependencyUpdates now also detects out-of-date android dependencies :D

[AndreiKingsley]

Looks unsafe. Is there any not reflection-based solution?
And do I understand correctly that we only need this for referencing versions through
libs.versions extensions?

[Jolanrensen]

Safety is relative ;P it's a trade-off. We need reflection to access the version name, the version itself can be accessed normally.

Either we have a String-based solution, which fails silently when a typo is made and will result in out-of-date versions in examples, or we use type-safe accessors which don't compile on typos and break only when Gradle changes how they are generated.

Btw, the reason reflection is needed, is because the accessor returns a simple Provider<String>, which, when executed, returns the version itself without any reference to the name of the version (which is what we need to sync them).

For instance libs.versions.spark4 corresponds to

which creates a provider based around this Callable<String> (DefaultProvider<String>.value):

where we can fetch that exact String from the first screenshot.
(For accessors which are also groups, like maven, because there's also maven.surefire, I need to first call .asProvider() on them, hence the second part of the function)

I do hope Gradle eventually adds a better way to reference version names safely.

I will add some guards around it, so we get more helpful exceptions when Gradle does change.

[AndreiKingsley]

I see, but can't it be broken by any Gradle internal implementation change?

[Jolanrensen]

yes, but only when we bump gradle versions

[AndreiKingsley]

Ok, left the note about it somewhere
(smth like if something was broken after gradle version bump, then check this method 😄 )

[Jolanrensen]

haha I already added a helpful exception in that function that when it breaks that function should be fixed ;P

Btw it won't break in Gradle 9.6.0 ;P Already tested it with the RC version.