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
