Ultimately, I think you are right that a standalone JavaFX needs to be
discoverable and usable via a dependency manager like gradle or maven.
From the discussion, it seems most others agree.
I note that this doesn't preclude also making a zip bundle available for
developers who want to download and unzip JavaFX to compile or run
against (i.e., I don't think it is an "either-or" choice). It probably
means that it isn't worth spending much time on installers, etc -- just
a zip bundle with the bits is probably good enough for the SDK.
-- Kevin
Johan Vos wrote:
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
