I use this in a gradle project I have and it works for me. All the OS-specific modules are packaged and I can run the app on all 3 desktop platforms.
It seems that you are doing something more special. Maybe someone else has insights. On Thu, Oct 20, 2022 at 8:03 PM Thomas Reinhardt <thomas.reinha...@s4p.de> 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>> 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 > > >
