Thanks Nir for the links to the other discussions. I got the thing to run with the simple approach of including all artifacts. Probably did miss some before but it's late in the night here :)
One thing that still bugs me is that I have to do dependency resolution manually if I want to include artifacts for different platforms. Not a huge problem but far from a perfect solution. And I can't stop to think what other big projects are doing. Apart from toy-applications that run on the development system only, everybody should have the same problems I had. Or maybe I am just the last one striving for a platform independent application. Thank you all for helping out! ________________________________ From: Nir Lisker <nlis...@gmail.com> Sent: 20 October 2022 23:14 To: Thomas Reinhardt <thomas.reinha...@s4p.de> Cc: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: Platform independent deployment 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<mailto: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<mailto:openjfx-dev-r...@openjdk.org>> on behalf of Andy Goryachev <andy.goryac...@oracle.com<mailto:andy.goryac...@oracle.com>> Sent: 20 October 2022 22:53 To: John Hendrikx <john.hendr...@gmail.com<mailto:john.hendr...@gmail.com>>; openjfx-dev@openjdk.org<mailto:openjfx-dev@openjdk.org> <openjfx-dev@openjdk.org<mailto: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<mailto:openjfx-dev-r...@openjdk.org>> on behalf of John Hendrikx <john.hendr...@gmail.com<mailto:john.hendr...@gmail.com>> Date: Thursday, 2022/10/20 at 13:03 To: openjfx-dev@openjdk.org<mailto:openjfx-dev@openjdk.org> <openjfx-dev@openjdk.org<mailto: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> >> <mailto: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 >>
