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
