Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

Seems a reasonable addition to me, too.

-- Kevin


Michael Ennen wrote:

Sounds like a reasonable idea to me.

On Mon, Mar 26, 2018 at 1:00 PM, Nir Lisker  wrote:

  

I'm thinking about the addition of a public method for mouse click, which
is mouse press and then mouse release - the parallel for key typed. Is it
worth?

- Nir

On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:



Seems good to me, too.

-- Kevin


Michael Ennen wrote:

  

Sounds like a good idea to me to only have `getScreenCapture` methods
that have a WritableImage parameter which can be `null` which means a
new WritableImage will be created otherwise the given one is re-used, as
in Scene.snapshot and Node.snapshot. What are your thoughts on this,
Kevin?

On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer > wrote:



On Mar 23, 2018, at 5:50 PM, Michael Ennen > wrote:

Kevin,

I believe I followed all of your suggestions, except the one with a
re-usable WritableImage.
If you want me to implement that as well, I can, but you seemed
unsure
about the necessity
of it.

  

I think it should be included to reduce garbage generated in a
case where repeated captures is used.  Such as a desktop sharing
application, a screen recorder, etc.
It would also be consistent with the node.snapshot API.

In fact, I would just have the version that takes a WriteableImage
and match the behaviour of node.snapshot.

Scott




--
Michael Ennen





  

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Sounds like a reasonable idea to me.

On Mon, Mar 26, 2018 at 1:00 PM, Nir Lisker  wrote:

> I'm thinking about the addition of a public method for mouse click, which
> is mouse press and then mouse release - the parallel for key typed. Is it
> worth?
>
> - Nir
>
> On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Seems good to me, too.
>>
>> -- Kevin
>>
>>
>> Michael Ennen wrote:
>>
>>> Sounds like a good idea to me to only have `getScreenCapture` methods
>>> that have a WritableImage parameter which can be `null` which means a
>>> new WritableImage will be created otherwise the given one is re-used, as
>>> in Scene.snapshot and Node.snapshot. What are your thoughts on this,
>>> Kevin?
>>>
>>> On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer >> > wrote:
>>>
>>>
>>>
>>> On Mar 23, 2018, at 5:50 PM, Michael Ennen > wrote:

 Kevin,

 I believe I followed all of your suggestions, except the one with a
 re-usable WritableImage.
 If you want me to implement that as well, I can, but you seemed
 unsure
 about the necessity
 of it.

>>>
>>> I think it should be included to reduce garbage generated in a
>>> case where repeated captures is used.  Such as a desktop sharing
>>> application, a screen recorder, etc.
>>> It would also be consistent with the node.snapshot API.
>>>
>>> In fact, I would just have the version that takes a WriteableImage
>>> and match the behaviour of node.snapshot.
>>>
>>> Scott
>>>
>>>
>>>
>>>
>>> --
>>> Michael Ennen
>>>
>>
>


-- 
Michael Ennen

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: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

[Kevin Rushforth]

This looks fine to me now.

-- Kevin


Ajit Ghaisas wrote:

Thanks all for the review.

I have addressed the review comments in - 
http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/

The changes are -
1. Addressed the (c) year inaccuracies in files -
modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java
modules/javafx.graphics/src/main/java/javafx/scene/Scene.java

2. Removed tabs from 
modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java
3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class.

Also, I have created a new bug JDK-8200236 to address some of the valid 
suggestions from Mandy and Daniel.

Request you to review the new webrev.

Regards,
Ajit

-Original Message-
From: Kevin Rushforth 
Sent: Saturday, March 24, 2018 3:27 AM

To: Ajit Ghaisas
Cc: Mandy Chung; Daniel Fuchs; openjfx-dev@openjdk.java.net
Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of 
platform logger in javafx modules

The only additional comments I have are couple typos and a white-space
issue:

1. There is a typo in the Copyright year (201 rather than 2018) in the 
following two files:

modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java
modules/javafx.graphics/src/main/java/javafx/scene/Scene.java


