Support MPP with multiple JVM targets about binary-compatibility-validator

[Him188]

Is there any workaround for this at this moment?

No, I think.

[JavierSegoviaCordoba]

@qwwdfsad I generated the tasks with the approach mentioned in the OP, but there should be a general apiBuild, apiCheck and apiDump which depends on all respective targetApiBuild (etc).

Maybe I can try to finish this fix tomorrow. Do you think this approach should be used? I could create a PR with it.

[JavierSegoviaCordoba]

My problem is with a KMP library that has jvm + Android as targets. 0.2.4 hasn't this problem so it was introduced in 0.3.0

[JavierSegoviaCordoba]

Is there any workaround for this at this moment?

[JavierSegoviaCordoba]

I am doing something wrong, I tried in my multiplatform library and it works, but tests fail :(

[qwwdfsad]

Since 0.2.4 we've added support for a single Android target and then the plugin stopped to work for multiple JVM targets in a single multiplatform project.

I'm prototyping the solution and would like to receive feedback on the following behaviour:

For JVM-only and multiplatform project with a single JVM target, everything stays the same.
Now consider a multiplatform project with the following structure:

commonMain
    \ MyClass.kt
jvmMain
    \ JvmClass.kt
anotherJvmMain
    \ AnotherJvmClass.kt

For now, when the plugin is applied and :apiDump is executed, the following structure will be produced:

api
    \ jvm
        \ project-name-jvm.api // <- contains dump of MyClass and JvmClass
    \ anotherJvm
        \ project-name-anotherJvm.api // <- contains dump of MyClass and AnotherJvmClass
commonMain 
 ... here everything stays the same...

[twyatt]

For JVM-only and multiplatform project with a single JVM target, everything stays the same.

At first this sounds appealing (previous commits of .api files will play nice with new versions of binary-compatibility-validator) but then consider the situation of adding/removing JVM targets to an existing project.

With the Gradle plugins for kotlin("multiplatform") and the other kotlin("*") plugins, they all play really nice with each other. Swapping between them is as simple as reconfiguring sourceSets (for the most part).

If the behavior (output directory structure) of binary-compatibility-validator is dependent on the number of JVM targets, then changing a project from (for example) kotlin("jvm") to kotlin("multiplatform") (with a jvm and android target), then suddenly the previous jvm target .api files will be generated in a new location (due to an additional JVM target being added).

I personally would prefer the structure always be consistent (whether 1 JVM target or many) — so always something like the last structure you described in your previous #38 (comment).

Unfortunately this will be rather jarring for users of previous versions of binary-compatibility-validator who upgrade, but it will be a one time change, rather than repeated changes anytime the number of JVM targets fluctuates between 1 or many.

Perhaps an option could be provided that enables/disables the previous (1 JVM target) behavior/structure, allowing developers to opt in (or out) of the new structure (and support for multiple JVM targets)?

[pdvrieze]

I'm prototyping the solution and would like to receive feedback on the following behaviour:

The described behaviour looks fine to me. The names can use the existing algorithms for target specific names, and might special case the default names to allow for backwards compatibility without depending on target counts.

[qwwdfsad]

Fixed in 0.8.0-RC.