https://gradle.com/ logo
Join Slack
Powered by
Can I declare a repository for a single configurat...
# dependency-management
m
Can I declare a repository for a single configuration? (I don't want to pollute the user repositories with a repository that is used for very niche case)
t
Copy code
repositories {
  maven(…) {
    content {
      onlyForConfigurations("fooBar")
    }
  }
}
thank you 3
m
Nice! Thanks
Only issue is I guess it'll break if users define their repos in the setting.gradle with FAIL_ON_PROJECT_REPO...
(If I'm adding the repo in a plugin)
Which I guess can be seen as a feature to avoid plugins downloading from untrusted places...
But on the other hand, plugins can make HTTP request wherever they want...
t
Ah yes, and you can't even tell if that's the case from within a project: https://github.com/gradle/gradle/issues/27260
⭐ 1
m
Which feels like the "good" (albeit not “easy") solution...
👍 1
v
A plugin adding a repository is practically always bad practice, yeah. Or at least if it does unasked or non-optional. Because such plugins cannot be used for example in companies with guidelines "only use internal maven repository proxy" for various reasons. So yeah, usually it is best to have the user responsible to add necessary repositories or maybe provide some function in an extension that does it for the use if he asks to do so, or if doing it unasked then at the very least should provide an option to not do it.
m
I can make any HTTP request I want in my plugin and execute any code but not download from a repository 🙃
I’d get it for configurations that I don’t own ( 
api
, 
implementation
, etc...), you may want to enforce that in a central place (I’d argue a convention plugin would be a much better place). But not being able to define my own configuration feels like an arbitrary limitation
Or maybe the big companies also restrict the HTTP network code with proxies or what not🤔 ? That’d be interesting
v
Points are supply chain security and also licenses. For example by only using an internal motor or repository, it can be ensured that only license-wise good things are available and content can be monitored / checked / verified
But yeah, also proxies or firewalls
m
I’m borderline considering bypassing the repo and doing a plain HTTP call to a jar file to avoid asking the user for an additional repo. I wonder if that’d be caught by the “big companies”
v
By firewall or proxy, probably yes. By "only use internal repository", probably not.
m
Or maybe the big companies also restrict the HTTP network code with proxies or what not🤔 ? That’d be interesting
Yes you would 🙂
It's better to avoid using plain HTTP and it's better to avoid adding a repository. We have "isolated" builds and dealing with Gradle is quite a pain because of the lack of support for https://github.com/gradle/gradle/issues/27808
To give you an idea what we're doing, we have init scripts which remove user declared repositories and replaces them with ours. It not quite practical, and never 100% working/safe.
👀 1
👍 1
e
can you publish whatever you need to maven central? then it would just work for most users (even those with custom repositories as long as they mirror central), and those that it doesn't work for are already accustomed to figuring that out
m
It’s for R8 
<https://storage.googleapis.com/r8-releases/raw>
. I don’t own the releases and don’t really want to fork. I’ll add instruction on how to add the repo
e
I wouldn't say these are the best way to handle it, but I can imagine a few other options • repackage r8 into your plugin like what AGP does. easy, but users have to include it in a parent classpath if they want to override it, and you may have issues co-existing with AGP in the same project • include r8.jar as a resource inside your plugin, and use an artifact transform to extract it from your own plugin dependency if the user doesn't supply a different r8 • ditto but instead of a transform, extract it to tmpdir before loading it at execution time
👀 1
m
Makes sense. In this setup, R8 is used in a 
JavaExec
task so tricks like loading from a parent classloader won't really work. Besides, I'm more and more team "the very bare minimum should be in Gradle build scripts classpaths". Also part of the question is I want it to be easy to change the R8 version for testing, using a more recent version than what the plugin is shipped with, etc... All in all the average user is probably expert enough today to add repos and understand the tradeoff. If this ever becomes more mainstream, let's hope R8 also becomes more stable (no need to change the version too often) and/or released to google/maven central for better inclusion
Thanks all for all the feedbacks and ideas!
v
Actually, if the average user would be expert enough to know what he is doing in Gradle, we would not need the "declarative gradle" project. 😄
➕ 1
m
Of course! Let's say my audience is plugin developers and not end users and I expect them to be more acquainted with the Gradle ways
👌 1
Just bumped into https://github.com/gradle/gradle/issues/28530, lots of options for downloading files there (and some recent activity too)
5 Views
Open in Slack
PreviousNext
Powered by