https://gradle.com/ logo
Join Slack
Powered by
Hi, is there any option to avoid repository url/co...
# community-support
н
Hi, is there any option to avoid repository url/configuration duplication? We have 2 nexus repos urls for custom snapshots/releases versions and currently it's at 3 places: buildSrc, settings.kts pluginsManagement and dependencyResolutionManagement
v
• ditch 
buildSrc
• instead have an included build like 
build-logic
• have an additional included build like 
repo-conf
that does not have dependencies and thus does not need a repository • in 
repo-conf
define a settings plugin that sets the repo as plugin repo and dependency repo • include 
repo-conf
in 
build-logic
and the main build and apply the settings plugin in both
👀 1
• If you need further settings plugins from those Nexus repos, in your main build, depend on them from the 
build-logic
build and make sure it is also added to the classpath of the main build's settings script • If you need furhter settings plugins from those Nexus repos in your 
build-logic
build, you probably need yet another build where you depend on those and then use that to get the plugins to the `build-logic`'s settings classpath
н
thanks, I will check more info on build-logic approach!
👌 1
I don't get, does composite builds allow to have script plugins? I am getting "Plugin [id: 'repositories-config'] was not found in any of the following sources:". If it should be the class based plugin, then I will have to add repositories for java-gradle-plugin. The documentation doesn't have too much details here :(
v
A composite build allows to have anything. And to great lengths 
buildSrc
is anyway almost equal to an included build, just some subtle differences. One is, that 
buildSrc
uses a default build script that applies the 
kotlin-dsl
plugin if you do not have an explicit one. That plugin is the one making precompiled Kotlin DSL script plugins possible, just apply it and it should work, unless something else is wrong. Btw. you should have a dot somewhere. Plugin IDs without dot should only be used by built-in plugins to reduce risk of clashes.
н
Yep, thats what I talking about, when I am applying the plugin I am getting error that no repositories found for external dependencies So kinda I have to add repos at those repo-conf, so they still will be duplicated with repos at repos-conf plugin I guess?
The only thing that come at my mind is to apply plugin as file at plugin's settings.gradle
Copy code
apply(from = "src/main/kotlin/com/example/repo-configuration-plugin.settings.gradle.kts")
don't know if there is better approach available
v
So kinda I have to add repos at those repo-conf, so they still will be duplicated with repos at repos-conf plugin I guess?
Well, if you want to use Kotlin DSL precompiled script plugins there, I guess so. My premise was, that you do the bottom-most repo-configuring plugin without the need for any 3rd-parts dependencies and thus no repositories. So you would probably there have to develop that plugin in plain Java.
don't know if there is better approach available
Those (things you use with "apply from") are called legacy script plugins. They have many quirks and are highly discouraged. I wouldn't recommend using them.
2 Views
Open in Slack
PreviousNext
Powered by