[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: JavaFX 11 maven snapshots - empty jars
From:       Steve Hruda <steve.hruda () gmail ! com>
Date:       2018-08-29 9:48:24
Message-ID: CAHJxpfROhQxSaXatuAx7Wezvfk4OmcALWBrKGDNEyf7aX5vFQg () mail ! gmail ! com
[Download RAW message or body]

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 <johan.vos@gluonhq.com
>:

> 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 <steve.hruda@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@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@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@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@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@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@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
>>
>

-- 
Mit freundlichen Grüßen
Steve Hruda
[prev in list] [next in list] [prev in thread] [next in thread]