Re: Update on enabling JavaFX to work with OpenJDK builds

2018-02-28 Thread Kevin Rushforth
This seems reasonable to me as well: integrating the JavaFX modules into 
whatever dependency manager you are using seems like a good thing.


-- Kevin


Johan Vos wrote:

Hi Michael,

The second question is what I think should be the default.
This is similar to Java EE ^^^ EE4J  Jakarta EE development: if you
want to include (some) EE API's, you include them in maven/gradle/ant, or
your IDE does that for you.

Same, if you want to include JavaFX API's in your project, you declare that
as a dependency in maven/gradle/ant (or your IDE does that for you) and
they will get downloaded from Maven Central or jcenter (if you don't have
them yet).

- Johan

Op wo 28 feb. 2018 om 10:29 schreef Michael Paus :

  

Hi Kevin,
thank you for the update. I appreciate this work very much because I
think it is utterly important for JavaFX.
While reading the past messages again I was wondering whether this will
also address the following
two questions.
1. Will there be a way to determine at program start-up whether JavaFX
is available or not in order to be able
to give a user a clear and helpful error message in case it is not?
2. Might it even be possible to treat JavaFX as just another dependency
in your Maven (or whatever) project?
For me personally these questions are not so important because I prefer
the approach of building a native
installer which already contains everything needed, but for other people
in other usage scenarios these
questions might be important.
--Michael

Am 27.02.18 um 22:21 schrieb Kevin Rushforth:


One of the big challenges in running JavaFX with OpenJDK builds is
that developers need to build OpenJDK locally themselves and include
the JavaFX bits produced by a locally-built OpenJFX build.

In an earlier email with the subject "javafx might not be present"
[1], I mentioned our intention to make it easier for OpenJFX to be
built, tested, and run with OpenJDK builds that don't already contain
javafx.* modules. This will pave the way to allow a set of pre-built
javafx modules to be distributed that will run on top of a pre-built
OpenJDK.

By way of update, this work is underway and can be tracked via the
following two JBS issues:

1. Removing internal dependencies:

JDK-8195798 [2] : Address dependencies in javafx.* modules on internal
APIs of core modules

The above is an umbrella task that points to several linked blocking
bugs. All of these bugs are in progress and a few are already done
(e.g., removing jdk.internal.Unsafe from Marlin).


2. Enabling the building, testing, and distribution as a set of
separate modules

JDK-8198329 [3] : Support FX build / test using JDK that doesn't
include javafx.* modules

This one depends on the first two, but can be started in parallel, so
I plan to start on it in the next few days.


Let me know if you have any questions on this.

-- Kevin

[1]

  

http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021447.html


[2] https://bugs.openjdk.java.net/browse/JDK-8195798

[3] https://bugs.openjdk.java.net/browse/JDK-8198329

  



Re: Update on enabling JavaFX to work with OpenJDK builds

2018-02-28 Thread Michael Paus
I think this feature would be nice to have but I doubt that it is simple 
to achieve
because JavaFX may or may not already be included in the JDK against 
which you build
and on which your project later runs. There needs to be a strategy how 
to handle all

the resulting corner cases.

Am 28.02.18 um 11:27 schrieb Johan Vos:

Hi Michael,

The second question is what I think should be the default.
This is similar to Java EE ^^^ EE4J  Jakarta EE development: 
if you want to include (some) EE API's, you include them in 
maven/gradle/ant, or your IDE does that for you.


