This is more of a gradle question, but it's really...

# compiler

[Youssef Shoaib [MOD]]

This is more of a gradle question, but it's really specific to compiler development
How can I bootstrap my compiler plugin? I tried to simply apply the plugin with a previous version (i.e. a version on maven central that isn't in my included buids) but gradle just blindly sees that the plugin artifact is in my included builds and simply uses it without looking at the version, which results in a circular dependency and my project not building.
I can see some mentions of this in the kotlin compiler source itself, but I don't quite understands how it works. Is there just a simple fix to make it so that Gradle doesn't look for gradle plugins in included builds?

[dmitriy.novozhilov]

Hi. What do you mean by bootstrap in this context? Do you want to compile your plugin using same plugin?

[Youssef Shoaib [MOD]]

Yeah I meant as in compiling the plugin with the previous version of it. At first I didn't quite get what gradle's issue was since I thought it was that it was resolving the usage of the gradle plugin using the sibling project, but thankfully it wasn't doing that. The only issue (which gave me a cyclic dependency) is that I had my kotlin-plugin and it was using my published gradle plugin as expected, which then meant that the kotlinCompilerPluginClasspathMain configuration had a dependency on kotlin-plugin, but gradle resolved that to be itself and not the published version. In other words, in project :kotlin-plugin , which was set up to be version 0.1.3, I used my plugin in build.gradle.kts, which resolved to the published 0.1.2 gradle-plugin, but then since ``kotlinCompilerPluginClasspathMain` depended on kotlin-plugin, even though it depended on 0.1.2, gradle still resolved it to the project kotlin-plugin i.e. itself, even though that had version 0.1.3.

I did find a solution, though. Digging around, it seems like that people were either trying to use their gradle plugins on the same project, and so their solution was to dynamically compile the groovy code, which isn't an option here. Others though wanted to use a published version of their project for rebasing, and their solution was to change the group of the project temporarily.

What I ended up doing is that I simply set the version in my project :kotlin-plugin to be 0.1.1 so that it's lower than the requested 0.1.2 and so Gradle was forced to use the published version, and then I made sure to set the correct version in my maven publishing configuration.

Here's the diff from that commit.

[Youssef Shoaib [MOD]]

Is there any elegant way to do this though? I'm not really a Gradle wiz so I have no idea. I just simply want Gradle to resolve the dependency on my.group:kotlin-plugin:0.1.2 to be the published version instead of resolving to itself (because it itself has version 0.1.3)

[dmitriy.novozhilov]

Honestly, IDK.
In kotlin project for local bootstrap we use changing dependency on all kotlin components (stdlib, gradle plugin, etc) version from 1.x.y-dev-abcd to 1.x.255-SNAPSHOT, which is published to maven local.
For global bootstrap we deploy some build to bootstrap repo and only after that update bootstrap version in project itself

[Youssef Shoaib [MOD]]

Okay yeah that's good to know that even Kotlin does a similar thing with changing the version. I think I'll stick to permanently changing the version in gradle for now. It's really annoying that even with custom conflict resolution gradle still doesn't allow this
Thank you!