Slackbot
02/01/2022, 10:43 PMephemient
02/01/2022, 10:46 PMapp resolves the transitive dependencies of library itself, the repositories in use by library are not exposed in any wayEli Graber
02/01/2022, 10:46 PMapp to delegate to library for resolving the dependencies?ephemient
02/01/2022, 10:46 PMEli Graber
02/01/2022, 10:47 PMrepositories to my top level projects?ephemient
02/01/2022, 10:47 PMgrossws
02/01/2022, 11:23 PMsettings.gradle[.kts] (or build.gradle[.kts]). Many do so both on local developer workstations and ci servers.
Another approach is to use settings plugin to externalize repo definition. I personally use this approach lately with my own plugin published to gradle plugin repo and private repo parameters in global gradle.properties file (or via command line parameters on GitHub Actions).Eli Graber
02/01/2022, 11:28 PMartifact is that the repo it lives in is authenticated by a secret that lives in the project itself (decrypted using ejson ).
In my convention plugin I use an ejson library to decrypt the secret when adding the repository, but my understanding is that if I use dependencyResolutionManagement I won't be able to use the ejson library (because it isn't in the classpath yet).
I'd rather not externalize this into a plugin or script.ephemient
02/01/2022, 11:34 PMdependencyResolutionManagement just like in any other scriptEli Graber
02/02/2022, 12:07 AMenableFeaturePreview("VERSION_CATALOGS") in settings.gradle.kts 🤔Eli Graber
02/02/2022, 12:22 AMbuildscript below pluginManagement