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 >
