What's the correct plugin to use in an Android module that uses other multiplatform modules ? <https...

# multiplatform

[mbonnin]

What's the correct plugin to use in an Android module that uses other multiplatform modules ? https://github.com/Kotlin/mpp-example/blob/master/androidApp/build.gradle#L3 has org.jetbrains.kotlin.multiplatform and https://github.com/chris-hatton/kotlin-multiplatform-template/blob/master/Code/Client/Android/mobile/build.gradle.kts#L17 has kotlin-android

[mbonnin]

Asking because I have a hard time having intelliJ picking up the multiplatform dependencies in my android app module (compilation works fine)

[Dominaezzz]

Ha, was doing this yesterday. If you need to use both, use the multiplatform one.

[mbonnin]

Does auto-complete work for you ? Some modules I can Ctrl-click into, other just stay red forever no matter how many times I gradle sync...

[Dominaezzz]

It does.

[Dominaezzz]

Try re-importing the project.

[mbonnin]

Yes, I've done that a few times... Right now I'm trying https://github.com/chris-hatton/kotlin-multiplatform-template but still got everything red (it's actually worse as intelliJ doesn't even pick up the androidx libs...) What intelliJ are you using ? (I'm using 2019.1 community)

[Dominaezzz]

Same but Ultimate.

[Dominaezzz]

Is all of the source red or just some?

[mbonnin]

[Dominaezzz]

Ah, off course.

[Dominaezzz]

Had the same issue.

[Dominaezzz]

Show me your gradle sync output.

[Dominaezzz]

It's the dependency resolution issue you're talking about.

[mbonnin]

Is that the sync output ? https://gist.github.com/martinbonnin/98ec2315474401e864ff1abad6d99ccc

[mbonnin]

That doesn't mention much...

[mbonnin]

[mbonnin]

multiplatform projects are resolved by the IDE but Ctrl-click opens the decompiled class (and not the commonMain source file I would expect)

[Dominaezzz]

Have you added jcentre() to your repositories block?

[mbonnin]

