1. Background: I have some Gradle custom plugins, ...

# gradle

[El Zhang]

1. Background: I have some Gradle custom plugins, and want to have a sample app to showcase all usage of them. Currently I use Gradle Kotlin DSL, and wish all *.gradle.kts are flexible to add/remove easily if developer wants. So I designed a arch like below diagram.
2. As we all know *.gradle.kts files can not place in the same place as build.gradle.kts and let build.gradle.kts apply it if we need to apply some plugins in this *.gradle.kts (while Groovy DSL works in this case), the common practice is move them to /buildSrc or a composite-build module, let say /build-env .
a. If /buildSrc , seems it does not support include() includeBuild() to include plugin source modules
b. if /build-env , I can refer plugin source via either include() or includeBuild() , however it does not have kotlin-dsl-accessors generated, so I can not use plugins{ id("slack")} with slackNotifyExt{ channel = "" } dsl extensions (but looks like apply<Plugin>() and configure<Ext>() works)
I'm wondering what is the best practice for this scenario? Below is a simple diagram to show my proposal arch.

[El Zhang]

For some error detail:
1. BuildSrc + includeBuild -> Cannot include build 'slack' in build 'buildSrc'. This is not supported yet.
2. BuildSrc + include ->
/buildSrc/settings.gradle.kts

include(":slack")
project(":slack").projectDir = file("../plugins/slack")

buildSrc/build.gradle.kts

implementation(project(":slack"))

error:


Could not determine the dependencies of task 'buildSrccompileGroovy'.

Could not resolve all task dependencies for configuration 'buildSrccompileClasspath'.

> Could not resolve project buildSrcslack.
Required by:
project :buildSrc
> No matching configuration of project buildSrcslack was found. The consumer was configured to find an API of a library compatible with Java 8, preferably not packaged as a jar, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm' but:
- None of the consumable configurations have attributes.

[Vampire]

Hard do say what your actual problem is, as I didn't fully understand your approach from the description. An MCVE would help much in understanding what you are trying and where your problem is.

But some comments to what you stated.

As we all know *.gradle.kts files can not place in the same place as build.gradle.kts and let build.gradle.kts  apply it if we need to apply some plugins in this *.gradle.kts (while Groovy DSL works in this case)

Seems your range of "we all" is much too narrow as I for example know the exact opposite. You can perfectly well put *.gradle.kts besides build.gradle.kts and apply them as "normal" script plugins without any problems just like with Groovy DSL. You just have some restrictions, like not being able to use a plugins block and due to that not having generated accessors available. But if you write them without the generated accessors or plugins block, they work just fine. It is just much more inconvenient than using them as pre-compiled script plugins, not only because the restricted syntax within the script plugin, but also because when it is a pre-compiled script plugin that you apply via plugins block you also get accessors for the things the script plugin did in the build script where you apply it to.

If /buildSrc , seems it does not support include() includeBuild()  to include plugin source modules

That's only to one third correct.
First third: buildSrc is a full standalone multi-project build, you can use include as much as you want.
Second third: it is correct that you cannot use includeBuild within buildSrc
Thrid third: since 6.7 buildSrc can see builds that were included by the main build, so if you use includeBuild in your root settings.gradle(.kts), then buildSrc can see and use that included build.

if /build-env , I can refer plugin source via either include()  or includeBuild() , however it does not have kotlin-dsl-accessors generated, so I can not use plugins{ id("slack")}  with slackNotifyExt{ channel = "" } dsl extensions (but looks like apply<Plugin>() and configure<Ext>() works)

Then you maybe did not apply the right plugin or made some other error.
precompiled script plugins always get accessors generated for things applied via plugins block within them, no matter whether it is in buildSrc, an included build or a standalone build.
As I said before, if you provide an MCVE where you show what does not work that you think should work, maybe we can help and tell you how to do it properly or why it does not work as expected.

[El Zhang]

Thanks for ur help, will provide a MCVE asap.

[El Zhang]

Hi @Vampire Thanks for your advice from last message. I think I have done my MVCE, I actually fixed all problems I encountered and made it work already. This is quite an amazing work that built a MVCE and then cleared all uncertain things. I would like to let u know the repo and see what can be improved.
https://github.com/2BAB/KTS-BuildSrc-Composite

Btw, is there anyway I can buy u a coffee? Very appreciate for you help =)

[El Zhang]

To recap my target: I have some Gradle custom plugins, and want to have a sample app to showcase all usage of them. Currently I use Gradle Kotlin DSL, and wish all *.gradle.kts are flexible to add/remove easily if developer wants. I basically built 2 samples to implement my thoughts, one bases on buildSrc, the other one is composite-build. I made the safe accessors work (this is one of the most important part I want, or I can basically put them in same the place as build.gradle.kts haha)

[Vampire]

I would like to let u know the repo and see what can be improved.

Glad that you solved your problems already,
But I fear I don't have the time to "see what can be improved".
If you have specific questions, sure, state them, but I'm not going to review the whole build.

Btw, is there anyway I can buy u a coffee? Very appreciate for you help 😃

Totally not necessary, but if you insist, you can for example send some Coffee via PayPal: https://paypal.me/BjoernKautler 🙂

[El Zhang]

But if you write them without the generated accessors or plugins block, they work just fine.

Hi @Vampire , I have a follow-up of your previous comment. I tried to implement the plugin config script as you mentioned, but encountered some problems:

1. There are a plugin and its extension class declared in /build-env/plugin-config/src/main/kotlin
2. The /app/build-env-config.gradle.kts script can refer the plugin id and apply it successfully
3. However, both 2 classes(plugin&extension) are not available from the context of /app/build-env-config.gradle.kts (can not import and configure the extension)
The MVCE can be found from below link: https://github.com/2BAB/KTS-BuildSrc-Composite/tree/main/config-gradle-kts

Thanks.

[Vampire]

build-env-config.gradle.kts is a normal script plugin, not a precompiled script plugin. That means it had certain limitations. One is for example that you cannot use the plugins block, but only the legacy way of applying plugins using apply. As a consequence you do not get any accessors, as you only get them in precompiled script plugins and only for built-in stuff and things you applied via plugins block.

Actually I wonder that applying by id when worked if it really did. I mean to remember that applying by id does not work in normal script plugins, but only by class.

To add the classes to the class path, you need to add a buildscript block where you define the dependency if you really want to use a normal script plugin.

[El Zhang]

1. Yes, I'm doing in the legacy way of "apply", I understand it's a normal script plugin
2. There is a print in the plugin apply method println("BuildEnvStubPlugin applied.") it did printed.
3. Just now I add the buildscript to build-env-config.gradle.kts , though the IDE still can not detect the classes, but the build is working. (Env: IDEA 2021.1.2-rc, Gradle 7.0.2)

[El Zhang]

I think that's the correct way to make it work eventually(legacy apply), though no perfect.

[El Zhang]

Thanks @Vampire 👍

[Vampire]

Maybe this is the cause IJ cannot display it properly:

[El Zhang]

https://youtrack.jetbrains.com/issue/IDEA-270097 I raised a ticket to JetBrains, it got updated by relating to some known issues, so I guess it's something they haven't supported yet from UI, though Gradle is supported. 😄