I’d like to get my team to use Kotlin Multiplatform as we could share a lot of code, but I’ve encountered some obstacles myself that make it impossible to work with it effectively at the moment.
I would be grateful for a little discussion about possible best practices and caveats with our current setup!
We currently use a JVM-backend, which serves as an HTTP server, similar to Ktor. The frontend is a simple vue-app written in Typescript.
Contrary to the examples and Gradle templates, these are not two projects:
Our bundled fullstack app is one fat JAR.
How would you structure your Maven project, then?
The current setup is as follows:
|- resources (we want our frontend here!)
The “assemble” module will build the frontend and put it inside the backend/resources folder (as we cannot do this inside the root module).
This kinda works, but it’s not as smooth as Gradle:
- How would you handle auto/hot-reload? File watchers with “compile-on-save” are quite cumbersome.
- Where do you declare frontend dependencies, inside the package.json or in the pom.xml?
Both options exclude some features; a dependency inside package.json will not be detected by Kotlin, a dependency inside pom.xml will not put the package inside node_modules. One solution would be to declare it in both, but why the redundancy?
Nevertheless, I was not able to import the kotlinx.html package as the browser was complaining about missing scripts. Is it necessary to declare the dependency in the index.html as well?
The current workflow with Kotlin Multiplatform and Maven is extremely confusing and not as flexible and smooth as I’d like. But maybe I’m just missing something.
Kotlin MPP only supports Gradle: https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html. We don’t plan to add Maven support currently.
Is there a rough time plan for Maven support yet? I would like to try Kotlin MPP, but I would need to invest time into learning Gradle just for that. I wonder whether I should rather bite the bullet or just wait for Maven support.
Maybe I missed some annoucement but I don’t think they really consider adding maven support. At least not before MPP get’s a full stable release. So unless you want to wait a year or more you should just learn a bit of gradle.
The model of a multiplatform project is too complex to even consider declare it in XML. Also many tasks are project specific and requires a level of flexibility that Maven just can’t offer. Asking such a question means that probably you do not know Gradle at all and mistakenly thought it is similar to Maven!
Give Gradle a shot. It will be hard at first, but after some time you’ll never go back to Maven.
@marcoeckstein I know the switch from Maven to learning Gradle can sometimes feel rough but it’s worth it. Learning how Gradle works will likely improve your knowledge of Maven and build tools in general which is nice
I enjoyed the Kotlin hands-on for Introduction to Multiplatform. It goes through adding each step of Gradle code and explains why while creating the tutorial project. Really gives you a nice step-by-step intro and there are several other multiplatform hands-on tutorials.
If those tutorials are too much of a jump to get started with Gradle, the Gradle docs are nice. Doing a basic project created by the Gradle CLI can be helpful to learn the basics. After that, IntelliJ has support just like Maven so you can discover new features through the GUI as you update your build script.
I tried both Maven and Gradle with Kotlin scripts. I’m disagree with comments here, Maven provide a standard highly parseable and well supported configs. Gradle provide possibility to program in your build system which is makes mess. Just as confirm I see how IntelliJ IDEA struggling in parsing such scripts to provide for example highlight for dependencies that have updates.
So having Maven support - will be a big plus. I believe if you need to pre-compile something you can create plugin for it in Maven.
Still, it would be interesting to state more precisely the maven limitations in this context, and why a multiplatform build cannot be performed using dedicated maven plugins. Is it the directory structure and the lifecycle of the common sources? The calculation of the classpath? etc.