It happens to be there (https://github.com/chris-hatton/kotlin-multiplatform-template/blob/96b78ed2237c7052c34b3ffe00ed3b573954732c/Code/Client/Android/build.gradle.kts#L33). But this is litteraly a clean checkout from the template project so I would expect it to work out of the box

[mbonnin]

Unless @darkmoon_uk does'nt have autocomplete either ?

[Sergioedcigreja]

have you modified the sdk.dir on local.properties?

[mbonnin]

yep, I have actually created local.properties, it wouldn't compile else

[Dominaezzz]

Compiles? So you can run the project via the IDE?

[mbonnin]

Yep

[mbonnin]

Everything compiles fine, it's just the IDE auto-complete that's messed up

[Dominaezzz]

I don't see the androidx dependencies.

[Dominaezzz]

Nvm, found them

[Dominaezzz]

In the gradle window, try clicking the Refresh dependencies button.

[mbonnin]

I have a "Refresh all Gradle project, is this it ?"

[Dominaezzz]

No, there's another one.

[mbonnin]

ah

[mbonnin]

[mbonnin]

Can't find it...

[Dominaezzz]

Right-click

[mbonnin]

Yay, thanks !

[mbonnin]

What does that do ? re-download dependencies ?

[louiscad]

It seems there's a problem with a dependency (according to the red underline). Trying to build from command line should show the problem with dependency resolution if there's one.

[Dominaezzz]

Hmm, I'm not completely sure but it usually forces IntelliJ to reindex stuff an the end.

[mbonnin]

So now I have androix resolved but client-common is all red now (it used to link to the decompiled class file)

[mbonnin]

[mbonnin]

@louiscad building is perfectly fine, it's just the IDE features not recognizing all the dependencies

[louiscad]

@mbonnin Are the red classes from an android or a jvm target, or from a non Kotlin multiplatform module (and if so, android or jvm?)

[mbonnin]

I believe they are from a commonMain sourceSet that is included as a jvm() artifact (does that make sense ?)

[mbonnin]

FirstPresenterContract usages for an example are all red until I build and gradle sync. Then usages are not red anymore but Ctrl-click opens the .jar and not the source file.

https://github.com/chris-hatton/kotlin-multiplatform-template/blob/121ef4fa3129d506245e4f5ca9b0ceb29e02f773/Code/Client/Common/src/commonMain/kotlin/org/chrishatton/example/ui/contract/FirstPresenterContract.kt#L4-L3

[Dominaezzz]

Hmm, it's frustrating that the project builds. Is client-common itself red?

[mbonnin]

Now that I built, red has disappeared but IDE features like Ctrl-click still don't work. The IDE looks up the symbols inside the jar and isn't able to understand that they actually come from a source module

[mbonnin]

[mbonnin]

Maybe I'll just try a free trial of the ultimate edition, never know...

[louiscad]

Android Studio has a decompiler too, but that doesn't work well for non java sources, especially when you start using features like coroutines and things that Java can't express

[louiscad]

Android Studio uses parts of Ultimate features, plus parts of CLion, which is paid by us through Google if I understood the business model well

[mbonnin]

The thing is I don't care about the decompiler, I just want Android Studio, intelliJ, idea, ... to recognize that these source are in my project in an included module

[louiscad]

But that won't solve your issue. I think you should report the issue on kotl.in/issue, ideally with a reproducing project. This should just work, that's the developer UX we aim for

[mbonnin]

But if it works for everyone else, it's going to be though to reproduce...

[louiscad]

It doesn't always work well for me when I mix jvm and android targets. I reported an issue a while ago with different symptoms, but it got crowded as there was regressions then partial fixes. A fresh one with a narrow scope will always help. In my company's project, I use only android targets for now because of these kind of issues. I planned to try 1.3.50 EAPs on a personal project after I make a release with 1.3.40 soon, so I can see what improved and open new issues for the remaining issues I encounter.

I'm also rounding the corners of a project template that bundles modules templates to generate modularized bug reproducers by reproducing the modules w/ targets and dependency graph, and generate other projects more quickly.

I didn't encounter the behavior you describe, so I still strongly encourage you to report it. If you want me to help generate a reproducing project, feel free to reach me here or by DM, my modules templates + (Kotlin) script already work well, I finished settings.gradle.kts auto-editing last nigh.

[mbonnin]

Ah, thanks for the jvm vs android thing, that might help. In this case, the reproducer is quite easy thanks to Chris: https://github.com/chris-hatton/kotlin-multiplatform-template

[mbonnin]

BTW, same thing with ultimate edition

[mbonnin]

https://youtrack.jetbrains.com/issue/KT-32814?project=kt

[louiscad]

Perfect! Voted for it

[mbonnin]

I ended up targetting android for all the modules and now everything's working fine. Here's the commit if you're curious: https://github.com/HearthSim/Arcane-Tracker/commit/2d652d678bdfd26e8eca779f9fd697e178c18ff6. It's a bit tedious to have to maintain all these AndroidManifest, etc...

[darkmoon_uk]

Upvoted as this affects the template; thanks for raising the issue @mbonnin!

[louiscad]

Note that you can use stdlib-jdk7 on Android. Maybe even stdlib-jdk8 since D8 in AGP 3.4+? Can you confirm @jw Also, do you know if it automatically raises the Kotlin jvmTarget to 8, and if you need to set compileOptions for AGP for it to work properly?

[jw]

It has nothing to do with desugaring. It's more about types and APIs which you're already protected against by lint. Every Android dev should be using jdk8 stdlib and it's orthogonal to bytecode level (although I suspect the jdk8 one might target 8 which will force it on you)

[mbonnin]

What do I get by using stdlib-jdk8 instead of the plain stdlib ?

[jw]

Not much. You won't use anything from it. 7 is where the suppressed exception support lives which you want. But you might as well use 8

[darkmoon_uk]

@mbonnin On the subject of my usage of the kotlin-android plugin instead of the kotlin-multiplatform plugin at the top-level; this was a considered choice. Considerations being:
• Firstly, I would expect either kotlin-android or kotlin-multiplatform (with Android target) to ultimately work.
• While there seems to be a perception that the multi-platform plugin is 'recommended'; I wasn't able to find any suggestion that the platform-specific plugins are deprecated in any way - they still have their place and are valid for use.
• Creating an all-in-one multiplatform client project for the clients I wanted to support is currently problematic for the multiplatform plugin. Specifically: to include a JavaFX Desktop client would mean the android and java plugins both need to be instated, but they are currently mutually exclusive in the same Gradle file.
• Anyway, the amount of configuration I have (or may want to expand to) would become too cluttered and disorganised in a single file. I feel that multiplatform driven projects are better suited to libraries and do not cater well to top-level application projects where there is a lot of extra configuration going on.
• In summary: the Android client project in my template should be only ever target the Android platform - so kotlin-android is the best fit
• Finally: My supporting library projects are kotlin-multiplatform - as the best fit for them

[mbonnin]

Makes sense, thanks !

[darkmoon_uk]

Added a follow up the issue of IntelliJ breaking when jvm/android targets are mixed, at:
https://youtrack.jetbrains.com/issue/KT-32814

[darkmoon_uk]

Looks related to (maybe even a duplicate of) https://youtrack.jetbrains.com/issue/KT-30510
...which comment says should be fixed in AS 3.6 Canary 6.