Re: modules versus SDK's

[Michael Dever]

Agreed.


On Mar 27, 2018, at 8:16 PM, Pedro Duque Vieira  
wrote:

Like Kevin says I don't think this is a one or the other choice.

I think we need to think about people who are just evaluating the platform
or learning, and whether making them also have to learn about build tools
is good.

I'd say part of the web's success is it shallow learning curve, and why
languages that are technically inferior like javascript are some times
preferred over technically superior languages.

I'd argue we should also have an installer to make the process of
evaluating/learning as easy as possible. We do need more javafx
programmers/adopters.

My 2 cents,

-- 
Pedro Duque Vieira

modules versus SDK's

[Pedro Duque Vieira]

Like Kevin says I don't think this is a one or the other choice.

I think we need to think about people who are just evaluating the platform
or learning, and whether making them also have to learn about build tools
is good.

I'd say part of the web's success is it shallow learning curve, and why
languages that are technically inferior like javascript are some times
preferred over technically superior languages.

I'd argue we should also have an installer to make the process of
evaluating/learning as easy as possible. We do need more javafx
programmers/adopters.

My 2 cents,

-- 
Pedro Duque Vieira

Re: modules versus SDK's

[Kevin Rushforth]

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
  

Re: modules versus SDK's

[Mark Raynsford]

On 2018-03-26T11:28:44 +
Mario Ivankovits  wrote:

> +1 on providing JavaFX as „simple“ dependency.
> 
> Question is how to deal with the native libraries. Provide an artifact per 
> platform?

Take a look at how LWJGL handles it:

  http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.lwjgl%22

We repack those artifacts into OSGi bundles in an automated fashion too:

  https://github.com/LWJGL/lwjgl3-osgi

-- 
Mark Raynsford | http://www.io7m.com

Re: modules versus SDK's

[Mario Ivankovits]

+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 :
> 
> 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

Re: 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
i...@michaelhoffer.de

2018-03-26 10:58 GMT+02:00 Tom Eugelink :

> 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
>>
>
>
>

Re: modules versus SDK's

[Sven Reimers]

+1 for getting it the "normal" way..

Sven

Tom Eugelink  schrieb am Mo., 26. März 2018, 10:59:

> 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
>
>
>

Re: modules versus SDK's

[Tom Eugelink]

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

modules versus SDK's

[Johan Vos]

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