https://kotlinlang.org logo
Join Slack
Powered by
Should the includeBuild feature work with Multipla...
# gradle
h
Should the includeBuild feature work with Multiplatform plugin using JS target only? I included the build but Gradle is unable to substitute the dependencies with my included project.
c
I believe it should work without issues, but I don't remember if I ever attempted it… do you have any kind of error message?
h
Well, only the normal one it can't find my dependency from maven central because it's not uploaded yet and it should be substituted. My group and name are the unchanged. A similar setup works like a charm with other Kotlin JVM projects, so I expect it should work for MMP too.
m
I'm using it with KMP with no issue (but I have more targets than plain JS)
Only reason that comes to mind is if maybe you have 
resolutionStrategy.useGlobalDependencySubstitutionRules.set(false)
somewhere?
h
Nope, but I include the same project twice, once in my build logic because the project contains a gradle plugin and in my root project too 🤔 But again, this (strange) setup works for JVM projects
Okay, got it: I added the same includeBuild twice to substitute the gradle plugin marker but including the same build twice with different dependencySubstitutions which does not work. You can include a build twice without custom substitution rules. My similar setup works because the marker plugin was uploaded once so Gradle can resolve the underlying implementation module and substitute it. Workaround: Either just publish the marker plugin once or just use the underlying module in 
implementation
.
today i learned 1
m
Oh wow, good find 👏
v
Actually, best is to not need manual substitution. As long as you do not do uncommon things like changing the coordinates in the publishing block and similar, substitution should just work.
h
Yes, manual substitution is exactly what I want to avoid but it is needed when referencing to the Gradle marker plugin artifact.
c
Is it? I have included builds which include Gradle plugins, with no particular config.
➕ 2
h
Unless Gradle would enforce/add a default value with 
:gradle-plugin
as module name
Did you ever published the included Gradle plugins?
m
I have included builds which include Gradle plugins, with no particular config
Same, it's actually the main reason why I use included builds. I think I've seen it working without publishing but would not put my hand on it.
h
Well, I will upload my code anyway, feel free to test it out 😛
👍 1
v
If I got everything right actually neither me nor @mbonnin, nor @CLOVIS tried what you say. I think they mean you use a plugin in the plugins block and replace it from an included build. And if I got it right you are depending on the plugin as dependency, depending on the marker artifact. I would have thought it should work too, but did not try that constellation yet.
🌟 1
h
It was my first time too. But if you want to try it, here you are, https://github.com/hfhbd/actions and https://github.com/hfhbd/kotlin-actions, checkout both projects in common parent dir, like 
~/Downloads/actions
and 
~/Download/kotlin-actions
. And change the file https://github.com/hfhbd/actions/blob/9d8ef2a7895f28fa1b2d3441085c9f78581357c8/gradle/build-logic/build.gradle.kts#L7
v
Ah, the building of the plugin works just fine. Just then when applying the plugin, it cannot be found. And how / where did you solve this using manual dependency substitution? As long as the plugin marker is not available published, I would have said you can only do it with directly depending on the code artifact. Maybe the whole thing is worth a ticket though anyway.
h
directly depending on the code artifact.
This is exactly what I did.
v
In that example yes, but I thought previously you used some dependency substitutions?
h
Ah yes, in the build logic settings gradle I substituted the marker plugin with the real code artifact and in the root settings I substituted the runtime (without success).
v
Yeah, I think because there the included build is only for project dependencies, not for plugin dependencies. And when including in the plugin management block, you cannot define substitutions as afair there it only works to substitute plugins applied by plugins block, not dependencies of plugins.
That's why I said I think there is a gap that should warrant a GitHub issue, basically the MCVE you sent above
19 Views
Open in Slack
PreviousNext
Powered by