From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

This is the documentation on how you can configure IVY repositories:
<https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:ivy_repositories>

With `patternLayout` , you can define your own layouts. I used that to access different kind of existing file structures "as Ivy repo" in the past. What do  you have in your structure that cannot be expressed in the _patternLayout_ configuration?

Thanks for taking a look. The problem is that we use more (custom) placeholders in our patterns. This was supported with a custom FileSystemResolver in the ant/ivy builds. Afaik these kind of customizations are not possible with Gradle. And the number of available placeholders (basically organization and module) are not enough.

That's why I thought a custom http based ivy repo (as a bridge) could do the trick. We could port our customization into that repo and it would be transparent from Gradle perspective.
Gradle would only see a standard http ivy repo.

So that's why I would like to learn more about the expected contract/interface on http level from Gradle ivy support perspective. Does it only send GETs? Does it only expect response status codes 200 and 404? Is there any caching? Do http headers (request or response) have a role?

Thanks for clarifying. It's simple `HEAD` and `GET` requests per file. Nothing fancy.

Gradle looks at the location according to the defined repository and pattern. Assuming we use the default IVY pattern, have  a dependency `org.example:moduele-a:1.0`  and a repository `<https://myorg.com/repo/>` , Gradle would (AFAIK):
• Send a `HEAD` to `<https://myorg.com/repo/org.example/module-a/1.0/ivy,xml>`
• If the file exists, Gradle fetches it via `GET` (if not, it goes looking in the next repository if there is one)
• Next steps depend on what's in the file, but it's all normal `HEAD` /`GET` and always one request per artifact or metadata file
You can also configure a repository to have aritfacts (Jars) without metadata. Then Gradle would look via `HEAD` for a Jar file at the location directly, or you configure it to have Gradle Metadata, then it would look for that `.module` file: <https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:supported_metadata_sources>

Thanks. Does Gradle cache the responses? Including the 404s?

If it successful the response it cached. As it is assumed that the repository is immutable. Gradle wouldn't query it again if metadata and artifacts are in the local cache.

For `404` , I think it is cached if the things are found in one of the next repos (not 100% sure). If it is not found at all, there is no caching.

To your original question: I am not aware on any writeup on this. One thing that can help you to understand is using `--scan` , if you can. There is a section in the Build Scan where you can see all the requests that were done during a build. Can help you to debug and test. E.g: <https://scans.gradle.com/s/ejjqimju7iz3q/performance/network-activity>

And you can force Gradle to re-download the metadata with `--refresh-dependency` , which can also be helpful to debug things.

In general, I think your idea with the intermediate web app that acts as repo is a valid approach.

Thank you for your comments. Really helpful. If I would need to clear the cache, how can I do that? Essentially with the refresh dependency flag? As for seeing the requests maybe Gradle with debug logging would log those as well?

Running Gradle with `--info`  or `--debug`  probably also logs the requests. But there is a lot of log output you would need to filter.

`--refresh-dependency` ignores the metadata cache. Jars might still be taken from cache normally, but only if the checksum matches. This is like another caching level. For this the repo also needs to serve the checksums as separate files, but I think it also works without. So your "custom repo" does not necessarily need to support that.
In any case `--refresh-dependency`  should be enough-

But if you want to make sure the whole cache is cleared, you can delete your Gradle user home `.gradle/caches` or set the user home to a different folder when running the build: `-g some/tmp/folder` .