https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
c
one approach is to create a Setting plugin that applies the repository
r
And does Settings plugin work for this other use case?: • Reuse a function that returns something
I see it’s something like this: 
class SettingsPlugin implements Plugin<Settings> {..}
Where you override this 
apply
function, doesn’t seem to be a place where you can expose functions and use it in other places
a
if you want to add a dependency that will be available in a build script (be it 
settings.gradle.kts
or 
build.gradle.kts
) there are basically two ways Either you add a dependency using the buildscript block
Copy code
buildscript {
    dependencies {
        classpath("org.apache.commons:commons-lang3:jar:3.12.0")
    }
}
This is good for dependencies that are published to a Maven repo you can add, but it’s not so convenient for project-local utilities that you don’t want to publish The alternative is to use a composite build. This is probably what you want. 1. create a new directory in your project, 
my-settings-utils
, and because this is going to be an independent Gradle build (not a subproject) create a 
build.gradle.kts
and a 
settings.gradle.kts
2. in 
build.gradle.kts
, apply the kotlin-dsl plugin 3. Create your utility class - 
my-settings-utils/src/main/kotlin/RepoUtils.kt
4. add 
includeBuild("./my-settings-utils")
in the base project settings file, as detailed in the docs 5. my memory is vague here, but I think you need to create a settings plugin, else Gradle won’t add the 
my-settings-utils.jar
to the 
settings.gradle.kts
buildscript classpath. So just create a dummy precompiled script plugin - 
my-settings-utils/src/main/kotlin/my-repos.settings.gradle.kts
- which can be empty, it doesn’t need any content 6. Now apply the plugin in 
settings.gradle.kts
Copy code
plugins {
  id("my-repos")
}
And the JAR will be added to the buildscript classpath, and because 
RepoUtils.kt
will be compiled into the same JAR as the dummy plugin those functions will be available
v
Copy code
// the plugin management block is evaluated first separately, do not change this to
// listOf(pluginManagement.repositories, dependencyResolutionManagement.repositories)
// instead that would change the semantics
pluginManagement {
    listOf(repositories, dependencyResolutionManagement.repositories).forEach { repositories ->
        repositories.apply {
            maven("<https://nexus.company.com/repository/maven>") {
                name = "Company Nexus"
            }
        }
    }
}
r
Thank you both @Adam & @Vampire 🙇 It seems that Vampire solution works for my 
settings.gradle.kts
and can use the repositories function without duplicating them! And now I have another small question So if this block is evaluated first separately it means that it cannot access anything outside of 
pluginManagement
? And neither someone can access any function found inside this block, right? So let’s say in my 
build.gradle.kts
. it’s impossible to access any function I’ve created there in my 
settings.gradle.kts
right? And I guess 
gradle.settingsEvaluated
doesn’t add anything here
v
Almost correct. The effects of 
pluginManagement
are seen outside too. That's why you can confiugre the 
dependencyResolutionManagement.repositories
inside the block while you would usually do it outside. So you could define some function and store it in an 
ext
property within 
pluginManagement
and then also use it outside, retrieving it from the extra properties.
r
I’m trying to verify this statement but that doesn’t seem to work, am I doing it wrong? I’m setting in the 
pluginManagement
block this: 
extra.set("dummy", "dummy")
And on 
build.gradle.kts
I read it like this: 
extra.get("dummy") as String
And it says, it cannot get property “dummy” So I’m not sure if I’m doing something wrong or I can’t get it in the 
build.gradle.kts
at project level
v
All extension-aware objects have extra properties. So you probably do read it from a different object than you set it to
👍 1
r
Ok, I woke up today and realized that outside means outside of the scope (This case: 
pluginManagement
) not in different files. (It helps to re-read again after 8h of sleep 😂) Got it, thank you! Although my problem has been partially solved by not duplicating repos (Which is amazing 🙇) I have the feeling that there’s no way to share the function nor results or use the same function in both places: 
pluginManagement
& 
build.gradle.kts
root level.
v
Actually, it means both. It also works in different files, if you use the same object, like the 
Gradle
instance. It just gets more dirty to do so. :-D especially as there should be no reason to do so. The only thing could be repositories and when defining them centrally using 
dependencyResolutionManagement
, there is not much point in declaring them in the build script again. I even usually forbid project repositories.
r
Oh you’re right, I was able to share the value I set in 
settings.gradle.kts
to my 
build.gradle.kts
buildscript block!! In my 
settings.gradle.kts
pluginManagement block I set it like this:
Copy code
(gradle as ExtensionAware).extensions.extraProperties.set("dummy", "dummy")
Then on my 
build.gradle.kts
buildscript block i do the same:
Copy code
println("Buildscript: ${(gradle as ExtensionAware).extensions.extraProperties.get("dummy")}")
Damn that was a nice finding, thank you!! 🙇
I guess it’s not recommended/or dirty as you said… But I dislike a lot duplicating code… And I guess since this is available in my buildscript it should also be available to other subprojects so it’s kind of reusing the code… (I think)
v
Yes, code duplication is bad. 🙂
s
@Roberto Fuentes trying to understand what you're solving, because I have\am running into what sounds similar. I have realized that settings.gradle, for say...a custom Maven host repo, can't put it in a project because it won't know where to find the Conventions Plugin. But I don't think there's a good way to consolidate it. I'd still end up with extra code in settings.kts... Maven had a settings.xml that would specify this and you wouldn't have to do it for every perfect... I considered putting it into init gradle or something. It's all just used internally in the company, so "host it externally"isn't an option Probably not worth much effort for me to do it either way I guess, versus just copy paste a bunch. Should be set it and forget
r
Hey @Shaun Reich, sorry for the delay, it definitely sounds similar to my issue Maybe some reproducible code or example code would be nice to visualize your issue. What I did is use @Vampire’s solution and leverage all the repositories into the 
pluginManagement
block. Inside there I define the • 
repositories
block (Which is for conventions plugin) • 
dependencyResolutionManagement
◦ 
repositories
block for dependencies
s
okay, that is what i m doing too
459 Views
Open in Slack
PreviousNext
Powered by