I'm trying to create a Plugin that configures sonar and creates all the necessary tasks. Until now all was done inside .gradle scripts, however we want to make use of the type safety of Gradle Plugins. No when I import

import org.sonarqube.gradle.SonarExtension

gradle is not able to resolve the class. (

Unresolved reference: sonarqube

) It clearly is there as the package

org.sonarqube.gradle

can be inspected and contains the File

SonarExtension

. Adding the sonarqube plugin in the build.gradle.kts of the plugin project changes nothing. Does anyone have any experience/hints regarding that matter? Thanks in advance.

How is a plugin more type-safe than a Kotlin DSL build script? And no, obviously it is clearly not there. :-D Can you share an MCVE?

No before it was a Groovy .gradle file. And as our team is used to write code in kotlin and using kotlin classes etc. We want to create a plugin instead of just using a script. Yes, it is clearly not, but it should be 😄 I'll create a small example

You add sonar as a plugin to your plugin. So you consume it as a plugin and the source is not available in your source. You’d need to add the plugin as a dependency to your project.

Yes, but how do I do that? How do you add a plugin as a dependency? Removing the

apply false

doesn't change anything. is there something I miss?

You need to figure out the maven coordinates of the plugin’s library and add it the the

dependencies

in the

implementation

configuration

Yes, I tried that but the version listed in mvnrepository.com seems not to exist: https://mvnrepository.com/artifact/org.sonarqube/org.sonarqube.gradle.plugin/4.3.1.3277 https://maven.eea.sk/ui/native/public/org/sonarqube/org.sonarqube.gradle.plugin/4.3.1.3277/

No before it was a Groovy .gradle file. And as our team is used to write code in kotlin and using kotlin classes etc.

Yeah, that's clear. What I wanted to say is, if all you want is type safety, you can just use Kotlin DSL instead. If there are other reasons like cleaner build script, reusing the logic in multiple projects and so on, that's a different story then of course. :-) Regarding the problem it seems you found out already. The artifact you found there is the "plugin marker artifact". It is always

<plugin id>:<plugin id>.gradle.plugin:<plugin version>

and is the way how the id in the

plugins

block is translated to a dependency. Some plugins also publish them to other places like Maven Central, but for just you need the plugin portal repo, yes. Alternatively, for example if you don't like to use transitive dependencies, you can also depend on the actual code artifact directly. For that either open the plugin portal page of the plugin and find the coordinates in the legacy application section, or just have a look on what the marker artifact depends.

Ah thanks. That's great to know. Is this somewhere listed in the documentation?

The marker artifact?

Ah never mind, just found it: https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers Thanks a lot for your help

Btw. as it is about plugins, you should

includeBuild

within

pluginManagement { ... }

, not top-level. :-)

You mean in the

settings.gradle

, right? What does that change? (Sorry for all the questions, we just started to migrate to the new dsl)

Regarding project plugins not much besides that it is cleaner. The main actual difference is, that you can also have settings plugins then that you can use right in that settings script.

Ah. You never stop learning new things 😄 Thanks for the input, I changed it.