This message was deleted.
# community-support
s
This message was deleted.
d
gradle-node-plugin out of the box lets you tell it where to get node from so if you put a caching proxy in front of the node.js distribution site you can have that functionality. (or even just declaring an internal repository containing it, since it's using an ivy repository under the hood) But when it comes to the described binary fetching infrastructure I'm not sure how this would improve your situation, you'd still have to maintain some mapping. But for now you probably want to have a look at https://docs.gradle.org/7.5/userguide/declaring_repositories.html#sub:centralized-repository-declaration and perhaps set
RepositoriesMode.FAIL_ON_PROJECT_REPOS
to find which plugins you need to reconfigure
g
I currently use detached resolver + ivy repo with custom layout as generic download/cache facility
🤦‍♂️ that's my issue about detached resolver) Same feeling as when you were searching for a solution, found it and than recognized that you provided it for someone years ago
j
The thing is that yet again it happens that plugins I use fetch stuff from the internet and my build breaks out of the blue because we are getting rate limited. As a user of plugins this sucks and there is not much I can do about it. The only way I could see this getting solved once and for all (for me as a user of plugins) is with gradle providing a standard fetcher that is about as easy to use as
URL(...).inputStream
(which is what this problematic plugin does) so plugin authors use this from the get go rather than me having to bug them to handle this use case. Gradle could then let me configure a cache/proxy for these and hopefully Artifactory, Github, Gitlab, etc. would then provide such an http cache / proxy for this use case.
d
Wouldn't that already work with the current proxy support?
j
You mean in Java?
d
Yeah, if you set
http(s).proxyHost
Gradle is going to respect that and I believe most HTTP libraries will as well https://docs.gradle.org/current/userguide/build_environment.html#sec:accessing_the_web_via_a_proxy
I still recommend setting
RepositoriesMode.FAIL_ON_PROJECT_REPOS
and seeing which plugins fail, and then checking their documentation to see if those let you configure where they're looking for things
j
RepositoriesMode.FAIL_ON_PROJECT_REPOS
seems unrelated to direct downloads? Or am I missing something ?
d
The plugins that use a detached configuration + adding an ivy repository (like the gradle-node-plugin) make use of that, I can swear I've seen it as a recommended somewhere. But even if not,
FAIL_ON_PROJECT_REPOS
is likely what you want 😉
j
Ok. This is not the case here. It is a terraform plugin. Thanks for the pointer on
RepositoriesMode