Kotlin 1.3-M2: new multiplatform projects model


#26

@h0tk3y I saw you updated to 1.3.0-dev-496 in your samples

none of your examples use coroutines and trying to use the latest coroutines (0.26.0-eap13) results in “Class ‘kotlinx.coroutines.Job’ is compiled by a pre-release version of Kotlin and cannot be loaded by this version of the compiler”

Does anyone know how solve this?

(also coroutines lib doesn’t work with Gradle over 4.7 but I don’t think that causes an issue)


#27

I see two questions there :slight_smile:
First,

Does this now also mean that I can (easily, on class by class basis) have some classes have different code for android, js and jvm and some share code between android and jvm (but not js)

— yes, you can. See split-actuals example to find out how it may be done.

Second,

Is that also possible if the android variant is in reality a java library that is just designed for use on Android

— do you mean a case when the Android IDE module is actually just a module with pure Java source code without any multiplatform (actual) declarations, but with a dependency on some platform-agnostic module which is, in turn, has some actual's and is shared between several modules? :slight_smile:
Or maybe can give a real example of the structure you meant?


#28

Actually what I have (currently) is two multiplatform-jvm modules for the same conmon module one that happens to be called Android and one that happens to be called jvm. They have some different implementations and dependencies but are both regular Jar files. (btw. this is due to Android not having all classes of the jdk as well as replacement libraries (which can be provided as compileOnly)


#29

@nbransby Looks like the latest EAP version of kotlinx.coroutines is built with an earlier pre-release (1.3-M2) version of the compiler, and the 1.3.0-dev-* builds reject them. The easiest solution is to use a stable version of kotlinx.coroutines, though you can force the compiler to skip this check as well by passing -Xskip-metadata-version-check into the compiler args.

Also, the situation with kotlinx.coroutines and Gradle 4.8+ incompatibility is caused by the fact that the library’s Native parts have been published with Gradle metadata enabled, which is an experimental Gradle feature that is deliberately non-backward-compatible, according to the spec.

The same may happen with libraries built with kotlin-multiplatform and published with experimental Gradle metadata enabled: they may fail to get resolved with newer Gradle versions. Unfortunately, Gradle metadata is exactly what’s required for publishing a multiplatform library as a single Maven module, so, if a library is published with no metadata, one has to specify dependencies on its platform-specific parts (e.g. my-lib-jvm and my-lib-js) rather than a single dependency (my-lib) in case a library has Gradle metadata.

Overall, this publishing mode should be considered experimental until the Gradle metadata feature becomes stable.


#30

Thanks for that, now im having a new problem which I suspect is due to using a dev version of the plugin

e: java.lang.IllegalStateException: Backend Internal error: Exception during code generation
Cause: Back-end (JVM) Internal error: Error type encountered: [ERROR : For Result] (ErrorType).
Cause: Error type encountered: [ERROR : For Result] (ErrorType).
The root cause was thrown at: KotlinTypeMapper.java:113

I can add on you track if you it would be useful


#31

I’m trying to use kotlin-android-extensions in a MPP. There is no error but looks like it’s not available as I’m trying to use it but it can’t resolve kotlinx.android.synthetic. Do you know what could be happening?


#32

I see, thank you. Well, as far as I understood the configuration, if you specify the source set (see the definition here) targeting to Android, it requires one of the Android Gradle plugins to be applied, accompanied with all the corresponding Android-specific configurations. Also, please note that multiplatform projects, which have Android target among others, have to have a bit specific structure, with at least two build.gradle files and all the source sets placed inside of app module. To get the point, please take a look at the following examples: simple-app-with-android, android-lib-and-app-with-mpp and common-lib-and-android-app.


#33

Can you share an example project, please? Or at least its configuration. You may also do it privately if needed


#34

Do you mean that the project builds successfully, but the code in the editor is highlighted in red? Is it highlighted so even after Gradle build task being successfully executed or only after the project import and/or Gradle clean?
Does this issue look like what you experience?


#35

Sorry if this has been asked or reported before, but is it going to be possible to publish with the new plugin to maven and in turn use those artifacts from the old plugin? (In particular using from non-multiplatform projects)

For the most part this seems to work as-is, but project dependencies are not declared properly in the pom files. Specifically if I publish lib1, lib1-jvm, lib2 and lib2-jvm with lib2 depending on lib1 then lib2-jvm only depends on lib1 instead of lib1-jvm1 in the pom file. (The same is true for *-metadata and *-js artifacts as well)

In case this is just a bug I can put this on youtrack.


#36

Yes its here: https://github.com/TeamHubApp/pusher-chatkit-multiplatform


#37

looks like it’s the same issue. Thanks for the link!


#38

Thank you!

I found out the reason. Indeed, there was something about pre-release versions. To fix it, you should do the following:

  1. Update Kotlin Gradle plugin version to 1.3.0-rc-26. Note that it’s not the Kotlin 1.3-RC itself and should be considered as yet another dev version, as well as the one you’ve set in your project. It’s just more up-to-date now.
  2. Update coroutines version to 0.26.0-rc13, so it’s compatible with the plugin version.
  3. Perform the migration to the new language version: you can either agree with the migration in the dialog which appears when you’ve set the newer plugin version or do it manually, applying a quick fix on all the kotlinx.coroutines import. The thing is, as you may know, coroutines become stable in Kotlin 1.3. Therefore, those are moved to another package and that’s why you need the migration.

When all is done, build passes successfully. Please let me know if you experience any problems with that.


#39

@GitOut

The dependencies you observe in the POM are fit for the new publishing mechanism where we also publish Gradle metadata, which serves as a hint for consumers who have a lib1 dependency – it then gets resolved to an appropriate variant for each of the consumer’s targets (e.g. the lib2 JVM target gets the lib1-jvm artifacts, even though it has just the lib1 dependency).

However, when a library is published with no metadata, or the consumer did not enableFeaturePreview("GRADLE_METADATA"), this kind of dependency becomes invalid. We are going to fix that in upcoming updates.