2. There are tab characters in the following file that need to be changed to 
spaces:

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java
 public static void setUpClass() {
 >>>System.err.println("SelectBindingTest : log messages are 
expected from these tests.");



All my testing looks good. With this patch I am now able to run applications 
with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command 
line (as long as it doesn't use Swing interop).

-- Kevin


Ajit Ghaisas wrote:
  

Hi Kevin, Mandy and Daniel,

Please review the changeset that removes dependency on sun.util.logging 
package from JavaFX code.

Bug :  https://bugs.openjdk.java.net/browse/JDK-8195799
Fix :  http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/

Request you to review.

Regards,
Ajit
  

Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

[Kevin Rushforth]

It doesn't seem harmful to keep the current implementation. This seems 
better to leave for the follow-on JBS issue (JDK-8200236) unless there 
something I am missing.


-- Kevin


mandy chung wrote:

You don't need the loggers map and getLogger method can simply return
 return new PlatformLogger(System.getLogger(name));

Other than this, looks fine.

Mandy


On 3/26/18 4:36 AM, Ajit Ghaisas wrote:

Thanks all for the review.

I have addressed the review comments in - 
http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/

The changes are -
1. Addressed the (c) year inaccuracies in files -
modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java
modules/javafx.graphics/src/main/java/javafx/scene/Scene.java

2. Removed tabs from 
modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java
3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class.

Also, I have created a new bug JDK-8200236 to address some of the valid 
suggestions from Mandy and Daniel.

Request you to review the new webrev.

Regards,
Ajit

-Original Message-
From: Kevin Rushforth 
Sent: Saturday, March 24, 2018 3:27 AM

To: Ajit Ghaisas
Cc: Mandy Chung; Daniel Fuchs; openjfx-dev@openjdk.java.net
Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of 
platform logger in javafx modules

The only additional comments I have are couple typos and a white-space
issue:

1. There is a typo in the Copyright year (201 rather than 2018) in the 
following two files:

modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java
modules/javafx.graphics/src/main/java/javafx/scene/Scene.java


2. There are tab characters in the following file that need to be changed to 
spaces:

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java
 public static void setUpClass() {
 >>>System.err.println("SelectBindingTest : log messages are 
expected from these tests.");



All my testing looks good. With this patch I am now able to run applications 
with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command 
line (as long as it doesn't use Swing interop).

-- Kevin


Ajit Ghaisas wrote:


Hi Kevin, Mandy and Daniel,

Please review the changeset that removes dependency on sun.util.logging 
package from JavaFX code.

Bug :  https://bugs.openjdk.java.net/browse/JDK-8195799
Fix :  http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/

Request you to review.

Regards,
Ajit
  
  

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Nir Lisker]

I'm thinking about the addition of a public method for mouse click, which
is mouse press and then mouse release - the parallel for key typed. Is it
worth?

- Nir

On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth  wrote:

> Seems good to me, too.
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
>> Sounds like a good idea to me to only have `getScreenCapture` methods
>> that have a WritableImage parameter which can be `null` which means a
>> new WritableImage will be created otherwise the given one is re-used, as
>> in Scene.snapshot and Node.snapshot. What are your thoughts on this,
>> Kevin?
>>
>> On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer > > wrote:
>>
>>
>>
>> On Mar 23, 2018, at 5:50 PM, Michael Ennen >> > wrote:
>>>
>>> Kevin,
>>>
>>> I believe I followed all of your suggestions, except the one with a
>>> re-usable WritableImage.
>>> If you want me to implement that as well, I can, but you seemed
>>> unsure
>>> about the necessity
>>> of it.
>>>
>>
>> I think it should be included to reduce garbage generated in a
>> case where repeated captures is used.  Such as a desktop sharing
>> application, a screen recorder, etc.
>> It would also be consistent with the node.snapshot API.
>>
>> In fact, I would just have the version that takes a WriteableImage
>> and match the behaviour of node.snapshot.
>>
>> Scott
>>
>>
>>
>>
>> --
>> Michael Ennen
>>
>

Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

[mandy chung]

You don't need the loggers map and getLogger method can simply return
 return new PlatformLogger(System.getLogger(name));

Other than this, looks fine.

Mandy


On 3/26/18 4:36 AM, Ajit Ghaisas wrote:

Thanks all for the review.

I have addressed the review comments in - 
http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/

The changes are -
1. Addressed the (c) year inaccuracies in files -
modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java
modules/javafx.graphics/src/main/java/javafx/scene/Scene.java

2. Removed tabs from 
modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java
3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class.

Also, I have created a new bug JDK-8200236 to address some of the valid 
suggestions from Mandy and Daniel.

Request you to review the new webrev.

Regards,
Ajit

-Original Message-
From: Kevin Rushforth
Sent: Saturday, March 24, 2018 3:27 AM
To: Ajit Ghaisas
Cc: Mandy Chung; Daniel Fuchs; openjfx-dev@openjdk.java.net
Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of 
platform logger in javafx modules

The only additional comments I have are couple typos and a white-space
issue:

1. There is a typo in the Copyright year (201 rather than 2018) in the 
following two files:

modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java
modules/javafx.graphics/src/main/java/javafx/scene/Scene.java


2. There are tab characters in the following file that need to be changed to 
spaces:

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java
  public static void setUpClass() {
  >>>System.err.println("SelectBindingTest : log messages are
expected from these tests.");


All my testing looks good. With this patch I am now able to run applications 
with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command 
line (as long as it doesn't use Swing interop).

-- Kevin


Ajit Ghaisas wrote:

Hi Kevin, Mandy and Daniel,

 Please review the changeset that removes dependency on sun.util.logging 
package from JavaFX code.

 Bug :  https://bugs.openjdk.java.net/browse/JDK-8195799
 Fix :  http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/

 Request you to review.

Regards,
Ajit
   

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

Seems good to me, too.

-- Kevin


Michael Ennen wrote:

Sounds like a good idea to me to only have `getScreenCapture` methods
that have a WritableImage parameter which can be `null` which means a
new WritableImage will be created otherwise the given one is re-used, as
in Scene.snapshot and Node.snapshot. What are your thoughts on this,
Kevin?

On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer > wrote:





On Mar 23, 2018, at 5:50 PM, Michael Ennen > wrote:

Kevin,

I believe I followed all of your suggestions, except the one with a
re-usable WritableImage.
If you want me to implement that as well, I can, but you seemed
unsure
about the necessity
of it.


I think it should be included to reduce garbage generated in a
case where repeated captures is used.  Such as a desktop sharing
application, a screen recorder, etc.
It would also be consistent with the node.snapshot API.

In fact, I would just have the version that takes a WriteableImage
and match the behaviour of node.snapshot.

Scott




--
Michael Ennen

Re: OpenJFX GitHub mirror

[Johan Vos]

Hi Nir,

About 4. (jfx-dev): you're right, I just removed that repository. That was
just some testing before we did the real thing.

As for the other points: I agree

- Johan

On Mon, Mar 26, 2018 at 12:03 PM Nir Lisker  wrote:

> Hi All,
>
> A few comments about the mirror and JBS:
>
> 1. In PRs and issues on GitHub, I strongly suggest that the link to JBS be
> included in the top comment. If the JBS issue was created after a
> discussion, edit it in.
>
> 2. In JBS, I suggest to link to the GitHub mirror via More > Link > Web
> Link and in the Link Text use something like "GitHub mirror" (open for
> suggestions). JIRA renders the link in an easy to see way (easier than
> looking at URLs). Iv'e tried it in a couple of issues, e.g.,
> https://bugs.openjdk.java.net/browse/JDK-8198795 and it seems preferable
> to
> me.
>
> 3. In JBS, I suggest a new label will be used for issues which are linked
> to GitHub for search purposes. This is similar to the webbug label.
>
> If these are agreeable, please add them to the contribution instructions.
>
> 4. What is https://github.com/javafxports/jfx-dev? Newcomers can confuse
> it
> with javafxports/openjdk-jfx.
>
> 5. When the mirror is fully ready and operational, we should advertise on
> community pages (like Reddit) to gather up contributors. Please keep a
> mental reminder when the time comes.
>
> Thanks to all who are working on this.
>
> - Nir
>

Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

[Daniel Fuchs]

Hi Ajit,

Looks good to me. I obviously didn't review the
build changes.

best regards,

-- daniel

On 26/03/2018 12:36, Ajit Ghaisas wrote:

Thanks all for the review.

I have addressed the review comments in 
-http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/

The changes are -
1. Addressed the (c) year inaccuracies in files -
modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java
modules/javafx.graphics/src/main/java/javafx/scene/Scene.java

2. Removed tabs from 
modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java
3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class.

Also, I have created a new bug JDK-8200236 to address some of the valid 
suggestions from Mandy and Daniel.

Request you to review the new webrev.

Regards,
Ajit

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: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

[Ajit Ghaisas]

Thanks all for the review.

I have addressed the review comments in - 
http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/

The changes are -
1. Addressed the (c) year inaccuracies in files -
modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java
modules/javafx.graphics/src/main/java/javafx/scene/Scene.java

2. Removed tabs from 
modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java
3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class.

Also, I have created a new bug JDK-8200236 to address some of the valid 
suggestions from Mandy and Daniel.

Request you to review the new webrev.

Regards,
Ajit

-Original Message-
From: Kevin Rushforth 
Sent: Saturday, March 24, 2018 3:27 AM
To: Ajit Ghaisas
Cc: Mandy Chung; Daniel Fuchs; openjfx-dev@openjdk.java.net
Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of 
platform logger in javafx modules

The only additional comments I have are couple typos and a white-space
issue:

1. There is a typo in the Copyright year (201 rather than 2018) in the 
following two files:

modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java
modules/javafx.graphics/src/main/java/javafx/scene/Scene.java


2. There are tab characters in the following file that need to be changed to 
spaces:

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java
 public static void setUpClass() {
 >>>System.err.println("SelectBindingTest : log messages are 
expected from these tests.");


All my testing looks good. With this patch I am now able to run applications 
with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command 
line (as long as it doesn't use Swing interop).

-- Kevin


Ajit Ghaisas wrote:
> Hi Kevin, Mandy and Daniel,
>
> Please review the changeset that removes dependency on sun.util.logging 
> package from JavaFX code.
>
> Bug :  https://bugs.openjdk.java.net/browse/JDK-8195799
> Fix :  http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/
>
> Request you to review.
>
> Regards,
> Ajit
>   

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

OpenJFX GitHub mirror

[Nir Lisker]

Hi All,

A few comments about the mirror and JBS:

1. In PRs and issues on GitHub, I strongly suggest that the link to JBS be
included in the top comment. If the JBS issue was created after a
discussion, edit it in.

2. In JBS, I suggest to link to the GitHub mirror via More > Link > Web
Link and in the Link Text use something like "GitHub mirror" (open for
suggestions). JIRA renders the link in an easy to see way (easier than
looking at URLs). Iv'e tried it in a couple of issues, e.g.,
https://bugs.openjdk.java.net/browse/JDK-8198795 and it seems preferable to
me.

3. In JBS, I suggest a new label will be used for issues which are linked
to GitHub for search purposes. This is similar to the webbug label.

If these are agreeable, please add them to the contribution instructions.

4. What is https://github.com/javafxports/jfx-dev? Newcomers can confuse it
with javafxports/openjdk-jfx.

5. When the mirror is fully ready and operational, we should advertise on
community pages (like Reddit) to gather up contributors. Please keep a
mental reminder when the time comes.

Thanks to all who are working on this.

- Nir

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