Platform independent deployment

[Nir Lisker]

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.reinhardt at 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.reinhardt at s4p.de <mailto:thomas.reinhardt at 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20221020/80715dc4/attachment.htm>