Make localhost repositories accessible with --offline

[ThadHouse]

Looking for a solution to #12748, an idea was suggested to me to start up a web server that would handle the artifact downloading and caching to work for my use case. Its a good idea, however we use the --offline flag, which blocks any http repositories, including localhost repositories. These should be allowed through --offline, since they are local.

Expected Behavior

A localhost hosted repository with --offline should be resolvable, similar to filesystem repositories.

Current Behavior

The localhost repository isn't searched at all, and cached artifacts are not found.

[lacasseio]

@ljacomet Could you provide some guidance on this issue? I would really need this issue to be fixed and was going to work on a PR in the coming week. The first question, is this something Gradle would allow? I believe there is some good reason for allowing it as localhost has already special treatment with regards to HTTP vs HTTPS.

It seems a patch to MavenResolver and StartParameterResolutionOverride would be required. I'm also wondering about the best place to add tests for this feature.

[ljacomet]

Last we discussed this issue, we did not find it very compelling to have exceptions to offline based on the hostname.
Also, thinking about the world of containers, a potential next ask could be to whitelist hosts that are to be considered "local" because they are simply running in a container.
The team is not convinced we should start on that path at all.

Another focus that looks much more promising and should - we believe - answer similar use cases, potentially better, would be to have a proper caching mechanism for file based repositories. See #8589 and #8360.

[lacasseio]

Could we look at white-listing the local IP address instead (that is 127.0.0.1)? It's a well-known value that always points to the current machine/container.

The reason for asking such request is around having a public API for custom repositories. At the moment, it is not possible to feed custom metadata to the dependency engine to resolve artifacts outside of maven style repositories. It seems to be a long way off before Gradle offers such public API. However, with the current API, it is possible to use a proxy maven server for this purpose. The issue comes when the computer is offline using --offline. The local server is still running and available but Gradle refuses to query it. It make sense for a local server to always be available given it's local to the machine. The custom metadata is reactive to the request meaning it would not be feasible to generate a static, on-disk, set of metadata ahead of time. There is a need to query various resources to build the required metadata for Gradle to understand.

I could mount a virtual file system and inject my custom metadata via the file system which would result in the same end result: Gradle quering a local server for dependency metadata. However, given the added complexity of such solution, I would rather not implement that.

How can we solve such use case?