Same, if you want to include JavaFX API's in your project, you declare 
that as a dependency in maven/gradle/ant (or your IDE does that for 
you) and they will get downloaded from Maven Central or jcenter (if 
you don't have them yet).


- Johan

Op wo 28 feb. 2018 om 10:29 schreef Michael Paus >:


Hi Kevin,
thank you for the update. I appreciate this work very much because I
think it is utterly important for JavaFX.
While reading the past messages again I was wondering whether this
will
also address the following
two questions.
1. Will there be a way to determine at program start-up whether JavaFX
is available or not in order to be able
to give a user a clear and helpful error message in case it is not?
2. Might it even be possible to treat JavaFX as just another
dependency
in your Maven (or whatever) project?
For me personally these questions are not so important because I
prefer
the approach of building a native
installer which already contains everything needed, but for other
people
in other usage scenarios these
questions might be important.
--Michael

Am 27.02.18 um 22:21 schrieb Kevin Rushforth:
> One of the big challenges in running JavaFX with OpenJDK builds is
> that developers need to build OpenJDK locally themselves and include
> the JavaFX bits produced by a locally-built OpenJFX build.
>
> In an earlier email with the subject "javafx might not be present"
> [1], I mentioned our intention to make it easier for OpenJFX to be
> built, tested, and run with OpenJDK builds that don't already
contain
> javafx.* modules. This will pave the way to allow a set of pre-built
> javafx modules to be distributed that will run on top of a pre-built
> OpenJDK.
>
> By way of update, this work is underway and can be tracked via the
> following two JBS issues:
>
> 1. Removing internal dependencies:
>
> JDK-8195798 [2] : Address dependencies in javafx.* modules on
internal
> APIs of core modules
>
> The above is an umbrella task that points to several linked blocking
> bugs. All of these bugs are in progress and a few are already done
> (e.g., removing jdk.internal.Unsafe from Marlin).
>
>
> 2. Enabling the building, testing, and distribution as a set of
> separate modules
>
> JDK-8198329 [3] : Support FX build / test using JDK that doesn't
> include javafx.* modules
>
> This one depends on the first two, but can be started in
parallel, so
> I plan to start on it in the next few days.
>
>
> Let me know if you have any questions on this.
>
> -- Kevin
>
> [1]
>
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021447.html
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8195798
>
> [3] https://bugs.openjdk.java.net/browse/JDK-8198329
>





Re: Update on enabling JavaFX to work with OpenJDK builds

2018-02-28 Thread Michael Paus

Hi Kevin,
thank you for the update. I appreciate this work very much because I 
think it is utterly important for JavaFX.
While reading the past messages again I was wondering whether this will 
also address the following

two questions.
1. Will there be a way to determine at program start-up whether JavaFX 
is available or not in order to be able

to give a user a clear and helpful error message in case it is not?
2. Might it even be possible to treat JavaFX as just another dependency 
in your Maven (or whatever) project?
For me personally these questions are not so important because I prefer 
the approach of building a native
installer which already contains everything needed, but for other people 
in other usage scenarios these

questions might be important.
--Michael

Am 27.02.18 um 22:21 schrieb Kevin Rushforth:
One of the big challenges in running JavaFX with OpenJDK builds is 
that developers need to build OpenJDK locally themselves and include 
the JavaFX bits produced by a locally-built OpenJFX build.


In an earlier email with the subject "javafx might not be present" 
[1], I mentioned our intention to make it easier for OpenJFX to be 
built, tested, and run with OpenJDK builds that don't already contain 
javafx.* modules. This will pave the way to allow a set of pre-built 
javafx modules to be distributed that will run on top of a pre-built 
OpenJDK.


By way of update, this work is underway and can be tracked via the 
following two JBS issues:


1. Removing internal dependencies:

JDK-8195798 [2] : Address dependencies in javafx.* modules on internal 
APIs of core modules


The above is an umbrella task that points to several linked blocking 
bugs. All of these bugs are in progress and a few are already done 
(e.g., removing jdk.internal.Unsafe from Marlin).



2. Enabling the building, testing, and distribution as a set of 
separate modules


JDK-8198329 [3] : Support FX build / test using JDK that doesn't 
include javafx.* modules


This one depends on the first two, but can be started in parallel, so 
I plan to start on it in the next few days.



Let me know if you have any questions on this.

-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021447.html


[2] https://bugs.openjdk.java.net/browse/JDK-8195798

[3] https://bugs.openjdk.java.net/browse/JDK-8198329





Re: Update on enabling JavaFX to work with OpenJDK builds

2018-02-28 Thread Paul Ray Russell
 "I mentioned our intention to make it easier for OpenJFX to be built,
tested, and run with OpenJDK builds that don't already contain javafx.*
modules."

+1 Great


Re: Update on enabling JavaFX to work with OpenJDK builds

2018-02-27 Thread Mark Raynsford
On 2018-02-27T13:21:56 -0800
Kevin Rushforth  wrote:
>
> In an earlier email with the subject "javafx might not be present" [1], 
> I mentioned our intention to make it easier for OpenJFX to be built, 
> tested, and run with OpenJDK builds that don't already contain javafx.* 
> modules. This will pave the way to allow a set of pre-built javafx 
> modules to be distributed that will run on top of a pre-built OpenJDK.
> 
> By way of update, this work is underway and can be tracked via the 
> following two JBS issues:

This is good to hear, thank you!

I'll keep an eye on this as it unfolds.

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