Platform independent deployment

[John Hendrikx]

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.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
>>