You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The JavaFX libraries contain platform-specific native libraries.
With the JavaFX Gradle plugin 0.1.0+ applied, or also natively after openjdk/jfx#1232 is finished, the JavaFX modules have various OS and architecture dependent feature variants.
With the tactic this plugin uses, this results in the JavaFX modules not being able to be resolved as the necessary attributes are not set to pick one of the variants and thus the resolution fails and due to that no license is recognized, though it would have been available in the (parent) POM.
I did not try, but I guess with KMP project this will be quite the same situation.
I guess for a proper fix of this problem there needs to be some rewrite done. The gradle-versions-plugin for example copies the configurations it wants to check and copies over all the set attributes on that configuration, so that the dependencies are resolved like the build under investigation (or the applied plugins) configured them to do. That plugin needs to copy those configurations, as it changes the version constraints so that the latest version is resolved, so this is most probably not necessary here. I didn't look too closely why you use a detached configuration to resolve the dependency, but maybe there is some other way to do what you need, like just resolving the configuration in question, or using an artifact view, or similar.
The text was updated successfully, but these errors were encountered:
The JavaFX libraries contain platform-specific native libraries.
With the JavaFX Gradle plugin 0.1.0+ applied, or also natively after openjdk/jfx#1232 is finished, the JavaFX modules have various OS and architecture dependent feature variants.
With the tactic this plugin uses, this results in the JavaFX modules not being able to be resolved as the necessary attributes are not set to pick one of the variants and thus the resolution fails and due to that no license is recognized, though it would have been available in the (parent) POM.
I did not try, but I guess with KMP project this will be quite the same situation.
I guess for a proper fix of this problem there needs to be some rewrite done. The gradle-versions-plugin for example copies the configurations it wants to check and copies over all the set attributes on that configuration, so that the dependencies are resolved like the build under investigation (or the applied plugins) configured them to do. That plugin needs to copy those configurations, as it changes the version constraints so that the latest version is resolved, so this is most probably not necessary here. I didn't look too closely why you use a detached configuration to resolve the dependency, but maybe there is some other way to do what you need, like just resolving the configuration in question, or using an artifact view, or similar.
The text was updated successfully, but these errors were encountered: