Kotlin MPP support.
DaRacci opened this issue · comments
I've taken the recent dive into trying to add kotlin MPP support and i have somewhat succeeded here, and was basically wondering if this would be wanted to make a PR into this repo instead.
Most new classes i made are copies of the present classes but with a KotlinTarget replacing project and just propagating that throughout.
I am a bit confused what I am looking at here.
like, what does paperweight, or paper for that matter, have to do with mpp? we target the jvm and only that.
can you describe more of what you are trying to do and what you aim to accomplish with that?
So basically the way im setting up my plugin library atm is to separate things like api, and core aswell as share code and using the expect, actual system instead of a bunch of abstract classes with Impl classes, which in turn is a in my opinion a cleaner workflow despite it being harder to setup and with less support from gradle plugins and the like, My changes should also allow the ability to have specific MPP source sets that target different NMS versions and so on, so you can use the expect, actual declarations with them.
I am not sure if we are open to inviting any complexity for support such non traditional setups. Paperweight is only really meant to be used as one, top level gradle plugin for a paper plugin project. The supported and recommended workflow would be to properly separate your projects instead of using modules (the feeling will be basically the same in any modern IDE as it will interpret dependencies as local modules)
But I'll leave this open for others to share their opinion.
That makes sense, I may eventually have to move to that if theres too many issues but i want to try with the MPP approach for now, Ill continue to support my modified MPP version of paperweight at the same time incase there ever is interest in adding official support
There doesn't seem to be much benefit in applying kotlin multiplatform to paperweight, and as said it'd mostly just result in increased complexity. You're free to continue this on your own, but it's not something we'd like in the main project.