There was a discussion on this some years ago, it started here: https://mail.openjdk.org/pipermail/openjfx-dev/2018-April/021762.html (and continued in https://mail.openjdk.org/pipermail/openjfx-dev/2018-May/021774.html). There might have been another discussion after that, I don't remember.
Thomas, the graphics, media, and web modules contain OS-specific libraries. You will need to do what I showed for any of these that you use. On Fri, Oct 21, 2022 at 12:05 AM Thomas Reinhardt <thomas.reinha...@s4p.de> wrote: > Interesting. I will repeat my test more carefully. Maybe I am just doing > something incredible stupid. But Andy has a good point: why include the > java classes at all in the platform-specific jars - shouldn't they just > contain the native libraries if all the java code is indeed the same? > > -Thomas > > ------------------------------ > *From:* openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Andy > Goryachev <andy.goryac...@oracle.com> > *Sent:* 20 October 2022 22:53 > *To:* John Hendrikx <john.hendr...@gmail.com>; openjfx-dev@openjdk.org < > openjfx-dev@openjdk.org> > *Subject:* Re: Platform independent deployment > > > Good point - are we packaging platform-specific javafx parts incorrectly? > > > > -andy > > > > *From: *openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John > Hendrikx <john.hendr...@gmail.com> > *Date: *Thursday, 2022/10/20 at 13:03 > *To: *openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> > *Subject: *Re: Platform independent deployment > > Correct me if I'm wrong, but all the classes in the artifacts for win, > linux and mac are actually exactly the same -- this is Java code after > all, why would all Java classes for a platform be platform specific? It > doesn't matter which one is packaged. The platform specific stuff lives > in the native libraries -- my shaded jar just includes all of them for > all platforms (dll for windows, so for linux, dylib for mac). I'm > pretty sure I used this exact same jar to run my software on windows and > linux. Never tested mac as I don't own one. > > My pom therefore includes all three, like Nir Lisker has, and my shaded > artifact just packages them all (I get a lot of warnings about duplicate > classes, but those can just be ignored). > > --John > > On 20/10/2022 19:03, Thomas Reinhardt wrote: > > > > Hi Nir, > > > > Does not work (I testet it) and it can not work (see below). > > > > Also, this is exactly what my naive test was (I did not use maven to > > copy the artifacts, but the result obviously is the same). > > > > It can not work as the implementation classes have the same name and > > thus the jre can not distinguish which one to load. For example both > > javafx-web-18-win and javafx-web-18-linux define a class > > "javafx.scene.web.WebEngine". From the jre's point of view they are > > the same. > > > > What would be needed is > > > > Either: a class "javafx.scene.web.WebEngine" that is only a thin > > wrapper to javafx.scene.web.linux.WebEngine. > > > > Or: a class that loads only one of the implementations during > > application startup (technically it could load both implementations > > with different classloaders, but lets not go there). > > > > There might be other solutions but I am not aware of any. > > > > > > I was looking for a help forum but did only find the #introduction > > link you mentioned. > > > > > > -Thomas > > > > > > > > On 20/10/2022 17:52, Nir Lisker wrote: > >> Hi Thomas, > >> > >> Did you try to just specify the platform-specific dependencies in the > >> POM? > >> > >> <dependency> > >> <groupId>org.openjfx</groupId> > >> <artifactId>javafx-graphics</artifactId> > >> <version>19</version> > >> <classifier>win</classifier> > >> </dependency> > >> <dependency> > >> <groupId>org.openjfx</groupId> > >> <artifactId>javafx-graphics</artifactId> > >> <version>19</version> > >> <classifier>linux</classifier> > >> </dependency> > >> <dependency> > >> <groupId>org.openjfx</groupId> > >> <artifactId>javafx-graphics</artifactId> > >> <version>19</version> > >> <classifier>mac</classifier> > >> </dependency> > >> > >> Seems more of a question for help forums, though if this information > >> is not mentioned in https://openjfx.io/openjfx-docs/#introduction > >> <https://openjfx.io/openjfx-docs/#introduction>, it might be worth > >> adding it. > >> > >> On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt > >> <thomas.reinha...@s4p.de <mailto:thomas.reinha...@s4p.de > <thomas.reinha...@s4p.de>>> wrote: > >> > >> > >> Hi! > >> > >> Apologizes if this is not the proper list to ask my question. > >> > >> For context: we are using the WebView of JavaFX in our legacy swing > >> based frontend application. For now that is the only component we > >> are > >> using but we might migrate completely at a later point in time. > >> > >> I have an issue with the way platform dependent dependencies are > >> handled. We are using maven btw. > >> My understanding is that during the build a profile is selected > >> based on > >> the host os name and architecture. That profile then sets a property > >> (javafx.platform) that is in turn used as the classifier for > >> platform > >> dependent dependencies. > >> (Offtopic to my question: eclipse warns that the profile ids are not > >> unique in the org.openjfx:javafx pom.xml). > >> > >> Which means that the result of my build is locked to a single > >> platform. > >> But we have customers for windows and linux and don't want to have > >> separate artifacts as that would mean we also have to handle that > >> distinction in our installer etc. > >> > >> I know I can override the automatically detected platform but > >> that does > >> not solve the issue. > >> > >> Ideally I would use something like -Djavafx.platform=all but that > >> does > >> not exist. > >> > >> My question is: is there an existing solution where I can just > >> include > >> all platform dependencies for say windows and linux and the runtime > >> "sorts it out"? A naive test (manual copying of artifacts) of mine > >> unfortunately failed. Of course I could just use custom classloaders > >> and > >> do it myself but I really would prefer to use an existing > >> solution and > >> not implement some workaround. > >> > >> If there is no solution (yet), is there interest in such a > >> feature? We > >> might be able to contribute to the project. > >> > >> > >> -Thomas > >> >