Right, that's a good idea. Thanks. 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 >
