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....@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.hr...@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.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 >>> <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....@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.hr...@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.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 < >>>>> 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: >>>>> >> >> <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
