Hit again by: `The 'java' plugin has been applied,...

# multiplatform

[darkmoon_uk]

Hit again by:
The 'java' plugin has been applied, but it is not compatible with the Android plugins.
...while trying to make an Multiplatform library with an Android and JavaFX target. The OpenJfx plugin putting a dependency on the Java application plugin is causing it, in this file:
https://github.com/openjfx/javafx-gradle-plugin/blob/master/src/main/java/org/openjfx/gradle/tasks/ExecTask.java

This means it is not a trivial fix 😕
The crux of the issue is the way the Android Plugin refuses to execute in the presence of the java plugin; I can see two routes to go here:
1) Make a PR vs the OpenJfx project to make the plugin it adheres to for execution more configurable.
2) Deal with the Android Plugin head on - while this seems like the more daunting task, as there may be deeper issues, @abreslav left a curious comment against a similar issue report, here:

https://discuss.kotlinlang.org/t/kotlin-android-gradle/789

"Since Andriod's Gradle is rather peculiar, we have to essentially build a separate Gradle plugin for Kotlin on Android. We are working on it, you can contribute if you feel like it."

...which suggests JB may have considered this back in '13, but the exclusion problem persists.

[louiscad]

Can you make a jvm only library with OpenJfx, then consume it from an android library or application module?

[darkmoon_uk]

I could do, but since my goal here is to make a multi-platform library neatly supporting Android and JavaFx, this approach would make puppies sad.

[darkmoon_uk]

The offending check from the Android side (although it may be valid and with good reason) is in: android-platform-tools-base/build-system/gradle/src/main/groovy/com/android/build/gradle/BasePlugin.groovy

[darkmoon_uk]

The smaller hill to climb is the OpenJfx plugin; I'll work with that and see if it can be made configurable in a way that cooperates with K/MP.

[louiscad]

You could have your library targeting Android and other Kotlin targets depend on the one with jvm target

[darkmoon_uk]

Appreciate the suggestion @louiscad but that still sounds like two libraries which I'd like to avoid (I have multiple modules to define like this so the maintenance would multiply). Trying to modify the OpenJfx plugin to meet the issue somewhat head-on. OpenJfx seems to only need the application plugin so it can emplace itself as a dependency of the run task, ensuring it gets to perform module configuration before any App compile. It should be possible to implement so that it has an affinity with 'Kotlin first' (✨), before attempting to load the Java plugin.

[abreslav]

CC @h0tk3y @snrostov

[gildor]

Own Android plugin is really bad idea
Imo just should be JVM module which doesn't related on application or Android and used by both

[darkmoon_uk]

Agree @gildor; forking Android plugin would end up a nightmare and there are probably good reasons it excludes java. Practical solution for my project right now is just to do manually what the OpenJfx plugin tries to provide as a convenience: which is just to set up the right Java Modules.

[darkmoon_uk]

I think there is also an opportunity to provide an 'improvement' for OpenJfx plugin so that it has a closer affinity with kotlin-multiplatform plugin, falling back to the default application plugin where multiplatform isn't present.

[gildor]

there are probably good reasons it excludes java

There is, java plugin used to build Jars, Android build and packaging process is completely different

falling back to the default application plugin where multiplatform isn’t present

I believe plugin just shouldn’t apply application automatically, instead configure own run task if application plugin is applied to the project

[h0tk3y]

We've started cooperation with the Android Gradle plugin maintainers about this incompatibility some time ago. Hypothetically, the Android plugin could co-exist with the Java plugin in multiplatform projects, as the AGP doesn't really use much of the Java infrastructure. However, this requires some work to be done on the Android plugin side. The issue is tracked in the Kotlin YouTrack: https://youtrack.jetbrains.com/issue/KT-30878, and in the Google Issue Tracker: https://issuetracker.google.com/issues/132576775

@darkmoon_uk Thanks for sharing this use case! I see that a workaround for now would require creating the exec task by hand, but this part of the plugin's code is only triggered when the application plugin is applied. Perhaps a third-party plugin could replace this logic by creating this task in a similar way using the Kotlin/JVM target. This logic could then be contributed to OpenJfx.