fix(maven)!: set RegistryStrategy = 'hunt'

[fredrondina]

Changes

set maven RegistryStrategy = 'hunt'

Context

Closes #22744

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

We need to first make sure that the registry Urls are in the best order. @Churro any thoughts?

[Churro]

Correct registry order is definitely not warranted in gradle and maven managers (at least). The existing merge strategy isn't fitting to how these two behave either but I'm clueless how many releases we'd miss by switching to hunt.

[rarkins]

Blocked by #22811

[rarkins]

@Churro I think we maybe need to make the change and then be responsive for fixing afterwards if necessary?

[Churro]

You're probably right.

I think with the maven manager it should be feasible to extract + re-order registryUrls according to the official docs (here). With gradle, it's way more intricate but I'd hope that hunt resolve at least as realiable as merge in that case.

[rarkins]

Are we sure Gradle does hunt too?

[Churro]

Are we sure Gradle does hunt too?

Generally, it does. This is also stated in the official docs:

A project can have multiple repositories. Gradle will look for a dependency in each repository in the order they are specified, stopping at the first repository that contains the requested module.

I'm not sure about deps with dynamic versions (e.g. com.squareup.okttp3:okhttp:4.9.+) though - see here:

Each repository is inspected, Gradle does not stop on the first one returning some metadata. When multiple are defined, they are inspected in the order they were added.

[rarkins]

Replaced by #24588