Re: JavaFX 11 maven snapshots - empty jars

[Steve Hruda]

Thanks Johan for the update. I will test it asap.

Best Regards,
Steve

Am Mi., 29. Aug. 2018 um 10:28 Uhr schrieb Johan Vos :

> Hi Steve,
>
> This has been applied in 11-ea+24 which is now in maven central.
>
> Thanks,
>
> - Johan
>
> On Thu, Aug 9, 2018 at 3:32 PM Steve Hruda  wrote:
>
>> Johan,
>> another temporary fix could be the META-INF attribute
>> "Automatic-Module-Name".  E.g. set it at the empty jar to
>> javafx.controls.workaround
>> https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#main-attributes
>>
>> Regards,
>> Steve
>>
>> Am Sa., 14. Juli 2018 um 12:16 Uhr schrieb Steve Hruda <
>> steve.hr...@gmail.com>:
>>
>>> Hi Johan,
>>> a discussion with a wider audience ist a very good Idea. Maybe some core
>>> developers of Gradle join the discussion and assist OpenJFX.
>>>
>>> Pleased dont missunderstand me, it's not my intention to push a solution
>>> which works only fit one case.
>>>
>>> From my current understandig, it's not a dedicated Eclipse issue. It's
>>> more an issue which affects somebody if he adds both jars (empty & platform
>>> dependent) to the module path.
>>>
>>> So in the end, It's ok for me that my mentioned workaround will not
>>> considered if doesn't work in both cases.
>>>
>>> To ensure that we all talk about the same, I describe it a little bit
>>> more in detail:
>>>
>>> 1. OpenJFX's gradle build
>>>  - Add the platform (windows,linux, mac) to the artifactId e.g
>>> javafx-controls-windows and don't use the classifier
>>>  - publish the platform dependent jar's to the repository without
>>> using any variables at the POMs. Which means that the current manipulation
>>> of the POM would no longer necessary.
>>> 2.  javafx.pom still defines properties which makes the maven handling
>>> more comfortable
>>> 3. in case of your hello3d example:
>>> https://github.com/johanvos/javafx11samples/blob/master/topics/javafx3d/hello3d
>>> - pom.xml: Remove the property at the classifier and define
>>> javafx-controls-${javafx.platform}
>>> - build.gradle: define "org.openjfx:javafx-controls-${javafx.platform}
>>> :11.0.0-SNAPSHOT" instead
>>>
>>> So in the end the maven user has still the possibility to define
>>> javafx.pom as a parent which sets the necessary javafx.platform.
>>>
>>> In addition and if it works, POM-only artifacts for maven builds can be
>>> defined (javafx-controls, javafx-graphics).
>>> These POM's can still use the Javafx.pom as a parent and Joeri's case 2
>>> should work for maven.
>>> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
>>>
>>> Regarding the current solution:
>>> Does the hello3d pom.xml work if
>>> 1. the parent javafx.pom will be removed so that the reference to the
>>> javafx.pom exists only at the
>>> 2. the dependency will be changed to javafx.controls without the
>>> classifier?
>>>
>>> Best Regards,
>>> Steve
>>>
>>>
>>>
>>>
>>>
>>> Johan Vos  schrieb am Sa., 14. Juli 2018, 10:32:
>>>
 Hi Steve,

 I think we really want a solution that allows for as many use cases as
 possible. If the current proposal is not working with Eclipse, we need to
 fix it. I wonder if we want to create a javafx gradle plugin? We already
 have a jfxmobile plugin for gradle to deal with JavaFX on mobile, but in
 general, a JavaFX gradle plugin that facilitates development of JavaFX on
 any platform might be good.

 I'm not sure that is a solution for all cases, as you don't want to
 force people to work with gradle. Hence, a maven plugin might be worth
 considering as well.

 It is not a JavaFX specific issue though. We will see an increasing
 number of related issues, where artifacts contain (platform-dependent)
 native code. Previously, the Java SDK that you installed contained all
 platform-specific libraries you needed. Moving these to separate projects
 also moves the platform-specific libraries to the repositories, and require
 the build tools to take care of this.
 IMHO, this is something that needs to be discussed with a wider
 audience. I want to discuss this at the OpenJDK Workshop (
 http://openjdk.java.net/workshop).

 - Johan

 On Fri, Jul 13, 2018 at 9:37 PM Steve Hruda 
 wrote:

> Okay, I understand.
>
> If the empty jar will be the final solution, then I think I will find a
> workaround at our Gradle's build to avoid loading of such empty jars.
>
>
> Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth <
> kevin.rushfo...@oracle.com>:
>
> >
> > > Is there a plan to split the really platform dependent stuff
> (natives)
> > from the platform independent Code?
> >
> > Not any time soon. And that would cause it's own set of problems.
> >
> > In particular I would not be in favor of a solution that leaked new
> > "module names" for what is (and should remain) an implementation
> detail.
> >
> > -- Kevin
> >

Re: JavaFX 11 maven snapshots - empty jars

[Johan Vos]

Thanks, that worked perfect.
ea-24 is available now.

- Johan

On Wed, Aug 22, 2018 at 3:03 PM Lennart Börjeson  wrote:

> Sound reasonable, thank you.
>
> In the meantime (waiting for the next version of the maven artefacts) I've
> updated my PR (https://github.com/johanvos/javafx11samples/pull/1) for
> your javafx11samples with a build.gradle work-around to filter out the
> empty javafx-jars.
>
> This makes your samples run with Java 11, gradle 4.9 and openjdx 11-ea+19.
>
> /Lennart
>
>
> 22 aug. 2018 kl. 14:11 skrev Johan Vos :
>
> I spent some more time on this.
> Adding the Automatic-Module-Name seems the easiest fix to me. I created a
> PR at https://github.com/javafxports/openjdk-jfx/pull/162 for this.
>
> Having the platform-name hardcoded in the artifact Id would require
> upfront magic in build.gradle or pom.xml to prevent the need to put a
> platform hardcoded in the build.gradle or pom.xml.
> Removing the empty jars never gives a result that works fine for both
> maven and gradle, see
> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
>
> In the end, the real fix for this should be in maven/gradle. We currently
> need to specify dependencies in both the module-info.java as well as in the
> pom.xml. That doesn't sound right. I would assume that the gradle Java
> plugin should check if a dependency contains a module-info.class, and if
> so, parse it and process it.
>
> - Johan
>
>
>
> On Thu, Aug 16, 2018 at 11:26 AM Lennart Börjeson 
> wrote:
>
>> FWIW, I've fixed the Gradle builds in the current javafx11samples and
>> sent you a pull request.
>>
>> I know these samples are only temporary, but I believe I'm not the only
>> gradle user who's been frustrated by not having any working example to try
>> out.
>>
>> My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in
>> the dependencies using Gradle's OPeratingSystem class.
>>
>>
>>
>> Best regards,
>>
>> /Lennart
>>
>>
>>
>

Re: JavaFX 11 maven snapshots - empty jars

[Johan Vos]

Hi Steve,

This has been applied in 11-ea+24 which is now in maven central.

Thanks,

- Johan

On Thu, Aug 9, 2018 at 3:32 PM Steve Hruda  wrote:

> Johan,
> another temporary fix could be the META-INF attribute
> "Automatic-Module-Name".  E.g. set it at the empty jar to
> javafx.controls.workaround
> https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#main-attributes
>
> Regards,
> Steve
>
> Am Sa., 14. Juli 2018 um 12:16 Uhr schrieb Steve Hruda <
> steve.hr...@gmail.com>:
>
>> Hi Johan,
>> a discussion with a wider audience ist a very good Idea. Maybe some core
>> developers of Gradle join the discussion and assist OpenJFX.
>>
>> Pleased dont missunderstand me, it's not my intention to push a solution
>> which works only fit one case.
>>
>> From my current understandig, it's not a dedicated Eclipse issue. It's
>> more an issue which affects somebody if he adds both jars (empty & platform
>> dependent) to the module path.
>>
>> So in the end, It's ok for me that my mentioned workaround will not
>> considered if doesn't work in both cases.
>>
>> To ensure that we all talk about the same, I describe it a little bit
>> more in detail:
>>
>> 1. OpenJFX's gradle build
>>  - Add the platform (windows,linux, mac) to the artifactId e.g
>> javafx-controls-windows and don't use the classifier
>>  - publish the platform dependent jar's to the repository without
>> using any variables at the POMs. Which means that the current manipulation
>> of the POM would no longer necessary.
>> 2.  javafx.pom still defines properties which makes the maven handling
>> more comfortable
>> 3. in case of your hello3d example:
>> https://github.com/johanvos/javafx11samples/blob/master/topics/javafx3d/hello3d
>> - pom.xml: Remove the property at the classifier and define
>> javafx-controls-${javafx.platform}
>> - build.gradle: define "org.openjfx:javafx-controls-${javafx.platform}
>> :11.0.0-SNAPSHOT" instead
>>
>> So in the end the maven user has still the possibility to define
>> javafx.pom as a parent which sets the necessary javafx.platform.
>>
>> In addition and if it works, POM-only artifacts for maven builds can be
>> defined (javafx-controls, javafx-graphics).
>> These POM's can still use the Javafx.pom as a parent and Joeri's case 2
>> should work for maven.
>> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
>>
>> Regarding the current solution:
>> Does the hello3d pom.xml work if
>> 1. the parent javafx.pom will be removed so that the reference to the
>> javafx.pom exists only at the
>> 2. the dependency will be changed to javafx.controls without the
>> classifier?
>>
>> Best Regards,
>> Steve
>>
>>
>>
>>
>>
>> Johan Vos  schrieb am Sa., 14. Juli 2018, 10:32:
>>
>>> Hi Steve,
>>>
>>> I think we really want a solution that allows for as many use cases as
>>> possible. If the current proposal is not working with Eclipse, we need to
>>> fix it. I wonder if we want to create a javafx gradle plugin? We already
>>> have a jfxmobile plugin for gradle to deal with JavaFX on mobile, but in
>>> general, a JavaFX gradle plugin that facilitates development of JavaFX on
>>> any platform might be good.
>>>
>>> I'm not sure that is a solution for all cases, as you don't want to
>>> force people to work with gradle. Hence, a maven plugin might be worth
>>> considering as well.
>>>
>>> It is not a JavaFX specific issue though. We will see an increasing
>>> number of related issues, where artifacts contain (platform-dependent)
>>> native code. Previously, the Java SDK that you installed contained all
>>> platform-specific libraries you needed. Moving these to separate projects
>>> also moves the platform-specific libraries to the repositories, and require
>>> the build tools to take care of this.
>>> IMHO, this is something that needs to be discussed with a wider
>>> audience. I want to discuss this at the OpenJDK Workshop (
>>> http://openjdk.java.net/workshop).
>>>
>>> - Johan
>>>
>>> On Fri, Jul 13, 2018 at 9:37 PM Steve Hruda 
>>> wrote:
>>>
 Okay, I understand.

 If the empty jar will be the final solution, then I think I will find a
 workaround at our Gradle's build to avoid loading of such empty jars.


 Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth <
 kevin.rushfo...@oracle.com>:

 >
 > > Is there a plan to split the really platform dependent stuff
 (natives)
 > from the platform independent Code?
 >
 > Not any time soon. And that would cause it's own set of problems.
 >
 > In particular I would not be in favor of a solution that leaked new
 > "module names" for what is (and should remain) an implementation
 detail.
 >
 > -- Kevin
 >
 >
 > On 7/13/2018 8:25 AM, Steve Hruda wrote:
 >
 > Johan,
 > hmm but is that not quite the same in case of the classifier? Because
 I
 > also have to define a property or static value in case of the
 classifier.
 >
 > 

Re: JavaFX 11 maven snapshots - empty jars

[Lennart Börjeson]

Sound reasonable, thank you.

In the meantime (waiting for the next version of the maven artefacts) I've 
updated my PR (https://github.com/johanvos/javafx11samples/pull/1 
) for your javafx11samples 
with a build.gradle work-around to filter out the empty javafx-jars.

This makes your samples run with Java 11, gradle 4.9 and openjdx 11-ea+19.

/Lennart

> 22 aug. 2018 kl. 14:11 skrev Johan Vos :
> 
> I spent some more time on this.
> Adding the Automatic-Module-Name seems the easiest fix to me. I created a PR 
> at https://github.com/javafxports/openjdk-jfx/pull/162 
>  for this.
> 
> Having the platform-name hardcoded in the artifact Id would require upfront 
> magic in build.gradle or pom.xml to prevent the need to put a platform 
> hardcoded in the build.gradle or pom.xml.
> Removing the empty jars never gives a result that works fine for both maven 
> and gradle, see 
> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 
> 
> 
> In the end, the real fix for this should be in maven/gradle. We currently 
> need to specify dependencies in both the module-info.java as well as in the 
> pom.xml. That doesn't sound right. I would assume that the gradle Java plugin 
> should check if a dependency contains a module-info.class, and if so, parse 
> it and process it.
> 
> - Johan
> 
> 
> 
> On Thu, Aug 16, 2018 at 11:26 AM Lennart Börjeson  > wrote:
> FWIW, I've fixed the Gradle builds in the current javafx11samples and sent 
> you a pull request.
> 
> I know these samples are only temporary, but I believe I'm not the only 
> gradle user who's been frustrated by not having any working example to try 
> out.
> 
> My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in the 
> dependencies using Gradle's OPeratingSystem class.
> 
> 
> 
> Best regards,
> 
> /Lennart
> 
> 

Re: JavaFX 11 maven snapshots - empty jars

[Johan Vos]

I spent some more time on this.
Adding the Automatic-Module-Name seems the easiest fix to me. I created a
PR at https://github.com/javafxports/openjdk-jfx/pull/162 for this.

Having the platform-name hardcoded in the artifact Id would require upfront
magic in build.gradle or pom.xml to prevent the need to put a platform
hardcoded in the build.gradle or pom.xml.
Removing the empty jars never gives a result that works fine for both maven
and gradle, see
https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804

In the end, the real fix for this should be in maven/gradle. We currently
need to specify dependencies in both the module-info.java as well as in the
pom.xml. That doesn't sound right. I would assume that the gradle Java
plugin should check if a dependency contains a module-info.class, and if
so, parse it and process it.

- Johan



On Thu, Aug 16, 2018 at 11:26 AM Lennart Börjeson 
wrote:

> FWIW, I've fixed the Gradle builds in the current javafx11samples and sent
> you a pull request.
>
> I know these samples are only temporary, but I believe I'm not the only
> gradle user who's been frustrated by not having any working example to try
> out.
>
> My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in
> the dependencies using Gradle's OPeratingSystem class.
>
>
>
> Best regards,
>
> /Lennart
>
>
>

Re: JavaFX 11 maven snapshots - empty jars

[Lennart Börjeson]

FWIW, I've fixed the Gradle builds in the current javafx11samples and sent you 
a pull request.

I know these samples are only temporary, but I believe I'm not the only gradle 
user who's been frustrated by not having any working example to try out.

My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in the 
dependencies using Gradle's OPeratingSystem class.



Best regards,

/Lennart

Re: JavaFX 11 maven snapshots - empty jars

[Johan Vos]

Right, that's a good idea. Thanks.

On Thu, Aug 9, 2018 at 3:32 PM Steve Hruda  wrote:

> Johan,
> another temporary fix could be the META-INF attribute
> "Automatic-Module-Name".  E.g. set it at the empty jar to
> javafx.controls.workaround
> https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#main-attributes
>
> Regards,
> Steve
>
> Am Sa., 14. Juli 2018 um 12:16 Uhr schrieb Steve Hruda <
> steve.hr...@gmail.com>:
>
>> Hi Johan,
>> a discussion with a wider audience ist a very good Idea. Maybe some core
>> developers of Gradle join the discussion and assist OpenJFX.
>>
>> Pleased dont missunderstand me, it's not my intention to push a solution
>> which works only fit one case.
>>
>> From my current understandig, it's not a dedicated Eclipse issue. It's
>> more an issue which affects somebody if he adds both jars (empty & platform
>> dependent) to the module path.
>>
>> So in the end, It's ok for me that my mentioned workaround will not
>> considered if doesn't work in both cases.
>>
>> To ensure that we all talk about the same, I describe it a little bit
>> more in detail:
>>
>> 1. OpenJFX's gradle build
>>  - Add the platform (windows,linux, mac) to the artifactId e.g
>> javafx-controls-windows and don't use the classifier
>>  - publish the platform dependent jar's to the repository without
>> using any variables at the POMs. Which means that the current manipulation
>> of the POM would no longer necessary.
>> 2.  javafx.pom still defines properties which makes the maven handling
>> more comfortable
>> 3. in case of your hello3d example:
>> https://github.com/johanvos/javafx11samples/blob/master/topics/javafx3d/hello3d
>> - pom.xml: Remove the property at the classifier and define
>> javafx-controls-${javafx.platform}
>> - build.gradle: define "org.openjfx:javafx-controls-${javafx.platform}
>> :11.0.0-SNAPSHOT" instead
>>
>> So in the end the maven user has still the possibility to define
>> javafx.pom as a parent which sets the necessary javafx.platform.
>>
>> In addition and if it works, POM-only artifacts for maven builds can be
>> defined (javafx-controls, javafx-graphics).
>> These POM's can still use the Javafx.pom as a parent and Joeri's case 2
>> should work for maven.
>> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
>>
>> Regarding the current solution:
>> Does the hello3d pom.xml work if
>> 1. the parent javafx.pom will be removed so that the reference to the
>> javafx.pom exists only at the
>> 2. the dependency will be changed to javafx.controls without the
>> classifier?
>>
>> Best Regards,
>> Steve
>>
>>
>>
>>
>>
>> Johan Vos  schrieb am Sa., 14. Juli 2018, 10:32:
>>
>>> Hi Steve,
>>>
>>> I think we really want a solution that allows for as many use cases as
>>> possible. If the current proposal is not working with Eclipse, we need to
>>> fix it. I wonder if we want to create a javafx gradle plugin? We already
>>> have a jfxmobile plugin for gradle to deal with JavaFX on mobile, but in
>>> general, a JavaFX gradle plugin that facilitates development of JavaFX on
>>> any platform might be good.
>>>
>>> I'm not sure that is a solution for all cases, as you don't want to
>>> force people to work with gradle. Hence, a maven plugin might be worth
>>> considering as well.
>>>
>>> It is not a JavaFX specific issue though. We will see an increasing
>>> number of related issues, where artifacts contain (platform-dependent)
>>> native code. Previously, the Java SDK that you installed contained all
>>> platform-specific libraries you needed. Moving these to separate projects
>>> also moves the platform-specific libraries to the repositories, and require
>>> the build tools to take care of this.
>>> IMHO, this is something that needs to be discussed with a wider
>>> audience. I want to discuss this at the OpenJDK Workshop (
>>> http://openjdk.java.net/workshop).
>>>
>>> - Johan
>>>
>>> On Fri, Jul 13, 2018 at 9:37 PM Steve Hruda 
>>> wrote:
>>>
 Okay, I understand.

 If the empty jar will be the final solution, then I think I will find a
 workaround at our Gradle's build to avoid loading of such empty jars.


 Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth <
 kevin.rushfo...@oracle.com>:

 >
 > > Is there a plan to split the really platform dependent stuff
 (natives)
 > from the platform independent Code?
 >
 > Not any time soon. And that would cause it's own set of problems.
 >
 > In particular I would not be in favor of a solution that leaked new
 > "module names" for what is (and should remain) an implementation
 detail.
 >
 > -- Kevin
 >
 >
 > On 7/13/2018 8:25 AM, Steve Hruda wrote:
 >
 > Johan,
 > hmm but is that not quite the same in case of the classifier? Because
 I
 > also have to define a property or static value in case of the
 classifier.
 >
 > Kevin,
 > The same name could b e a problem.
 > 

Re: JavaFX 11 maven snapshots - empty jars

[Steve Hruda]

Johan,
another temporary fix could be the META-INF attribute
"Automatic-Module-Name".  E.g. set it at the empty jar to
javafx.controls.workaround
https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#main-attributes

Regards,
Steve

Am Sa., 14. Juli 2018 um 12:16 Uhr schrieb Steve Hruda <
steve.hr...@gmail.com>:

> Hi Johan,
> a discussion with a wider audience ist a very good Idea. Maybe some core
> developers of Gradle join the discussion and assist OpenJFX.
>
> Pleased dont missunderstand me, it's not my intention to push a solution
> which works only fit one case.
>
> From my current understandig, it's not a dedicated Eclipse issue. It's
> more an issue which affects somebody if he adds both jars (empty & platform
> dependent) to the module path.
>
> So in the end, It's ok for me that my mentioned workaround will not
> considered if doesn't work in both cases.
>
> To ensure that we all talk about the same, I describe it a little bit more
> in detail:
>
> 1. OpenJFX's gradle build
>  - Add the platform (windows,linux, mac) to the artifactId e.g
> javafx-controls-windows and don't use the classifier
>  - publish the platform dependent jar's to the repository without
> using any variables at the POMs. Which means that the current manipulation
> of the POM would no longer necessary.
> 2.  javafx.pom still defines properties which makes the maven handling
> more comfortable
> 3. in case of your hello3d example:
> https://github.com/johanvos/javafx11samples/blob/master/topics/javafx3d/hello3d
> - pom.xml: Remove the property at the classifier and define
> javafx-controls-${javafx.platform}
> - build.gradle: define "org.openjfx:javafx-controls-${javafx.platform}
> :11.0.0-SNAPSHOT" instead
>
> So in the end the maven user has still the possibility to define
> javafx.pom as a parent which sets the necessary javafx.platform.
>
> In addition and if it works, POM-only artifacts for maven builds can be
> defined (javafx-controls, javafx-graphics).
> These POM's can still use the Javafx.pom as a parent and Joeri's case 2
> should work for maven.
> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
>
> Regarding the current solution:
> Does the hello3d pom.xml work if
> 1. the parent javafx.pom will be removed so that the reference to the
> javafx.pom exists only at the
> 2. the dependency will be changed to javafx.controls without the
> classifier?
>
> Best Regards,
> Steve
>
>
>
>
>
> Johan Vos  schrieb am Sa., 14. Juli 2018, 10:32:
>
>> Hi Steve,
>>
>> I think we really want a solution that allows for as many use cases as
>> possible. If the current proposal is not working with Eclipse, we need to
>> fix it. I wonder if we want to create a javafx gradle plugin? We already
>> have a jfxmobile plugin for gradle to deal with JavaFX on mobile, but in
>> general, a JavaFX gradle plugin that facilitates development of JavaFX on
>> any platform might be good.
>>
>> I'm not sure that is a solution for all cases, as you don't want to force
>> people to work with gradle. Hence, a maven plugin might be worth
>> considering as well.
>>
>> It is not a JavaFX specific issue though. We will see an increasing
>> number of related issues, where artifacts contain (platform-dependent)
>> native code. Previously, the Java SDK that you installed contained all
>> platform-specific libraries you needed. Moving these to separate projects
>> also moves the platform-specific libraries to the repositories, and require
>> the build tools to take care of this.
>> IMHO, this is something that needs to be discussed with a wider audience.
>> I want to discuss this at the OpenJDK Workshop (
>> http://openjdk.java.net/workshop).
>>
>> - Johan
>>
>> On Fri, Jul 13, 2018 at 9:37 PM Steve Hruda 
>> wrote:
>>
>>> Okay, I understand.
>>>
>>> If the empty jar will be the final solution, then I think I will find a
>>> workaround at our Gradle's build to avoid loading of such empty jars.
>>>
>>>
>>> Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth <
>>> kevin.rushfo...@oracle.com>:
>>>
>>> >
>>> > > Is there a plan to split the really platform dependent stuff
>>> (natives)
>>> > from the platform independent Code?
>>> >
>>> > Not any time soon. And that would cause it's own set of problems.
>>> >
>>> > In particular I would not be in favor of a solution that leaked new
>>> > "module names" for what is (and should remain) an implementation
>>> detail.
>>> >
>>> > -- Kevin
>>> >
>>> >
>>> > On 7/13/2018 8:25 AM, Steve Hruda wrote:
>>> >
>>> > Johan,
>>> > hmm but is that not quite the same in case of the classifier? Because I
>>> > also have to define a property or static value in case of the
>>> classifier.
>>> >
>>> > Kevin,
>>> > The same name could b e a problem.
>>> > "Module names, like package names, must not conflict. The recommended
>>> way
>>> > to name a module is to use the reverse-domain-name pattern that has
>>> long
>>> > been recommended for naming packages. "
>>> >
>>> >
>>> 

Re: JavaFX 11 maven snapshots - empty jars

[Mark Soderquist]

I've been forging ahead in my JavaFX work trying to get things figured out
with OpenJDK 11 and OpenJFX. It's an exciting challenge.

I've read the other two threads regarding the Maven snapshot artifacts and
there are probably more questions than answers at this point. Since Johan
mentioned the OpenJDK workshop I wanted to ask about the intended tooling
around modules, specifically since OpenJFX just got thrust into that space
starting with OpenJDK 11.

Maven only handles JARs as far as I can tell. Support for proper modules,
JMODs, is limited at this point. I'm not sure if Maven would know how to
use a JMOD if it were put in a repository. I haven't tried. Even if we
manage to get the current artifacts working we still have to be able to get
through jlink and javapackager to create a deployable application.

My hope for the workshop is that some guidance will come from those who
understand how java modules are intended to work so we can apply that
guidance to OpenJFX. It would apply to all those who have to make platform
specific modules.

- Mark

Re: JavaFX 11 maven snapshots - empty jars

[Steve Hruda]

Hi Johan,
a discussion with a wider audience ist a very good Idea. Maybe some core
developers of Gradle join the discussion and assist OpenJFX.

Pleased dont missunderstand me, it's not my intention to push a solution
which works only fit one case.

>From my current understandig, it's not a dedicated Eclipse issue. It's more
an issue which affects somebody if he adds both jars (empty & platform
dependent) to the module path.

So in the end, It's ok for me that my mentioned workaround will not
considered if doesn't work in both cases.

To ensure that we all talk about the same, I describe it a little bit more
in detail:

1. OpenJFX's gradle build
 - Add the platform (windows,linux, mac) to the artifactId e.g
javafx-controls-windows and don't use the classifier
 - publish the platform dependent jar's to the repository without using
any variables at the POMs. Which means that the current manipulation of the
POM would no longer necessary.
2.  javafx.pom still defines properties which makes the maven handling more
comfortable
3. in case of your hello3d example:
https://github.com/johanvos/javafx11samples/blob/master/topics/javafx3d/hello3d
- pom.xml: Remove the property at the classifier and define
javafx-controls-${javafx.platform}
- build.gradle: define "org.openjfx:javafx-controls-${javafx.platform}
:11.0.0-SNAPSHOT" instead

So in the end the maven user has still the possibility to define javafx.pom
as a parent which sets the necessary javafx.platform.

In addition and if it works, POM-only artifacts for maven builds can be
defined (javafx-controls, javafx-graphics).
These POM's can still use the Javafx.pom as a parent and Joeri's case 2
should work for maven.
https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804

Regarding the current solution:
Does the hello3d pom.xml work if
1. the parent javafx.pom will be removed so that the reference to the
javafx.pom exists only at the
2. the dependency will be changed to javafx.controls without the classifier?

Best Regards,
Steve





Johan Vos  schrieb am Sa., 14. Juli 2018, 10:32:

> Hi Steve,
>
> I think we really want a solution that allows for as many use cases as
> possible. If the current proposal is not working with Eclipse, we need to
> fix it. I wonder if we want to create a javafx gradle plugin? We already
> have a jfxmobile plugin for gradle to deal with JavaFX on mobile, but in
> general, a JavaFX gradle plugin that facilitates development of JavaFX on
> any platform might be good.
>
> I'm not sure that is a solution for all cases, as you don't want to force
> people to work with gradle. Hence, a maven plugin might be worth
> considering as well.
>
> It is not a JavaFX specific issue though. We will see an increasing number
> of related issues, where artifacts contain (platform-dependent) native
> code. Previously, the Java SDK that you installed contained all
> platform-specific libraries you needed. Moving these to separate projects
> also moves the platform-specific libraries to the repositories, and require
> the build tools to take care of this.
> IMHO, this is something that needs to be discussed with a wider audience.
> I want to discuss this at the OpenJDK Workshop (
> http://openjdk.java.net/workshop).
>
> - Johan
>
> On Fri, Jul 13, 2018 at 9:37 PM Steve Hruda  wrote:
>
>> Okay, I understand.
>>
>> If the empty jar will be the final solution, then I think I will find a
>> workaround at our Gradle's build to avoid loading of such empty jars.
>>
>>
>> Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth <
>> kevin.rushfo...@oracle.com>:
>>
>> >
>> > > Is there a plan to split the really platform dependent stuff (natives)
>> > from the platform independent Code?
>> >
>> > Not any time soon. And that would cause it's own set of problems.
>> >
>> > In particular I would not be in favor of a solution that leaked new
>> > "module names" for what is (and should remain) an implementation detail.
>> >
>> > -- Kevin
>> >
>> >
>> > On 7/13/2018 8:25 AM, Steve Hruda wrote:
>> >
>> > Johan,
>> > hmm but is that not quite the same in case of the classifier? Because I
>> > also have to define a property or static value in case of the
>> classifier.
>> >
>> > Kevin,
>> > The same name could b e a problem.
>> > "Module names, like package names, must not conflict. The recommended
>> way
>> > to name a module is to use the reverse-domain-name pattern that has long
>> > been recommended for naming packages. "
>> >
>> > http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations
>> >
>> > But something like a "javafx.controls.dummy" could help.
>> >
>> > Is there a plan to split the really platform dependent stuff (natives)
>> > from the platform independent Code?
>> >
>> > Which would causein the end that the javafx.controls.jar would not be
>> > empty?
>> >
>> > Maybe in that case it makes sense that the empty jar uses the module
>> name
>> > javafx.controls and the platform dependent uses e.g.
>> 

Re: JavaFX 11 maven snapshots - empty jars

[Johan Vos]

Hi Steve,

I think we really want a solution that allows for as many use cases as
possible. If the current proposal is not working with Eclipse, we need to
fix it. I wonder if we want to create a javafx gradle plugin? We already
have a jfxmobile plugin for gradle to deal with JavaFX on mobile, but in
general, a JavaFX gradle plugin that facilitates development of JavaFX on
any platform might be good.

I'm not sure that is a solution for all cases, as you don't want to force
people to work with gradle. Hence, a maven plugin might be worth
considering as well.

It is not a JavaFX specific issue though. We will see an increasing number
of related issues, where artifacts contain (platform-dependent) native
code. Previously, the Java SDK that you installed contained all
platform-specific libraries you needed. Moving these to separate projects
also moves the platform-specific libraries to the repositories, and require
the build tools to take care of this.
IMHO, this is something that needs to be discussed with a wider audience. I
want to discuss this at the OpenJDK Workshop (
http://openjdk.java.net/workshop).

- Johan

On Fri, Jul 13, 2018 at 9:37 PM Steve Hruda  wrote:

> Okay, I understand.
>
> If the empty jar will be the final solution, then I think I will find a
> workaround at our Gradle's build to avoid loading of such empty jars.
>
>
> Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth <
> kevin.rushfo...@oracle.com>:
>
> >
> > > Is there a plan to split the really platform dependent stuff (natives)
> > from the platform independent Code?
> >
> > Not any time soon. And that would cause it's own set of problems.
> >
> > In particular I would not be in favor of a solution that leaked new
> > "module names" for what is (and should remain) an implementation detail.
> >
> > -- Kevin
> >
> >
> > On 7/13/2018 8:25 AM, Steve Hruda wrote:
> >
> > Johan,
> > hmm but is that not quite the same in case of the classifier? Because I
> > also have to define a property or static value in case of the classifier.
> >
> > Kevin,
> > The same name could b e a problem.
> > "Module names, like package names, must not conflict. The recommended way
> > to name a module is to use the reverse-domain-name pattern that has long
> > been recommended for naming packages. "
> >
> > http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations
> >
> > But something like a "javafx.controls.dummy" could help.
> >
> > Is there a plan to split the really platform dependent stuff (natives)
> > from the platform independent Code?
> >
> > Which would causein the end that the javafx.controls.jar would not be
> > empty?
> >
> > Maybe in that case it makes sense that the empty jar uses the module name
> > javafx.controls and the platform dependent uses e.g.
> javafx.controls.windows
> >
> > Regards,
> > Steve
> >
> >
> > Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth <
> > kevin.rushfo...@oracle.com>:
> >
> >> Would it help Eclipse if instead of an empty jar, the jar contained just
> >> the module-info.class file? Or will that then cause problems because of
> >> two .jar files with the same module name?
> >>
> >> -- Kevin
> >>
> >>
> >> On 7/13/2018 7:37 AM, Johan Vos wrote:
> >> > Hi Steve,
> >> >
> >> > Yes, that has been considered, but I'm more than happy to re-open the
> >> > discussion.
> >> >
> >> > The problem with javafx-controls-${javafx.platform} as the artifactId
> is
> >> > that in that case, the gradle developer is in all cases required to
> add
> >> the
> >> > platform suffix to the dependency, which makes it very hard to manage
> >> > JavaFX projects via version control, as the dependency file will
> >> hard-code
> >> > contain e.g. javafx-controls-linux, where other developers would use
> >> > javafx-controls-windows
> >> >
> >> > - Johan
> >> >
> >> >
> >> > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda 
> >> wrote:
> >> >
> >> >> Hi,
> >> >> Johan asked me to move the empty jar discussion to the mailing list.
> >> >>
> >> >> As I mentioned at GitHub, we did some tests with the published
> >> SNAPSHOT's
> >> >> and we had to force an exclude of the empty jars at the dependecies.
> >> >> Otherwise e.g. Eclipse shows a warning that the module name is
> instable
> >> >> because of the "auto-generated" module name in case of the empty
> jars.
> >> >>
> >> >> Thanks at Joeri for explaining the reason. I understand now the
> reason
> >> for
> >> >> the empty jar.
> >> >>
> >>
> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
> >> >>
> >> >> I never tried it and I know that it doesn't fit to the familar
> >> handling of
> >> >> platform dependent jars...
> >> >>
> >> >> Have you thought about it to use the platform variable at the
> >> artifactId?
> >> >> Something like:
> >> >> javafx-controls-${javafx.platform}
> >> >>
> >> >> Best Regards,
> >> >> Steve
> >> >>
> >>
> >>
> >
> > --
> > Mit freundlichen Grüßen
> > Steve Hruda
> >
> >
> >
>
> --
> Mit freundlichen Grüßen
> Steve 

Re: JavaFX 11 maven snapshots - empty jars

[Steve Hruda]

Okay, I understand.

If the empty jar will be the final solution, then I think I will find a
workaround at our Gradle's build to avoid loading of such empty jars.


Am Fr., 13. Juli 2018 um 17:39 Uhr schrieb Kevin Rushforth <
kevin.rushfo...@oracle.com>:

>
> > Is there a plan to split the really platform dependent stuff (natives)
> from the platform independent Code?
>
> Not any time soon. And that would cause it's own set of problems.
>
> In particular I would not be in favor of a solution that leaked new
> "module names" for what is (and should remain) an implementation detail.
>
> -- Kevin
>
>
> On 7/13/2018 8:25 AM, Steve Hruda wrote:
>
> Johan,
> hmm but is that not quite the same in case of the classifier? Because I
> also have to define a property or static value in case of the classifier.
>
> Kevin,
> The same name could b e a problem.
> "Module names, like package names, must not conflict. The recommended way
> to name a module is to use the reverse-domain-name pattern that has long
> been recommended for naming packages. "
>
> http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations
>
> But something like a "javafx.controls.dummy" could help.
>
> Is there a plan to split the really platform dependent stuff (natives)
> from the platform independent Code?
>
> Which would causein the end that the javafx.controls.jar would not be
> empty?
>
> Maybe in that case it makes sense that the empty jar uses the module name
> javafx.controls and the platform dependent uses e.g. javafx.controls.windows
>
> Regards,
> Steve
>
>
> Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth <
> kevin.rushfo...@oracle.com>:
>
>> Would it help Eclipse if instead of an empty jar, the jar contained just
>> the module-info.class file? Or will that then cause problems because of
>> two .jar files with the same module name?
>>
>> -- Kevin
>>
>>
>> On 7/13/2018 7:37 AM, Johan Vos wrote:
>> > Hi Steve,
>> >
>> > Yes, that has been considered, but I'm more than happy to re-open the
>> > discussion.
>> >
>> > The problem with javafx-controls-${javafx.platform} as the artifactId is
>> > that in that case, the gradle developer is in all cases required to add
>> the
>> > platform suffix to the dependency, which makes it very hard to manage
>> > JavaFX projects via version control, as the dependency file will
>> hard-code
>> > contain e.g. javafx-controls-linux, where other developers would use
>> > javafx-controls-windows
>> >
>> > - Johan
>> >
>> >
>> > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda 
>> wrote:
>> >
>> >> Hi,
>> >> Johan asked me to move the empty jar discussion to the mailing list.
>> >>
>> >> As I mentioned at GitHub, we did some tests with the published
>> SNAPSHOT's
>> >> and we had to force an exclude of the empty jars at the dependecies.
>> >> Otherwise e.g. Eclipse shows a warning that the module name is instable
>> >> because of the "auto-generated" module name in case of the empty jars.
>> >>
>> >> Thanks at Joeri for explaining the reason. I understand now the reason
>> for
>> >> the empty jar.
>> >>
>> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
>> >>
>> >> I never tried it and I know that it doesn't fit to the familar
>> handling of
>> >> platform dependent jars...
>> >>
>> >> Have you thought about it to use the platform variable at the
>> artifactId?
>> >> Something like:
>> >> javafx-controls-${javafx.platform}
>> >>
>> >> Best Regards,
>> >> Steve
>> >>
>>
>>
>
> --
> Mit freundlichen Grüßen
> Steve Hruda
>
>
>

-- 
Mit freundlichen Grüßen
Steve Hruda

Re: JavaFX 11 maven snapshots - empty jars

[Kevin Rushforth]

> Is there a plan to split the really platform dependent stuff 
(natives) from the platform independent Code?


Not any time soon. And that would cause it's own set of problems.

In particular I would not be in favor of a solution that leaked new 
"module names" for what is (and should remain) an implementation detail.


-- Kevin


On 7/13/2018 8:25 AM, Steve Hruda wrote:

Johan,
hmm but is that not quite the same in case of the classifier? Because 
I also have to define a property or static value in case of the 
classifier.


Kevin,
The same name could b e a problem.
"Module names, like package names, must not conflict. The recommended 
way to name a module is to use the reverse-domain-name pattern that 
has long been recommended for naming packages. "


http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations

But something like a "javafx.controls.dummy" could help.

Is there a plan to split the really platform dependent stuff (natives) 
from the platform independent Code?


Which would causein the end that the javafx.controls.jar would not be 
empty?


Maybe in that case it makes sense that the empty jar uses the module 
name javafx.controls and the platform dependent uses e.g. 
javafx.controls.windows


Regards,
Steve


Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>>:


Would it help Eclipse if instead of an empty jar, the jar
contained just
the module-info.class file? Or will that then cause problems
because of
two .jar files with the same module name?

-- Kevin


On 7/13/2018 7:37 AM, Johan Vos wrote:
> Hi Steve,
>
> Yes, that has been considered, but I'm more than happy to
re-open the
> discussion.
>
> The problem with javafx-controls-${javafx.platform} as the
artifactId is
> that in that case, the gradle developer is in all cases required
to add the
> platform suffix to the dependency, which makes it very hard to
manage
> JavaFX projects via version control, as the dependency file will
hard-code
> contain e.g. javafx-controls-linux, where other developers would use
> javafx-controls-windows
>
> - Johan
>
>
> On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda
mailto:steve.hr...@gmail.com>> wrote:
>
>> Hi,
>> Johan asked me to move the empty jar discussion to the mailing
list.
>>
>> As I mentioned at GitHub, we did some tests with the published
SNAPSHOT's
>> and we had to force an exclude of the empty jars at the
dependecies.
>> Otherwise e.g. Eclipse shows a warning that the module name is
instable
>> because of the "auto-generated" module name in case of the
empty jars.
>>
>> Thanks at Joeri for explaining the reason. I understand now the
reason for
>> the empty jar.
>>
https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
>>
>> I never tried it and I know that it doesn't fit to the familar
handling of
>> platform dependent jars...
>>
>> Have you thought about it to use the platform variable at the
artifactId?
>> Something like:
>> javafx-controls-${javafx.platform}
>>
>> Best Regards,
>> Steve
>>



--
Mit freundlichen Grüßen
Steve Hruda

Re: JavaFX 11 maven snapshots - empty jars

[Steve Hruda]

Johan,
hmm but is that not quite the same in case of the classifier? Because I
also have to define a property or static value in case of the classifier.

Kevin,
The same name could b e a problem.
"Module names, like package names, must not conflict. The recommended way
to name a module is to use the reverse-domain-name pattern that has long
been recommended for naming packages. "

http://openjdk.java.net/projects/jigsaw/spec/sotms/#module-declarations

But something like a "javafx.controls.dummy" could help.

Is there a plan to split the really platform dependent stuff (natives) from
the platform independent Code?

Which would causein the end that the javafx.controls.jar would not be empty?

Maybe in that case it makes sense that the empty jar uses the module name
javafx.controls and the platform dependent uses e.g. javafx.controls.windows

Regards,
Steve


Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth <
kevin.rushfo...@oracle.com>:

> Would it help Eclipse if instead of an empty jar, the jar contained just
> the module-info.class file? Or will that then cause problems because of
> two .jar files with the same module name?
>
> -- Kevin
>
>
> On 7/13/2018 7:37 AM, Johan Vos wrote:
> > Hi Steve,
> >
> > Yes, that has been considered, but I'm more than happy to re-open the
> > discussion.
> >
> > The problem with javafx-controls-${javafx.platform} as the artifactId is
> > that in that case, the gradle developer is in all cases required to add
> the
> > platform suffix to the dependency, which makes it very hard to manage
> > JavaFX projects via version control, as the dependency file will
> hard-code
> > contain e.g. javafx-controls-linux, where other developers would use
> > javafx-controls-windows
> >
> > - Johan
> >
> >
> > On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda 
> wrote:
> >
> >> Hi,
> >> Johan asked me to move the empty jar discussion to the mailing list.
> >>
> >> As I mentioned at GitHub, we did some tests with the published
> SNAPSHOT's
> >> and we had to force an exclude of the empty jars at the dependecies.
> >> Otherwise e.g. Eclipse shows a warning that the module name is instable
> >> because of the "auto-generated" module name in case of the empty jars.
> >>
> >> Thanks at Joeri for explaining the reason. I understand now the reason
> for
> >> the empty jar.
> >>
> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
> >>
> >> I never tried it and I know that it doesn't fit to the familar handling
> of
> >> platform dependent jars...
> >>
> >> Have you thought about it to use the platform variable at the
> artifactId?
> >> Something like:
> >> javafx-controls-${javafx.platform}
> >>
> >> Best Regards,
> >> Steve
> >>
>
>

-- 
Mit freundlichen Grüßen
Steve Hruda

Re: JavaFX 11 maven snapshots - empty jars

[Kevin Rushforth]

Would it help Eclipse if instead of an empty jar, the jar contained just 
the module-info.class file? Or will that then cause problems because of 
two .jar files with the same module name?


-- Kevin


On 7/13/2018 7:37 AM, Johan Vos wrote:

Hi Steve,

Yes, that has been considered, but I'm more than happy to re-open the
discussion.

The problem with javafx-controls-${javafx.platform} as the artifactId is
that in that case, the gradle developer is in all cases required to add the
platform suffix to the dependency, which makes it very hard to manage
JavaFX projects via version control, as the dependency file will hard-code
contain e.g. javafx-controls-linux, where other developers would use
javafx-controls-windows

- Johan


On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda  wrote:


Hi,
Johan asked me to move the empty jar discussion to the mailing list.

As I mentioned at GitHub, we did some tests with the published SNAPSHOT's
and we had to force an exclude of the empty jars at the dependecies.
Otherwise e.g. Eclipse shows a warning that the module name is instable
because of the "auto-generated" module name in case of the empty jars.

Thanks at Joeri for explaining the reason. I understand now the reason for
the empty jar.
https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804

I never tried it and I know that it doesn't fit to the familar handling of
platform dependent jars...

Have you thought about it to use the platform variable at the artifactId?
Something like:
javafx-controls-${javafx.platform}

Best Regards,
Steve

Re: JavaFX 11 maven snapshots - empty jars

[Johan Vos]

Hi Steve,

Yes, that has been considered, but I'm more than happy to re-open the
discussion.

The problem with javafx-controls-${javafx.platform} as the artifactId is
that in that case, the gradle developer is in all cases required to add the
platform suffix to the dependency, which makes it very hard to manage
JavaFX projects via version control, as the dependency file will hard-code
contain e.g. javafx-controls-linux, where other developers would use
javafx-controls-windows

- Johan


On Fri, Jul 13, 2018 at 4:30 PM Steve Hruda  wrote:

> Hi,
> Johan asked me to move the empty jar discussion to the mailing list.
>
> As I mentioned at GitHub, we did some tests with the published SNAPSHOT's
> and we had to force an exclude of the empty jars at the dependecies.
> Otherwise e.g. Eclipse shows a warning that the module name is instable
> because of the "auto-generated" module name in case of the empty jars.
>
> Thanks at Joeri for explaining the reason. I understand now the reason for
> the empty jar.
> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804
>
> I never tried it and I know that it doesn't fit to the familar handling of
> platform dependent jars...
>
> Have you thought about it to use the platform variable at the artifactId?
> Something like:
> javafx-controls-${javafx.platform}
>
> Best Regards,
> Steve
>