modules versus SDK's

[Michael Hoffer]

Hi Johan, hi all,

in my opinion SDKs are tolerable for providing the fundamental layers of
infrastructure. But other dependencies should be lightweight and use the
default channels for providing dependencies. There should be no difference
between consuming JavaFX and let's say CommonsIO as dependencies.

I think Qt is a good example why SDKs are not the ideal solution. While on
Linux Qt is provided as a set of packages (e.g. rpm and deb) it is common
to download the SDK on Windows and macOS. From my experience with students
this sets an unnecessarily high barrier. If you don't know the technology
so well most people download all sub-components just to get rid of any
dependency problems. This leads to huge junks of unnecessary dependencies
in the GB range. SDKs are easy to install if the come as a monolithic
package but usually don't integrate well with well-established ways of
providing and consuming dependencies.

I think a Wiki page reads much nicer if it recommends to add simply add a
dependency like

    compile: 'javafx:javax.graphics:11.0.0'

instead of explaining where to download the SDK, setting JAVAFX_HOME etc.

Regards,
Michael


--
Dr. Michael Hoffer

Twitter: @mihosoft
Webpage: www.mihosoft.eu

Goethe-Zentrum für Wissenschaftliches Rechnen (G-CSC)
Goethe-Universität
Kettenhofweg 139
60325 Frankfurt am Main
phone: +49 69 798 25254
info at michaelhoffer.de

2018-03-26 10:58 GMT+02:00 Tom Eugelink <tbee at tbee.org>:

> I totally assumed that, when JavaFX is separated out, it will distributed
> as an artifact on Maven central (or similar) so it can be included like a
> dependency. Feels like a no brainer?
>
>
>
> On 26-3-2018 10:50, 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
>>
>
>
>