JavaFX plugin implicitly puts all code on the module path instead of the classpath about javafx-gradle-plugin

[tiainen]

This is something that grew historically when trying to make life easier for gradle projects that depend on JavaFX. The JavaFX components must be detected as modules by the java runtime and therefor the jars must be defined on the module path. That's why, at first (before the existence of this plugin), we used the gradle modules plugin. We've provided changes to that plugin to make it work together with non-modular projects as well (see java9-modularity/gradle-modules-plugin#24).

Currently, the gradle modules plugin will indeed put all runtime dependencies on the module path, which might cause split package issues, because not all dependencies are safe to be used in a modular environment.

The best solution seems to me, that we get rid of the changes for "non-modular" support in the gradle modules plugin. I don't think we should even fix the module-path/classpath issue because, in retrospect, it just makes sense that the gradle modules plugin does it's work only in the case where a modular project is detected.
The second change is then to be done in the gradle javafx plugin. In case it detects that it is applied to a non-modular project, only the javafx artifacts should be added to the module path. All other dependencies should stay on the classpath.

[tiainen]

See the following issue in the gradle modules plugin: java9-modularity/gradle-modules-plugin#47

[xeruf]

The gradle modules plugin has been updated, but I still see classpath conflict issues when using this plugin. I guess you have to release a new version?