JavaFX 11 maven snapshots - empty jars

Thu Aug 9 13:33:38 UTC 2018

Right, that's a good idea. Thanks.

On Thu, Aug 9, 2018 at 3:32 PM Steve Hruda <steve.hruda at gmail.com> 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.hruda at 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
>> <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
>>>>
>>>
>
> --
> Mit freundlichen Grüßen
> Steve Hruda
>