JavaFX 11 maven snapshots - empty jars

Sat Jul 14 10:16:02 UTC 2018

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
<artifactId>javafx-controls-${javafx.platform}</artifactId>
- 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 <johan.vos at gluonhq.com> 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 <steve.hruda at gmail.com> 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.rushforth at 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.rushforth at 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 <steve.hruda at 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:
>> >> >> <artifactId>javafx-controls-${javafx.platform}</artifactId>
>> >> >>
>> >> >> Best Regards,
>> >> >> Steve
>> >> >>
>> >>
>> >>
>> >
>> > --
>> > Mit freundlichen Grüßen
>> > Steve Hruda
>> >
>> >
>> >
>>
>> --
>> Mit freundlichen Grüßen
>> Steve Hruda
>>
>