+1 on providing JavaFX as „simple“ dependency.
Question is how to deal with the native libraries. Provide an artifact per
platform?
compile: 'javafx:javax.graphics-osx:11.0.0'
compile: 'javafx:javax.graphics-win:11.0.0'
compile: 'javafx:javax.graphics-pi:11.0.0‘
These bundles might just contain the native libraries and each of them depend
on e.g.
compile: 'javafx:javax.graphics:11.0.0‘
which contains just the JavaFX Java sources.
That way one can build a cross-platfrom bundle with all native libraries or a
slim bundle for a specific target.
Best regards,
Mario
> Am 26.03.2018 um 10:50 schrieb Johan Vos <johan....@gluonhq.com>:
>
> Hi,
>
> I want to start a discussion on distributing JavaFX as an SDK versus
> distributing its modules via the traditional build and distribution
> mechanisms.
>
> Personally, I think relying on an SDK is too much a barrier. It requires
> users to manually download software from the exact right place, and
> "install" it on the exact right target. If a version changes, you have to
> manage that manually.
>
> That is how JavaFX was distributed before it was bundled with the JDK, so
> it makes sense to provide that option (although me and others will probably
> never use that).
>
> Today however, when a developer has a dependency on a library or framework
> (including property files and native code), he uses his build tools (e.g.
> maven/gradle) to manage the download/install//update of those
> libaries/frameworks.
> If you rely on Spring, Apache Commons, slf4j,... you don't download those
> SDK's but you point to the group-name-version triplet in your pom.xml or
> build.gradle file. I don't see why JavaFX would be different here.
>
> When someone is new to JavaFX, or is considering JavaFX, I think chances on
> success will be much bigger if that person simply needs to add e.g.
> dependencies {
> compile: 'javafx:javax.graphics:11.0.0'
> }
> to his build.gradle and then rely on gradle (or maven) and jcenter/sonatype
> to make sure the correct version with all its dependencies are installed
> (in a maven/gradle local cache)
>
> - Johan
