Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restructure the project for multiplatform Kotlin #304

Open
1 of 2 tasks
Egorand opened this issue Dec 15, 2017 · 7 comments
Open
1 of 2 tasks

Restructure the project for multiplatform Kotlin #304

Egorand opened this issue Dec 15, 2017 · 7 comments
Milestone

Comments

@Egorand
Copy link
Collaborator

Egorand commented Dec 15, 2017

  • Switch to Gradle (Maven not supported yet)
  • Create a common module and a platform module for JVM
@Egorand
Copy link
Collaborator Author

Egorand commented Dec 17, 2017

I'm preparing a POC, want to implement a few more use cases and will push. Looks like we'll have to give up on truth for assertions to move tests to the common module...

@tamimattafi
Copy link

Are there any updates on this issue? Can we use the generated code in our KMM project?

@Egorand
Copy link
Collaborator Author

Egorand commented Feb 15, 2022

Yes, generated code is platform-agnostic by default. This issue was about making KotlinPoet itself multiplatform.

@krzema12
Copy link

krzema12 commented Apr 7, 2023

What's the status of this request?

I have an use case where I'd like to host my tool using KotlinPoet somewhere. JVM hosting, well, costs money, and I thought of using Kotlin/JS. KotlinPoet is one of the problematic dependencies because it's JVM-only.

If the topic is well explored, I'd be grateful for a rough list of items to address to make this library multiplatform. I may have a chance to contribute.

@thagikura
Copy link

+1 to krzema12 if there is a rough list of remaining tasks, I'd like to see if I can contribute, too. @Egorand

@JakeWharton
Copy link
Collaborator

The biggest inhibitor to this is the lack of default implementations in expect classes. Because of the API design mixing common things with JVM-specific things, it's a gigantic pain in the ass to maintain effectively four copies of the API: the expect, the JVM actual facade, the non-JVM actual facade, and the real common implementations. It's not impossible to do this change without implementations inside expects, but it's certainly annoying.

@takahirom
Copy link
Contributor

I've made an attempt to address the issue of restructuring the project for multiplatform Kotlin. I have transitioned to using the Multiplatform plugin along with JVM configuration.

Please have a look at the changes. If you find them unnecessary or not aligned with your plans for the project, feel free to close this.
#1654

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants