https://kotlinlang.org logo
#feed
Title
# feed
b

Big Chungus

04/03/2021, 4:19 PM
Hi all. I've created a GitHub project template for kotlin multiplatform libraries. It comes with a lot of preconfigured goodies to help you kickstart your projects. Star if you like it and don't forget to leave any feedback you might have in a form of Issue, PR or even DM here. Currently it features the following: • Native target grouping and shared sourceSets • Wrapper library module that declares dependencies on all lib modules • Uniform configuration via
allprojects
• Local
test
module for shared test utilities (a helper function to run coroutine tests in common sourceSet included) • Local
sandbox
module for easy library consumer side checks • Publication control to avoid multiple publications for targets that can be built on multiple hosts •
ktlint
plugin with automatic
git-hooks
refreshVersions
plugin for better version control • Main host for publications can be changed via
gradle.properties#project.mainOS
property P.S. Commonizer breaks if I bump kotlin version to 1.5.0-M2, Might be something JB folks want to look into as a potential regression.
👍 2
👍🏼 1
v

Vampire

04/03/2021, 5:17 PM
I didn't look at it, but "Uniform configuration via allprojects" sounds very non-idiomatic if you care about that. Better practice is to have convention plugins that you apply to the single projects manually.
b

Big Chungus

04/03/2021, 5:45 PM
Interesting point. last time I've tried conventional plugins with build.gradle.kts, I kept getting resolution errors. Things might've changed by now. I'll give it another go 😄
v

Vampire

04/03/2021, 6:01 PM
Or maybe you made some mistake? 🙂 Never seen resolution errors with convention plugins or I don't understand what you mean.
b

Big Chungus

04/03/2021, 7:42 PM
Are we talking about the same thing? I meant this:
Copy code
apply(from="another.build.gradle.kts")
j

Javier

04/03/2021, 7:56 PM
That should not work
I think the id should be different
maybe apply(from = "another.build")
b

Big Chungus

04/03/2021, 7:57 PM
Don't confuse it with
apply(plugin="some.plugin.id")
j

Javier

04/03/2021, 7:57 PM
but I don't know exactly, I should not use apply fun
Ah, yeah, you have right
Anyways, I should avoid both
b

Big Chungus

04/03/2021, 8:00 PM
They both have their usages. Consider this case applying mpp plugin to all modules so you could set some common configs
Copy code
plugins {
  kotlin("multiplatform") version "420.69"
}

allprojects {
  apply(plugin="org.jerbrains.kotlin.multiplatform")
  kotlin {
    explicitApi()
    jvm()
    js { nodejs() }
  }
}
v

Vampire

04/03/2021, 8:19 PM
No, you are not talking about what is called a convention plugin. What you are talking about is a script plugin. There you for example cannot use a plugins block inside and don't have type-safe accessors available which makes them look clunky. A convention plugin is a pre-compiled script plugin that you have in
buildSrc
or how I prefer it in an included build. In such script plugins you can use the plugins block and also get type-safe accessors for these. They look almost the same as when writing a normal build script. And you apply them just as other plugins in the plugins block of the respective projects.
b

Big Chungus

04/03/2021, 8:24 PM
Yeah, was JUST reading about it 😀 That definitely looks cleaner, will refactor tomorrow.
l

louiscad

04/04/2021, 12:36 PM
Me, working on changing #gradle-refresh-versions setup 🙈
b

Big Chungus

04/04/2021, 12:38 PM
Any breaking changes on the horizon?
l

louiscad

04/04/2021, 12:40 PM
Fortunately, no 😉 I am working on some code that will automatically replace the old bootstrap with the new setup way (a settings plugin + an extension). It takes a lot of time to do it right, but it looks like it'll be worth it.
🎉 1
b

Big Chungus

04/04/2021, 12:56 PM
Can't wait to try it out!
l

louiscad

04/04/2021, 12:56 PM
Tests and pair programming (aka. live code review) will try it first!
c

christophsturm

04/04/2021, 2:57 PM
idea is pretty buggy with convention plugins. the workaround is to exclude buildSrc in the compiler paths
in  
Settings->Build->Compiler->Excludes
(my youtrack ticket about it got set to private for some reason)
l

louiscad

04/04/2021, 6:44 PM
I'd ask the folks to make it public again, or I'd create a new one and link it in the comments
c

christophsturm

04/04/2021, 6:46 PM
I’ll just wait for it to be fixed
v

Vampire

04/05/2021, 12:29 AM
Never had real problems with convention plugins in IJ. Granted nowadays I only use included builds and not buildSrc, but even with buildSrc I cannot remember significant problems.
What problems did you have?
c

christophsturm

04/05/2021, 10:35 AM
there were 3 problems: scratch files did not work, jps tried to build the files in buildSrc as kotlin scripts and failed, and “analyze code” analyzes autogenerated code in buildSrc. I have workarounds for the first two.
j

Javier

04/05/2021, 12:22 PM
I am using them since 2019 with no issues. I use scratch files usually too.
b

Big Chungus

04/06/2021, 11:50 PM
Did some refactoring (mainly gradle conventional plugins introduction, thanks to @Vampire) and added matrix-based GH actions to test and publish libs on all native hosts. This now warrants a v1.0.0 "release" As always, feedback is most welcome.
4 Views