Hi Nir,
No, it is not a "big problem", but it certainly is an annoyance. I went
from 2 dependencies that manage transitive dependencies themselves to 12
handcrafted depdendencies. I also have to manage versions for all the
platform specific artifacts by hand. That is 6 artifacts for two
platforms and most have a platform independent version also. Totalling
to 18 versions that I have to manage in my bom. All of that is "easy"
but it has to be done and clutters my poms. If we ever want to support
another os I will have to add even more noise to my poms.
As for the javafx-maven-plugin: I don't see how this would help here. It
states on the github page "JavaFX dependencies are added as usual".
Don't get me wrong, I am perfectly fine with doing it that way. But the
situation is far from easy or painless. And after a little digging I
think half of the artifacts should not have been platform dependent in
the first place:
$ diff -rq javafx-base-19-linux/ javafx-base-19-win/ | wc -l
1
$ diff -rq javafx-controls-19-linux/ javafx-controls-19-win/ | wc -l
6
$ diff -rq javafx-fxml-19-linux/ javafx-fxml-19-win/ | wc -l
0
$ diff -rq javafx-graphics-19-linux/ javafx-graphics-19-win/ | wc -l
72
$ diff -rq javafx-media-19-linux/ javafx-media-19-win/ | wc -l
13
$ diff -rq javafx-swing-19-linux/ javafx-swing-19-win/ | wc -l
0
$ diff -rq javafx-web-19-linux/ javafx-web-19-win/ | wc -l
2
javafx-base only differs in VersionInfo.class, javafx-fxml and
javafx-swing are completely identical so 3 out of 7 artifacts really
should not be platform dependent at all.
javafx-controls only differs in .bss files (binary css? interesting).
seems like a packaging artifact to me as the (corresponding?) .css files
are identical. So this artifact probably should not be platform
dependent either.
javafx-graphics differs in a handful of java classes and native
libraries of course.
javafx-media and javafx-web which differ only in native libraries.
I would really like to see the platform dependency be removed from
javafx-base, javafx-fxml, javafx-swing and javafx-controls. That would
be a big step to ease platform independent deployments.
Sorry for the big wall of text :)
-Thomas
On 21/10/2022 00:38, Nir Lisker wrote:
It doesn't look to me like a big problem, regardless of the size of the
project. You just include the modules you want depending on what your
application needs and which platforms it targets. In Gradle, it's just 2
lines of code.
There is also the JavaFX plugin that might help with this, but it's
unrelated to the development here:
Gradle variant - https://github.com/openjfx/javafx-gradle-plugin
<https://github.com/openjfx/javafx-gradle-plugin>
Maven variant - https://github.com/openjfx/javafx-maven-plugin
<https://github.com/openjfx/javafx-maven-plugin>
On Fri, Oct 21, 2022 at 1:29 AM Thomas Reinhardt
<thomas.reinha...@s4p.de <mailto:thomas.reinha...@s4p.de>> wrote:
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 <mailto:nlis...@gmail.com>>
*Sent:* 20 October 2022 23:14
*To:* Thomas Reinhardt <thomas.reinha...@s4p.de
<mailto:thomas.reinha...@s4p.de>>
*Cc:* openjfx-dev@openjdk.org <mailto:openjfx-dev@openjdk.org>
<openjfx-dev@openjdk.org <mailto: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
<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
<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>
>> <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
<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
>>
