This message was deleted.

hi 👋 Move your utility functions into a separate

.kt

file, then you'll be able to import and use them.

There are actually two points. 1. What Adam said. Imagine all contents of a Kotlin script as being inside a class body (that approximately is what happens), so you're function is only available within that scope. You can either move it to a

.kt

file to be able to use it, or instead work with adding extensions on which you call their functions. 2. Your function will not work in its current state. You define it as extension function of

SonarExtension

, so to call it you would after the move do

sonarqube { setProjectKey(...) }

. Your context is the extension already, so you need to remove the

sonarqube { ... }

from the function.

Thank you for your response thank you I created the package as described by @Adam and @Vampire, declared the extension function in a

.kt

file, and imported it from the submodule's

build.gradle.kts

, and it works 👍 I have a few more questions. I'm new to this, so there's a lot I'm not sure about 😅 1. Is using

afterEvaluate { ... }

an anti-pattern? Is there any explanation or reference for this? 2. I'm curious about the identity of the

Convention_project_gradle

I mentioned in the previous thread. Do you know somewhere I can check the Javadoc for this class? 3. The structure I created works, but I'm not sure if it's a commonly used structure. Do you have any recommendations for sample projects that use the

Convention Plugins

?

re 1. Yes. Its main effect is, that it introduces ordering constraints, timing problems, and race conditions. Using it is most often just symptom treatment, shifting the problem to a later, better hidden, harder to reproduce, harder to debug, and harder to fix point in time. It is like using

SwingUtilities.invokeLater

or

Platform.runLater

to "fix" a GUI bug. You should avoid it whereever possible. There are some rare cases like when a plugin itself uses it and you have to delay to thereafter for some reason, or when you need to bridge new lazy APIs to old eager APIs in some cases. But it is always preferable to not use it. re 2.

convention.project.gradle.kts

=>

Convention_project_gradle

class

foo.bar.gradle.kts

=>

Foo_bar_gradle

class It is just the compilation result of the Kotlin Script and nothing you should ever care about directly. Consider this an implementation detail you should never rely on directly. re 3. Having such an extension function that you then use is not really a convention plugin. Convention plugins are plugins that you apply to your projects and that do some plugin application and configuration - establishing your conventions. These can be plain old normal plugins, precompiled script plugins, or whatever. They can be in

buildSrc

or an included build or published, ... There are many projects out there that use convention plugins. But it always depends on what you need. Even some of the projects generated by the

init

task contain convention plugins.

Your explanation has deepened my understanding. Thanks for the detailed explanation, @Vampire thank you