Please find my problem description for thinkorswim, which I sent to them a couple of days ago: ;----------------------------------------------------------------------------- Hello, I would like to address an issue with your tos platform and hope for a quick solution. Yesterday I downloaded tos from this page: https://mediaserver.thinkorswim.com/installer/install.html https://mediaserver.thinkorswim.com/installer/InstFiles/thinkorswim_installer.sh and installed it under Linux Fedora 20 to be specific. The installation went smoothly so far. I have chosen to install the software "for this user" and have "ameritrade" chosen from the offered brokers. I also allowed the installer to create a desktop icon. Start "tos" after installation complete. Installation path is the homedir. Now a small splash-screen popped up because tos got started. this thing informed me that it's "Installing updates...". From what I was able to see within the ~/thinkorswim directory it was downloading the update for the suit (from 1858.9 to 1864.42) and usergui (1864.54). After the downloadprocess has been completed (all files from usergui have been catched) the splash-screen keeps saying "Installing updates...". Regardless what you do, this thing is the first that shows up. Always "Installing updates...". I removed the tos directories and tried to re-install everything from scratch (all java processes including tos has been killed). Same issues. I believed that this might be an issue from the java version provided by Fedora 20 which is: java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i686 So I tried installing java-1.8.0-openjdk-1.8.0.11-9.b12.fc20 Same issues. I went to the Oracle site and downloaded the JDK package from their site and installed that one. Same issues. Rebooting the machine a couple of times and re-tried above steps under different scenarios. Same issue. The popup still says "Installing updates..." and seem to be stuck with it. Therefore I believe that this might be a software related issue. I know that tos works on this machien because I have successfully been testing it a couple of months before with a demo-account. I like to make sure that I even tried to install tos on a brand new and fresh installation of Fedora. Same issues. The logs for "suit" and "usergui" don't contain anything strange. No issues with NULL Pointer or similar breakage. To be specific: No known errors. No firewall running. No ports blocked. Please find attached a screenshot of the issue. Greets Ali Akcaagac ;----------------------------------------------------------------------------- No screenshot here. The problem is that I had issues with OpenJDK 1.7 and 1.8, then tried JDK from Oracle. Sadly it was interfering with my OpenJDK installation (which I use for development). After a while I retried JDK (better JRE) from Oracle and this thing worked. After some deeper investigation I figured out that thinkorswim requires JavaFX, which the Java Oracle Version provides. I am not sure how the license situation for JavaFX is but this is really a messy situation as it is now.
I don't think JavaFX is fully open-source yet, and there are additional issues such as the complex build system, that hinder addition to Fedora. I am adding Mario Torre to cc: as he has tried building JavaFX for Fedora before. Mario, what is the current status of OpenJFX, and what stands in the way of introducing it into Fedora?
Created attachment 940157 [details] tos-issue.png I just received a mail from tech support of the TOS platform. They suggested me to try Oracle JRE / JDK once again -> which I already figured out myself. Sadly their platform gave me issues for the entire weekend because no proper output of missing JavaFX. Also included the "screenshot". Not that it helps much.
After some digging I found this here: http://pkgs.org/fedora-centos-rhel-opensuse-mandriva/olea/java-1.7.0-oracle-javafx-1.7.0.21-1.0.cf.i586.rpm.html Which directs me to this here: http://olea.org/paquetes-rpm/repoview/letter_j.group.html http://olea.org/paquetes-rpm/repoview/java-1.7.0-oracle-javafx.html Looks like someone made *.rpm packages for exactly the missing files. Nonetheless they are somehow outdated and needs some love. What would be nice is to have something similar: java-1.7.0.xx-openjdk.rpm java-1.7.0.xx-openjdk-headless.rpm java-1.7.0.xx-openjdk-devel.rpm java-1.7.0.xx-openjdk-javafx.rpm Same for 1.8.x
It cant be done. As Deepak wrote, the javfx is not yet fully opensourced. So the FX binaries, which are in oracle java can not magically appear in openjdk packages. Once they are, I will follow the same file sorting as I'm using for Oracle java for Rhel. And so there will be java-1.8.0-javafx
RE JavaFX: We can't officially support the closed JavaFX binary, the same way as we don't offer closed JDK binary RPM in Fedora. I didn't look at the Mandriva package, but by the naming convention I think is exactly the pre-packaged version of the *closed* JavaFX that *only* works with the *closed* JDK (which is quite likely a dependency). OpenJFX is now fully open sourced, it can be compiled by yourself and should work well with the OpenJDK 8 that we ship in Fedora. However, packaging it is a different story, because it depends on Gradle that is not available in Fedora and is also specific to OpenJDK 8, although this has now been officially released so is less of a blocker. Note that the closed JavaFX '7' is not compatible with OpenJDK (so even if you just download the jar from somewhere it won't work), it does certain assumptions on the host platform and there's no easy way to make it run. Some people have done an unofficial OpenJFX fork that works with OpenJDK 7, but I don't know what the state of that. Re thinkorswim: Are you sure it needs JavaFX? By the look of it it seems like it's only using Swing (and the release notes say it requires Java 6, if this is correct it's surely not a JavaFX application). We would need a log of what's going on, but the closed nature of the application will make it quite hard to figure out what's the issue.
(In reply to Mario Torre from comment #5) > OpenJFX is now fully open sourced, it can be compiled by yourself and should > work well with the OpenJDK 8 that we ship in Fedora. However, packaging it > is a different story, because it depends on Gradle that is not available in > Fedora and is also specific to OpenJDK 8, although this has now been > officially released so is less of a blocker. Right. According to [1] Gradle has been retired in F20 and up. So it would mean to a) port OpenJFX's build to some other build system such as maven or b) unretire Gradle and maintain it. Note that Gradle has been notorious to do strange things which makes it hard to maintain[2]. Not sure how hard option b) would be. [1] https://admin.fedoraproject.org/pkgdb/package/gradle/ [2] https://lists.fedoraproject.org/pipermail/java-devel/2013-October/004979.html
(In reply to Severin Gehwolf from comment #6) > (In reply to Mario Torre from comment #5) > > OpenJFX is now fully open sourced, it can be compiled by yourself and should > > work well with the OpenJDK 8 that we ship in Fedora. However, packaging it > > is a different story, because it depends on Gradle that is not available in > > Fedora and is also specific to OpenJDK 8, although this has now been > > officially released so is less of a blocker. > > Right. According to [1] Gradle has been retired in F20 and up. So it would > mean to a) port OpenJFX's build to some other build system such as maven or > b) unretire Gradle and maintain it. Note that Gradle has been notorious to > do strange things which makes it hard to maintain[2]. Not sure how hard > option b) would be. > > [1] https://admin.fedoraproject.org/pkgdb/package/gradle/ > [2] > https://lists.fedoraproject.org/pipermail/java-devel/2013-October/004979.html The problem is also that JavaFX have been updating their gradle version a few times over their development lifetime, which makes it harder for downstream. I've been thinking to port the build infrastructure like we did for OpenJDK at the beginning. I'll meet the JavaFX people at JavaOne and see what they think about that. Moving away from Gradle would help downstream which ultimately means broather adoption of JavaFX, but I don't know if they want to go that way, given the considerable amount of effort they've been putting into the build machinery already.
(In reply to Mario Torre from comment #5) > RE JavaFX: Thanks for your feedback and the indepth explaination. > Re thinkorswim: > > Are you sure it needs JavaFX? By the look of it it seems like it's only > using Swing (and the release notes say it requires Java 6, if this is > correct it's surely not a JavaFX application). We would need a log of what's > going on, but the closed nature of the application will make it quite hard > to figure out what's the issue. Well I am not 100% sure. What I can tell is, that the thinkorswim platform used to work under Fedora 18 and OpenJDK 1.6. I abandoned the platform for a while and was using something else. Now with Fedora 20 and OpenJDK 1.7 things look different. They have changed a bunch of stuf like GUI appearance and embedded some media stuff inside the code. I spent the entire weekend to get that thing running and it only operates well with Oracles JRE/JDK. After some google I figured out that some forum people mentioned it requires features provided by JavaFX. What I could have done is this: Check all the classes for traces to JavaFX methods or class calls. I have written some code for it a couple of years ago which dives into all classes and spit out the methods to stdout. Unfortunately - and for personal reasons (also related with my former eployer) I have abandoned all my work as Java developer 2 years ago and now focus on daytrading. Life changes!
I found someone else reporting same issue: reference: http://lists.opensuse.org/opensuse/2014-06/msg00667.html ;----------------------------------------------------- java.lang.RuntimeException: Unexpected error! at com.devexperts.tos.ui.user.login.LoginDialogFXUtils.runAndWait(LoginDialogFXUtils.java:110) at com.devexperts.tos.ui.user.login.LoginDialogFX.<init>(LoginDialogFX.java:107) at com.devexperts.tos.ui.user.login.StartupUtils$3.run(StartupUtils.java:247) ;----------------------------------------------------- Looks like their login dialog depends on FX. Either this was a practical decision to style their GUI or a tactical decision to remove complexity from their technical support. Tactical decision could be to enforce Oracle Java to make sure everyone is using the same stuff, same compatibility, same output, avoid lawsuits because of lost money or something similar, avoid guiding and/or struggling through OpenJDK (problems if exist). Sadly I wasn't able to find a trace towards JavaFX within the thinkorswim logs.
Being able to use JavaFX from java apps would really be nice. netbeans uses it. jboss tools uses it. For now we are forced to recommend users to install oracle jdk if they want to benefit from it ;/
I'm taking the bug, I guess it's time to look again at integrating OpenJFX into Fedora.
I've been following this too, and I think we need a sane build for this at the distro-agnostic level. Hopefully, I'll find some time to take a look after the current security update. A glance over the existing build shows that there is native code in there, plus dependencies, which will need cleaning up.
Just lurking because I'd like to run Geogebra on free Java, but it wants JavaFX: 14:54:37.388 ERROR: geogebra.gui.Q.X[-1]: JavaFX 2.2 not available It seems to mostly run without it but I'm not familiar enough with Geogebra to know what's missing.
Hi I don't want to encourage the end users to install Oracle Java. OpenJFX is already available for Ubuntu and Debian: https://packages.qa.debian.org/o/openjfx.html What is missing to do the same for Fedora (and Mageia)? Gradle? Is it possible to build OpenJFX without Gradle? Maybe we can generate Ant or Maven scripts from Gradle scripts. I just ran "gradle init" in the directory containing the main pom file when I wanted to generate the Gradle script for a Maven project.
Severin Gehwolf's suggestion might be viable, look at the section 47.3.1 about the conversion of an Apache Maven build to a Gradle build: http://www.gradle.org/docs/current/userguide/build_init_plugin.html
alien can be used in the meantime to convert the Debian packages into RPM packages: http://pkgs.org/fedora-20/fedora-i386/alien-8.88-4.fc20.noarch.rpm.html http://manpages.ubuntu.com/manpages/raring/en/man1/alien.1p.html Of course, it's not a clean solution.
(In reply to Julien Gouesse from comment #14) > I don't want to encourage the end users to install Oracle Java. I am the first to encourage end users to install Oracle Java. Simply because it just works and offers rpm Packages that installs clean into my Fedora 20 system. > alien can be used in the meantime to convert the Debian packages into RPM > packages: > > Of course, it's not a clean solution. Your last sentence is the right answer why I would encourage end users to do so. There are people who want to use the system and not waste too much time in administration. Oracle Java offers this out of the box as it is now.
I'm wondering how you run the stack of java applications on Oracle JDK?
(In reply to Ali Akcaagac from comment #17) > (In reply to Julien Gouesse from comment #14) > > I don't want to encourage the end users to install Oracle Java. > > I am the first to encourage end users to install Oracle Java. Simply because > it just works and offers rpm Packages that installs clean into my Fedora 20 > system. > I'm sorry, I don't want to turn this bug report into a OpenJDK vs Oracle Java debate and I have a completely different opinion about the reliability of the packages provided by Oracle/Sun Microsystems for GNU Linux in general. > > alien can be used in the meantime to convert the Debian packages into RPM > > packages: > > > > Of course, it's not a clean solution. > > Your last sentence is the right answer why I would encourage end users to do > so. There are people who want to use the system and not waste too much time > in administration. Oracle Java offers this out of the box as it is now. This bug report talks about java-1.7.0-openjdk. My suggestion has a chance to work with java-1.8.0-openjdk. OpenJFX/JavaFX will be fully integrated into Java 1.9 anyway as far as I know and no longer installed as an extension. The current situation is a bit annoying. My workaround is only a pragmatic temporary solution to go on using OpenJDK and to benefit of OpenJFX.
(In reply to jiri vanek from comment #18) > I'm wondering how you run the stack of java applications on Oracle JDK? I run a stripped down version of Fedora 20 with XFCE4 only (approx 720 packages) and install packages on demand. Rather than uninstalling everything again I usually keep a tar.bz2 of the stripped installation and untar it in a chroot and replace it with root (automated process). My demand for java is only for thinkorswim and freemind (upstream bin/tar files). No further dependencies of openjdk required. No other programs depending on java. If I'd go back using freemind from Fedora 20 repo then it starts installing the whole rattail of things I don't need. But sure I agree that a nice openjfx version is required. But for Fedora 20 I need it now with java 1.7 which is a requirement for thinkorswim. You might understand that I need some sort of reliability to run my business. I can't rely on openjdk 1.7 without openjfx support. Nor do I want to install openjdk 1.8 when it's clearly stated that thinkorswim mandatory says 1.7. So all it does is running X, XFCE, Java, ThinkOrSwim. The rest is &> /dev/null
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Resetting component to java-1.8.0-openjdk since there is no java-1.7.0-openjdk in F22.
*** Bug 1234168 has been marked as a duplicate of this bug. ***
Gradle 2.2 is now available in Fedora 22, with Gradle 2.4 in rawhide. We (Gradle maintainers) can help porting OpenJFX build scripts from Gradle 1.x to 2.x
I just created a COPR repository to host a package for OpenJFX. It's using Gradle 1.8 so this particular version is included in the SRPM. See here: https://copr.fedoraproject.org/coprs/gferon/openjfx/
Thank you Gabriel for copr repository. I at least got the jar file running on Fedora 22. But the jar application that I got is having button to add new row in the form for adding additional information. When I click on it, jar file application crashes with error java: symbol lookup error: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.45-40.b14.fc22.x86_64/jre/lib/amd64/libjfxwebkit.so: undefined symbol: _ZN3JSC8JSObject45putByIndexBeyondVectorLengthWithoutAttributesILh20EEEvPNS_9ExecStateEjNS_7JSValueE
Seems to be an issue with GCC 5 / Webkit (see here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292) I'll try to find a way around this bug in a week or so, either by compiling libjfxwebkit with an earlier GCC version, or by applying the CPP patch to Webkit before compiling the library.
I've ported OpenJFX build script to latest Gradle and built it in offline mode. The results are at https://github.com/mizdebsk/newpkg/tree/openjfx See also: https://lists.fedoraproject.org/pipermail/java-devel/2015-July/005635.html
Mikolaj do you have copr or other repo for such builds?
(In reply to Pavel Alexeev from comment #29) > Mikolaj do you have copr or other repo for such builds? No, because my build was proof of concept only - it was never meant to be used.
Could we get something from https://wiki.openjdk.java.net/display/OpenJFX/Community+Builds into Fedora? This status quo while Fedora is trying to get developer minds is really bad IMHO.
Are you going to package OpenJFX to some Fedora release?
(In reply to Jiri Konecny from comment #32) > Are you going to package OpenJFX to some Fedora release? We are investigating this possibility.
Missing OpenJFX also prevents MediathekView¹ from running. Any update on this? ¹ http://zdfmediathk.sourceforge.net/
Needed OpenJFX package for Fedora 24 too. Please, add it. Ubuntu 16.04 already have OpenJFX packages in repository.
(In reply to Marek Novotny from comment #31) > Could we get something from > https://wiki.openjdk.java.net/display/OpenJFX/Community+Builds into Fedora? > > This status quo while Fedora is trying to get developer minds is really bad > IMHO. I am asking the same T.T
(In reply to Vitaliy Gribko from comment #35) > Needed OpenJFX package for Fedora 24 too. > > Please, add it. Ubuntu 16.04 already have OpenJFX packages in repository. You're welcome to contribute :) Regarding Ubuntu, I didn't try the Ubuntu packages in a while, but last time I checked they were not complete. Unfortunately we need some extra deps to get the full build of OpenJFX, it doesn't make a lot of sense to have a package that is half working. It also requires a lot of collaboration to ensure that the latest security updates are delivered efficiently, not to speak about the fact that OpenJFX depends on a specific version of OpenJDK, so we need to make this package a subpackage of OpenJDK, which is not really a good idea. It makes more sense for users to build it themeselves and use whatever bits they need instead. Building JavaFX is very easy.
Looking at the repositories, you'd probably need to branch your own repository before even making a start, as there is no tree matching the current release, or at least be very careful to bundle the right tag. At present, the OpenJFX which matches java-1.8.0-openjdk would be the tag http://hg.openjdk.java.net/openjfx/8u/rt/rev/10037acb5c7a, not the tip of that repository. We have the same issue with OpenJDK 8u upstream, and aarch64/jdk8u (OpenJDK 8u + AArch64 port) follows release tags rather than pulling the whole of 8u.
Thank you for this precision regarding the right tag! I guess I'll adapt the spec file I wrote nearly a year ago and try publishing a fully working package on COPR again. (this is the spec file I wrote at the time https://raw.githubusercontent.com/gferon/openjfx-fedora/master/openjfx.spec)
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Any news on this? Where is the testpackage?
I'm trying to install TD Ameritrade's Think-or-Swim trading program on my Fedora workstation and ran into the same problem as the OP. After the "installing updates" dialog, the installer dies with this error message: Missing JavaFX in Java Please set Oracle Java 8 as default java for thinkorswim Java must include JavaFX and Oracle Java 8 has it, but OpenJDK 8 has not. TD's tech support says I should switch to Ubunutu because it "works fine" there (haha, that's not going to happen!) :) Any chance we'll have a fix or work-around for this in the near future? Or has anyone figured out a way to make it work? I'm not a Java person, so I don't quite grok the difference between OpenJDK, JavaFX, and Java. Is there a different Java package I can install via dnf that will fix this?
(In reply to Steevithak from comment #42) > Any chance we'll have a fix or work-around for this in the near future? Or has anyone figured out a way to make it work? There are experimental builds. Just have a look at the github URLs above. > I'm not a Java person, so I don't quite grok the difference between OpenJDK, JavaFX, and Java. OpenJDK is the reference implementation for the Java standard library. JavaFX is an additional library with a referenence implementation (OpenJFX) inside the OpenJDK, but it is > Is there a different Java package I can install via dnf that will fix this? You could download the oracle java bundle from https://www.java.com/en/download/linux_manual.jsp , which has no support from Fedora. This is the implementation of Java from Oracle, the main developer of Java, mostly identical to OpenJDK. It might contain some proprietary code (did so in the past). It misses a few patches OpenJDK has on Fedora: https://src.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/
I've manually updated the spec from https://github.com/gferon/openjfx-fedora/ to 8u111_b14. Build itself seems to run fine but then finally fails for me with: cp -f generated/InspectorJSFrontendDispatchers.h cp -f generated/InspectorJSBackendDispatchers.h cp -f generated/InspectorJSTypeBuilders.h cp: missing destination file operand after 'generated/InspectorJSFrontendDispatchers.h' Try 'cp --help' for more information. cp: missing destination file operand after 'generated/InspectorJSBackendDispatchers.h' Try 'cp --help' for more information. cp: missing destination file operand after 'generated/InspectorJSTypeBuilders.h' Try 'cp --help' for more information. Since the build went fine I expect that's a minor glitch? (which I just didn't yet figure out how to fix) It would be great to get that build working again. I expect we're 90% there already?
This is exactly the error that stopped me from updating the SPEC file I wrote a while ago... You can build without Webkit support in the meantime by setting COMPILE_WEBKIT = false. I already disabled media support a few months ago because it requires libraries only available in RPMfusion.
I've tried that. But that build again fails for me. Maybe somebody knows more about that building-process.
This may be a dumb question but if this is already fixed on Ubuntu (according to TD, think-or-swim runs on the current Ubuntu version), wouldn't it be possible for Fedora developers to have a peek at how Ubuntu got JavaFX compiling/working and copy those changes over to Fedora's Java code? Also, thanks for the suggestions on how I could get this running but I rely on my Fedora box for work, so I'm not thrilled with the idea of replacing the supported version of java with a new one I download and compile myself. I'm afraid that I might break something important. I'm content to wait for the next rev of Fedora if necessary.
I need openjfx for bitsquare
(In reply to Steevithak from comment #47) > This may be a dumb question but if this is already fixed on Ubuntu > (according to TD, think-or-swim runs on the current Ubuntu version), > wouldn't it be possible for Fedora developers to have a peek at how Ubuntu > got JavaFX compiling/working and copy those changes over to Fedora's Java > code? > > Also, thanks for the suggestions on how I could get this running but I rely > on my Fedora box for work, so I'm not thrilled with the idea of replacing > the supported version of java with a new one I download and compile myself. > I'm afraid that I might break something important. I'm content to wait for > the next rev of Fedora if necessary. Debian has got openjfx package with JavaFX build which is their take on this and Ubuntu usually picks over from Debian testing repositories.
Gabriel, how far are you with attempt to include this to main repositories?
I'll try a new build very soon and fix the Webkit compilation but AFAIK, media support will still be lacking because Fedora doesn't include ffmpeg. It's possible to build a meta-package and only publish this on a 3rd-party repository though, as it simply produces a bunch of additional static libraries.
I updated the spec file made by Mikolaj Izdebski to latest version of openjfx: https://jonny.fedorapeople.org/openjfx.spec One question: Where should the files go? The current .spec puts the files in /usr/lib/jvm/openjfx, but as my understanding it should be inside $JAVA_HOME, but that will cause problems when upgrading the openjdk package.
(In reply to Jonny Heggheim from comment #52) > I updated the spec file made by Mikolaj Izdebski to latest version of > openjfx: https://jonny.fedorapeople.org/openjfx.spec > > One question: Where should the files go? The current .spec puts the files in > /usr/lib/jvm/openjfx, but as my understanding it should be inside > $JAVA_HOME, but that will cause problems when upgrading the openjdk package. Yes, please don't put things in $JAVA_HOME. The way I suggest to solve the need for the jfxrt.jar to be in the ext directory of $JAVA_HOME is similar to what we do with the accessibility toolkit, that is a package that is part of the openjdk distribution that creates the necessary symlinks at every update.
(In reply to Mario Torre from comment #53) > Yes, please don't put things in $JAVA_HOME. The way I suggest to solve the > need for the jfxrt.jar to be in the ext directory of $JAVA_HOME is similar > to what we do with the accessibility toolkit, that is a package that is part > of the openjdk distribution that creates the necessary symlinks at every > update. Sounds like a good solution. What is the package name of the accessibility toolkit?
(In reply to Jonny Heggheim from comment #54) > (In reply to Mario Torre from comment #53) > > Yes, please don't put things in $JAVA_HOME. The way I suggest to solve the > > need for the jfxrt.jar to be in the ext directory of $JAVA_HOME is similar > > to what we do with the accessibility toolkit, that is a package that is part > > of the openjdk distribution that creates the necessary symlinks at every > > update. > > Sounds like a good solution. What is the package name of the accessibility > toolkit? java-atk-wrapper. Required directly from java-1.8.0-openjdk-accessibility (a sub-package of java-1.8.0-openjdk[1]). [1] http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec#n1168
Thanks
Yes. I will be happy to add those links to java8 packages.
(In reply to jiri vanek from comment #57) > Yes. I will be happy to add those links to java8 packages. Great to hear!
Good news, I installed openjfx from the RPM into /usr/lib/jvm/openjfx, made links into the openjdk JRE and JDK and was able to build ReactFX and run the sample application. I will do some more cleanup and include documentation and soon publish the SRPM. [1] https://github.com/TomasMikula/ReactFX
Cool, that sounds good! So will this fix be added to Fedora 25 or will we need to wait until F26 to see it?
(In reply to Steevithak from comment #60) > So will this fix be added to Fedora 25 or will we > need to wait until F26 to see it? My goal is to get it working on Fedora 25
Not ready for review yet, but here is an updated version, it includes a README.fedora for how to create the symlinks for the JDK and JRE. Spec: https://jonny.fedorapeople.org/openjfx.spec SRPM: https://jonny.fedorapeople.org/openjfx-8.0.152-1.b00.fc25.src.rpm Please give feedback and patches.
How does one build this package?
(In reply to Christian Stadelmann from comment #63) > How does one build this package? Install mock, download the package and run this command: mock --rebuild openjfx-8.0.152-1.b00.fc25.src.rpm I also uploaded a x86_64 build in case you do not want to build it yourself: https://jonny.fedorapeople.org/openjfx-8.0.152-1.b00.fc25.x86_64.rpm
/usr/share/doc/openjfx/README.fedora contains the last steps to get it working, these should be done in a openjdk sub-package
(In reply to Jonny Heggheim from comment #64) > (In reply to Christian Stadelmann from comment #63) > > How does one build this package? > > Install mock, download the package and run this command: > mock --rebuild openjfx-8.0.152-1.b00.fc25.src.rpm > > I also uploaded a x86_64 build in case you do not want to build it yourself: > https://jonny.fedorapeople.org/openjfx-8.0.152-1.b00.fc25.x86_64.rpm Could you create COPR repository with your changes?
Great. Installing the binary package and simply running the lines from README.fedora worked out of the box. With this I got a previouly not running tool working fine (MediathekView) which requires openjfx.
(In reply to Stefan Neufeind from comment #67) > Great. Installing the binary package and simply running the lines from > README.fedora worked out of the box. With this I got a previouly not running > tool working fine (MediathekView) which requires openjfx. Confirmed. @Jonny Heggheim: Thank you. I couldn't spot any issues.
Glad to hear that it work with real applications, I will have a look into COPR.
(In reply to Marek Novotny from comment #66) > Could you create COPR repository with your changes? Hope it work, will build new updates here: https://copr.fedorainfracloud.org/coprs/jonny/openjfx/
Thanks Jonny for copr. Package installation from copr repository works like a charm. One additional comment to manual creation of symlinks in README.fedora. I am on fedora 25 and there is java installed in /usr/lib/jvm/java-openjdk directory or in java-1.8.0-openjdk* directories instead of /usr/lib/jvm/java and the same apply to jre, where it is in /usr/lib/jvm/jre-openjdk instead of /usr/lib/jvm/jre
All these folders on my Fedora 25 installation are symlinks to the same JDE/JRE folders. $ tree -L 1 /usr/lib/jvm /usr/lib/jvm ├── java -> /etc/alternatives/java_sdk ├── java-1.8.0 -> /etc/alternatives/java_sdk_1.8.0 ├── java-1.8.0-openjdk -> /etc/alternatives/java_sdk_1.8.0_openjdk ├── java-1.8.0-openjdk-1.8.0.111-4.b16.fc25.x86_64 ├── java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 ├── java-openjdk -> /etc/alternatives/java_sdk_openjdk ├── jre -> /etc/alternatives/jre ├── jre-1.8.0 -> /etc/alternatives/jre_1.8.0 ├── jre-1.8.0-openjdk -> /etc/alternatives/jre_1.8.0_openjdk ├── jre-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 -> java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64/jre ├── jre-openjdk -> /etc/alternatives/jre_openjdk └── openjfx The /etc/alternatives/ symlinks also points to the same JDK/JRE folder. In the future it will be the openjdk subpackage that will take care of adding the correct symlinks. These manual made links today will be invalid after upgrade/downgrade of JDK/JRE. That will not be the case of a subpackage.
I have sent a mail to upstream: http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-January/020195.html
Generally speaking you wont me to add those symlinks to java-1.8.0-openjdk-devel /usr/lib/jvm/openjfx/bin/javafxpackager -> /usr/lib/jvm/java/bin/javafxpackager /usr/lib/jvm/openjfx/bin/javapackager -> /usr/lib/jvm/java/bin/javapackager /usr/lib/jvm/openjfx/lib/javafx-mx.jar -> /usr/lib/jvm/java/lib/javafx-mx.jar /usr/lib/jvm/openjfx/lib/packager.jar -> /usr/lib/jvm/java/lib/packager.jar /usr/lib/jvm/openjfx/lib/ant-javafx.jar -> /usr/lib/jvm/java/lib/ant-javafx.jar and those symlinks to java-1.8.0-openjdk (not headless) /usr/lib/jvm/openjfx/rt/lib/jfxswt.jar -> /usr/lib/jvm/jre/lib/jfxswt.jar /usr/lib/jvm/openjfx/rt/lib/ext/jfxrt.jar -> /usr/lib/jvm/jre/lib/ext/jfxrt.jar /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_es2.so -> /usr/lib/jvm/jre/lib/amd64/libprism_es2.so /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_common.so -> /usr/lib/jvm/jre/lib/amd64/libprism_common.so /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font.so -> /usr/lib/jvm/jre/lib/amd64/libjavafx_font.so /usr/lib/jvm/openjfx/rt/lib/amd64/libdecora_sse.so -> /usr/lib/jvm/jre/lib/amd64/libdecora_sse.so /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_freetype.so -> /usr/lib/jvm/jre/lib/amd64/libjavafx_font_freetype.so /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_sw.so -> /usr/lib/jvm/jre/lib/amd64/libprism_sw.so /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_pango.so -> /usr/lib/jvm/jre/lib/amd64/libjavafx_font_pango.so /usr/lib/jvm/openjfx/rt/lib/amd64/libglass.so -> /usr/lib/jvm/jre/lib/amd64/libglass.so /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_iio.so -> /usr/lib/jvm/jre/lib/amd64/libjavafx_iio.so /usr/lib/jvm/openjfx/rt/lib/javafx.properties -> /usr/lib/jvm/jre/lib/javafx.properties where /usr/lib/jvm/openjfx is contract we will have, /usr/lib/jvm/{jre,java} is my "private path", and the lists are subject of occasional bug/ping/email right? I will be happy to include those links to opanjdk packages in rawhide once official review starts. Thoughts?
s/->/<-/g
(In reply to Jonny Heggheim from comment #72) > All these folders on my Fedora 25 installation are symlinks to the same > JDE/JRE folders. > > $ tree -L 1 /usr/lib/jvm > /usr/lib/jvm > ├── java -> /etc/alternatives/java_sdk > ├── java-1.8.0 -> /etc/alternatives/java_sdk_1.8.0 > ├── java-1.8.0-openjdk -> /etc/alternatives/java_sdk_1.8.0_openjdk > ├── java-1.8.0-openjdk-1.8.0.111-4.b16.fc25.x86_64 > ├── java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 > ├── java-openjdk -> /etc/alternatives/java_sdk_openjdk > ├── jre -> /etc/alternatives/jre > ├── jre-1.8.0 -> /etc/alternatives/jre_1.8.0 > ├── jre-1.8.0-openjdk -> /etc/alternatives/jre_1.8.0_openjdk > ├── jre-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 -> > java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64/jre > ├── jre-openjdk -> /etc/alternatives/jre_openjdk > └── openjfx > > The /etc/alternatives/ symlinks also points to the same JDK/JRE folder. > > In the future it will be the openjdk subpackage that will take care of > adding the correct symlinks. These manual made links today will be invalid > after upgrade/downgrade of JDK/JRE. That will not be the case of a > subpackage. My point is that I don't have these jre and java in /usr/lib/jvm directory. I installed openjdk 8 with standard way through dnf ;) So even later manual installation of symlinks will be done automatically, now some users need to be notified about this potential issue. My content is: tree -L 1 /usr/lib/jvm /usr/lib/jvm ├── java-1.8.0 -> /etc/alternatives/java_sdk_1.8.0 ├── java-1.8.0-openjdk -> /etc/alternatives/java_sdk_1.8.0_openjdk ├── java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.x86_64 ├── java-1.8.0-openjdk-1.8.0.111-4.b16.fc25.x86_64 ├── java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 ├── java-openjdk -> /etc/alternatives/java_sdk_openjdk ├── jre-1.8.0 -> /etc/alternatives/jre_1.8.0 ├── jre-1.8.0-openjdk -> /etc/alternatives/jre_1.8.0_openjdk ├── jre-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 -> java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64/jre ├── jre-openjdk -> /etc/alternatives/jre_openjdk └── openjfx
(In reply to jiri vanek from comment #74) > Generally speaking you wont me to add those symlinks to > java-1.8.0-openjdk-devel > > /usr/lib/jvm/openjfx/bin/javafxpackager -> > /usr/lib/jvm/java/bin/javafxpackager > /usr/lib/jvm/openjfx/bin/javapackager -> /usr/lib/jvm/java/bin/javapackager > /usr/lib/jvm/openjfx/lib/javafx-mx.jar -> /usr/lib/jvm/java/lib/javafx-mx.jar > /usr/lib/jvm/openjfx/lib/packager.jar -> /usr/lib/jvm/java/lib/packager.jar > /usr/lib/jvm/openjfx/lib/ant-javafx.jar -> > /usr/lib/jvm/java/lib/ant-javafx.jar > > > and those symlinks to java-1.8.0-openjdk (not headless) > > /usr/lib/jvm/openjfx/rt/lib/jfxswt.jar -> /usr/lib/jvm/jre/lib/jfxswt.jar > /usr/lib/jvm/openjfx/rt/lib/ext/jfxrt.jar -> > /usr/lib/jvm/jre/lib/ext/jfxrt.jar > /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_es2.so -> > /usr/lib/jvm/jre/lib/amd64/libprism_es2.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_common.so -> > /usr/lib/jvm/jre/lib/amd64/libprism_common.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font.so -> > /usr/lib/jvm/jre/lib/amd64/libjavafx_font.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libdecora_sse.so -> > /usr/lib/jvm/jre/lib/amd64/libdecora_sse.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_freetype.so -> > /usr/lib/jvm/jre/lib/amd64/libjavafx_font_freetype.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_sw.so -> > /usr/lib/jvm/jre/lib/amd64/libprism_sw.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_pango.so -> > /usr/lib/jvm/jre/lib/amd64/libjavafx_font_pango.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libglass.so -> > /usr/lib/jvm/jre/lib/amd64/libglass.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_iio.so -> > /usr/lib/jvm/jre/lib/amd64/libjavafx_iio.so > /usr/lib/jvm/openjfx/rt/lib/javafx.properties -> > /usr/lib/jvm/jre/lib/javafx.properties > > where /usr/lib/jvm/openjfx is contract we will have, > /usr/lib/jvm/{jre,java} is my "private path", and the lists are subject of > occasional bug/ping/email > > right? > > I will be happy to include those links to opanjdk packages in rawhide once > official review starts. Thoughts? I would advice against doing so, we should have a separate optional package that adds those symlinks. We can't guarantee at this stage that security updates for OpenJFX will be issued timely with the OpenJDK updates, so we can't enable access to OpenJFX by default. User need to specifically install that and should be entirely optional.
(In reply to Marek Novotny from comment #76) > My point is that I don't have these jre and java in /usr/lib/jvm directory. > I installed openjdk 8 with standard way through dnf ;) So even later manual > installation of symlinks will be done automatically, now some users need to > be notified about this potential issue. > > My content is: > tree -L 1 /usr/lib/jvm > /usr/lib/jvm > ├── java-1.8.0 -> /etc/alternatives/java_sdk_1.8.0 > ├── java-1.8.0-openjdk -> /etc/alternatives/java_sdk_1.8.0_openjdk > ├── java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.x86_64 > ├── java-1.8.0-openjdk-1.8.0.111-4.b16.fc25.x86_64 > ├── java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 > ├── java-openjdk -> /etc/alternatives/java_sdk_openjdk > ├── jre-1.8.0 -> /etc/alternatives/jre_1.8.0 > ├── jre-1.8.0-openjdk -> /etc/alternatives/jre_1.8.0_openjdk > ├── jre-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 -> > java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64/jre > ├── jre-openjdk -> /etc/alternatives/jre_openjdk > └── openjfx Hmm.. strange, I am not sure who created by jre and java symlinks in the /usr/lib/jvm.
(In reply to Mario Torre from comment #77) > I would advice against doing so, we should have a separate optional package > that adds those symlinks. We can't guarantee at this stage that security > updates for OpenJFX will be issued timely with the OpenJDK updates, so we > can't enable access to OpenJFX by default. User need to specifically install > that and should be entirely optional. I think that is the plan, a separate optional sub-package that adds the correct requires and includes symlinks for that specific JRE/JDK.
(In reply to jiri vanek from comment #74) > Generally speaking you wont me to add those symlinks to > java-1.8.0-openjdk-devel. I assume you mean: want > /usr/lib/jvm/openjfx/bin/javafxpackager -> > /usr/lib/jvm/java/bin/javafxpackager > /usr/lib/jvm/openjfx/bin/javapackager -> /usr/lib/jvm/java/bin/javapackager > /usr/lib/jvm/openjfx/lib/javafx-mx.jar -> /usr/lib/jvm/java/lib/javafx-mx.jar > /usr/lib/jvm/openjfx/lib/packager.jar -> /usr/lib/jvm/java/lib/packager.jar > /usr/lib/jvm/openjfx/lib/ant-javafx.jar -> > /usr/lib/jvm/java/lib/ant-javafx.jar Yes, and destination should be the absolute path of that specific JDK. > and those symlinks to java-1.8.0-openjdk (not headless) > > /usr/lib/jvm/openjfx/rt/lib/jfxswt.jar -> /usr/lib/jvm/jre/lib/jfxswt.jar > /usr/lib/jvm/openjfx/rt/lib/ext/jfxrt.jar -> > /usr/lib/jvm/jre/lib/ext/jfxrt.jar > /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_es2.so -> > /usr/lib/jvm/jre/lib/amd64/libprism_es2.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_common.so -> > /usr/lib/jvm/jre/lib/amd64/libprism_common.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font.so -> > /usr/lib/jvm/jre/lib/amd64/libjavafx_font.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libdecora_sse.so -> > /usr/lib/jvm/jre/lib/amd64/libdecora_sse.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_freetype.so -> > /usr/lib/jvm/jre/lib/amd64/libjavafx_font_freetype.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_sw.so -> > /usr/lib/jvm/jre/lib/amd64/libprism_sw.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_pango.so -> > /usr/lib/jvm/jre/lib/amd64/libjavafx_font_pango.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libglass.so -> > /usr/lib/jvm/jre/lib/amd64/libglass.so > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_iio.so -> > /usr/lib/jvm/jre/lib/amd64/libjavafx_iio.so > /usr/lib/jvm/openjfx/rt/lib/javafx.properties -> > /usr/lib/jvm/jre/lib/javafx.properties Yes, and destination should be the absolute path of that specific JRE. > where /usr/lib/jvm/openjfx is contract we will have, I continued to use /usr/lib/jvm/openjfx in my SPEC file, but this should be changed if others have better suggestions. It could be that a openjfxdir RPM macro would fit better as a contract. > /usr/lib/jvm/{jre,java} is my "private path", and the lists are subject of > occasional bug/ping/email > > right? Yes, openjfx will not know where or what JRE/JDKs are installed. > I will be happy to include those links to opanjdk packages in rawhide once > official review starts. Thoughts? As Miro Torre pointed out, these links should be owned/made by an optional sub-package.
(In reply to Jonny Heggheim from comment #80) > (In reply to jiri vanek from comment #74) > > Generally speaking you wont me to add those symlinks to > > java-1.8.0-openjdk-devel. > > I assume you mean: want sure > > > /usr/lib/jvm/openjfx/bin/javafxpackager -> ... > > /usr/lib/jvm/java/lib/ant-javafx.jar > > Yes, and destination should be the absolute path of that specific JDK. sure > > > > and those symlinks to java-1.8.0-openjdk (not headless) > > > > /usr/lib/jvm/openjfx/rt/lib/jfxswt.jar -> /usr/lib/jvm/jre/lib/jfxswt.jar ... > > /usr/lib/jvm/jre/lib/amd64/libglass.so > > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_iio.so -> > > /usr/lib/jvm/jre/lib/amd64/libjavafx_iio.so > > /usr/lib/jvm/openjfx/rt/lib/javafx.properties -> > > /usr/lib/jvm/jre/lib/javafx.properties > > Yes, and destination should be the absolute path of that specific JRE. sure > > > > where /usr/lib/jvm/openjfx is contract we will have, > > I continued to use /usr/lib/jvm/openjfx in my SPEC file, but this should be > changed if others have better suggestions. It could be that a openjfxdir RPM > macro would fit better as a contract. I think it is good decision. %{_jvmdir} is already existing macro of /usr/lib/jvm. I would stcik on that. So the contract really is only openjfx (which I see as good), and be sure I will use the macro. Or is there any other macro you would like to see? There is no other java macro for destination then _jvmdir whcih I'm aware about. The new macro you would like to introduce is competently another story (and chapter) > > > /usr/lib/jvm/{jre,java} is my "private path", and the lists are subject of > > occasional bug/ping/email > > > > right? > > Yes, openjfx will not know where or what JRE/JDKs are installed. oook! > > > I will be happy to include those links to opanjdk packages in rawhide once > > official review starts. Thoughts? > > As Miro Torre pointed out, these links should be owned/made by an optional > sub-package. I don't agree 100% with the statements but I will do it in this way. Mario is more aware about javafx internals then me, and you seems to agree so lets it happen.
Are there any news in the meantime?
My email provider (sigaint.org) went down before my holiday. I am back home in the end of March, my plan is to submit a review request when I am back
Review request is made in bug 1145303
(In reply to Jonny Heggheim from comment #84) > Review request is made in bug 1145303 Ups, this is the correct bug 1438673
Delegating being able to actually *use* OpenJFX to a not-yet-developed optional sub-package seems a bit dubious and user-unfriendly. Note that Oracle releases JavaFX with the same "release-train" as JavaSE, so JavaFX releases are tied to a specific JavaSE release. I'm unclear on the problem we're actually trying to solve. What breaks if we just install openjfx in the same directories as we install 'java'? What kind of "multiple parallel installations of Java" are we trying to support? Alternate Java VM an releases from IBM or Azul? If anyone needs using multiple installed jvms from different suppliers along with a single installation of JavaFX, that needs to be justified and tested. Otherwise, it seems like needless generality. Do these multiple parallel installations of Java each need their own 'ext' directory? If not, perhaps we could have 'ext' be a link to a common location, and we could we install openjfx there. If we do need to split "openjfx" and "openjfx-links" into separate packages, I suggest a renaming. Just like users install the 'java' and 'javac' packages (and not the 'openjdk' package), perhaps the user-visible package should be 'javafx'. The 'javafx' packages would require openjfx *and* set up the needed links.
(In reply to Per Bothner from comment #86) > Delegating being able to actually *use* OpenJFX to a not-yet-developed > optional sub-package seems a bit dubious and user-unfriendly. Note that > Oracle releases JavaFX with the same "release-train" as JavaSE, so JavaFX > releases are tied to a specific JavaSE release. > > I'm unclear on the problem we're actually trying to solve. What breaks if we > just install openjfx in the same directories as we install 'java'? It's not about having multiple version at the same time, but it's about releasing OpenJFX when a security update of OpenJDK is released. In a perfect world, we would be able to update, for each OpenJDK, to the parallel OpenJFX version at the same time as either one is released. In the current situation we are forced to have them updated separately. Also, OpenJFX is a work in progress. For those reasons it needs to be an opt in and we can't make OpenJDK depend on OpenJFX. Cheers, Mario
(In reply to Per Bothner from comment #86) > Delegating being able to actually *use* OpenJFX to a not-yet-developed > optional sub-package seems a bit dubious and user-unfriendly. Note that > Oracle releases JavaFX with the same "release-train" as JavaSE, so JavaFX > releases are tied to a specific JavaSE release. Lets they do what they do. Their jdk is statically linked and although based on openjdk, have complete different release cycle. You can see it already from build scripts and repos - javafx *is* different product. The necessity of exactly same jdk as used during build durin during runtime wasnot yet proved, so hopefully javafx will need much less updates then jdk itself. > > I'm unclear on the problem we're actually trying to solve. What breaks if we > just install openjfx in the same directories as we install 'java'? What kind > of "multiple parallel installations of Java" are we trying to support? > Alternate Java VM an releases from IBM or Azul? If anyone needs using Nope. We are shipping openjdk 8. From copr is shippable jdk7 and 6, and from f27 there will be jdk9 as techpreview. So the need of parallel jdks starts here. Another point is parallel existence of same jdk on system. We found that some really tricky bugs may appear by adding single patch to spec. It happens rarely, but when it does it is really tricky to solve. To have some help here from reporter, we shep debug subpakcages, which have same (binary identical) buildroot and are actually the seaprate, parallel JDK. Last result with same reason is allow the affected system to have two (or more) jdks, just with single patch difference and allow simple switching or using exact one. Maybe this do not help you, but is helping many others. Anyway single-vm (==majority) of users should not even notice. > multiple installed jvms from different suppliers along with a single > installation of JavaFX, that needs to be justified and tested. Otherwise, > it seems like needless generality. I'm personally against the symlink subpackage. But will do what will serve best. > > Do these multiple parallel installations of Java each need their own 'ext' > directory? If not, perhaps we could have 'ext' be a link to a common > location, and > we could we install openjfx there. > > If we do need to split "openjfx" and "openjfx-links" into separate packages, > I suggest a renaming. Just like users install the 'java' and 'javac' > packages (and not the 'openjdk' package), perhaps the user-visible package > should be 'javafx'. The 'javafx' packages would require openjfx *and* set > up the needed links. Something like that... Jsut maybe without depends, just with recommends... Still I hope that dangling symlinks from jdk will serve enough.
(In reply to Mario Torre from comment #87) > It's not about having multiple version at the same time, Presumably it is, otherwise you wouldn't need the complex layout of version-numbered directories and symlinks. Regardless how it's done internally, all I care is that I should be able to 'dnf install javafx' (or similar) and it it Just Work. Until we have that, it's limited what reviewing is possible.
(In reply to Per Bothner from comment #89) > Presumably it is, otherwise you wouldn't need the complex layout of > version-numbered directories and symlinks. I love simple solutions and want to avoid adding complexity. But OpenJFX have made it hard for us to package for Fedora, I hope that they will make it easier for Java 9 with the more modular system. > Regardless how it's done internally, all I care is that I should be able to > 'dnf install javafx' (or similar) and it it Just Work. Until we have that, > it's limited what reviewing is possible. I agree, we improve this by better naming (or provides). My understanding is that the current naming for openjdk8 is like this: * java-1.8.0-openjdk-openjfx (symlinks and requires on openjfx) * openjfx (.jar and .so files) We fail to provide user friendly packages if the end user only install the openjfx package and not the java-1.8.0-openjdk-openjfx. Suggestions: * Adding a prefix and/or suffix to the openjfx package * Adding openjfx and/or javafx provides for the java-1.8.0-openjdk-openjfx
(In reply to Jonny Heggheim from comment #90) > My understanding is that the current naming for openjdk8 is like this: > * java-1.8.0-openjdk-openjfx (symlinks and requires on openjfx) > * openjfx (.jar and .so files) > > We fail to provide user friendly packages if the end user only install the > openjfx package and not the java-1.8.0-openjdk-openjfx. > > Suggestions: > * Adding a prefix and/or suffix to the openjfx package > * Adding openjfx and/or javafx provides for the java-1.8.0-openjdk-openjfx The raw openjfx should be named something "unfriendly". Perhaps "openjfx-core" or "openjfx-base". Based on some quick experiments, it looks like "jre", "java", "javac", and "java-openjdk" are all synonyms for java-1.8.0-openjdk. Perhaps "javafx" and "java-openjfx" would be good aliases for java-1.8.0-openjdk-openjfx.
(In reply to Per Bothner from comment #91) > (In reply to Jonny Heggheim from comment #90) > > My understanding is that the current naming for openjdk8 is like this: > > * java-1.8.0-openjdk-openjfx (symlinks and requires on openjfx) > > * openjfx (.jar and .so files) > > > > We fail to provide user friendly packages if the end user only install the > > openjfx package and not the java-1.8.0-openjdk-openjfx. > > > > Suggestions: > > * Adding a prefix and/or suffix to the openjfx package > > * Adding openjfx and/or javafx provides for the java-1.8.0-openjdk-openjfx > > The raw openjfx should be named something "unfriendly". Perhaps > "openjfx-core" or "openjfx-base". > > Based on some quick experiments, it looks like "jre", "java", "javac", and > "java-openjdk" are all synonyms for java-1.8.0-openjdk. Perhaps "javafx" > and "java-openjfx" would be good aliases for java-1.8.0-openjdk-openjfx. nope, the way johny is suggesting should take place. Although now have feodra only one main jdk, it is not always true. User must be able to symlink openjfx form jdk he wont/needs (In reply to Jonny Heggheim from comment #90) > (In reply to Per Bothner from comment #89) > > Presumably it is, otherwise you wouldn't need the complex layout of > > version-numbered directories and symlinks. > > I love simple solutions and want to avoid adding complexity. But OpenJFX > have made it hard for us to package for Fedora, I hope that they will make > it easier for Java 9 with the more modular system. > > > > Regardless how it's done internally, all I care is that I should be able to > > 'dnf install javafx' (or similar) and it it Just Work. Until we have that, > > it's limited what reviewing is possible. > > I agree, we improve this by better naming (or provides). > > My understanding is that the current naming for openjdk8 is like this: > * java-1.8.0-openjdk-openjfx (symlinks and requires on openjfx) > * openjfx (.jar and .so files) Yes this is whats going to happen. Per, note that java-1.8.0-openjdk-openjfx will be subpackage if java-1.8.0-openjdk > > We fail to provide user friendly packages if the end user only install the > openjfx package and not the java-1.8.0-openjdk-openjfx. > > Suggestions: > * Adding a prefix and/or suffix to the openjfx package > * Adding openjfx and/or javafx provides for the java-1.8.0-openjdk-openjfx Rather provides.... Prefixes and suffixes should be kept as unused as possible...
if we look to comment #74, there is clear jre/jdk correlation. It is also the way I did it in first java-1.8.0-openjdk patch - https://bugzilla.redhat.com/show_bug.cgi?id=1438673#c29 Imho it have sense to split also openjfx package (https://bugzilla.redhat.com/show_bug.cgi?id=1438673#c26) to openjfx (where links from jre goes) and openjfx-devel into where links from jdk goes). Thoughts?
(In reply to jiri vanek from comment #81) > (In reply to Jonny Heggheim from comment #80) > > (In reply to jiri vanek from comment #74) > > > Generally speaking you wont me to add those symlinks to > > > java-1.8.0-openjdk-devel. > > > > I assume you mean: want > > sure > > > > > /usr/lib/jvm/openjfx/bin/javafxpackager -> > ... > > > /usr/lib/jvm/java/lib/ant-javafx.jar > > > > Yes, and destination should be the absolute path of that specific JDK. > > sure > > > > > > > and those symlinks to java-1.8.0-openjdk (not headless) > > > > > > /usr/lib/jvm/openjfx/rt/lib/jfxswt.jar -> /usr/lib/jvm/jre/lib/jfxswt.jar > ... > > > /usr/lib/jvm/jre/lib/amd64/libglass.so > > > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_iio.so -> > > > /usr/lib/jvm/jre/lib/amd64/libjavafx_iio.so > > > /usr/lib/jvm/openjfx/rt/lib/javafx.properties -> > > > /usr/lib/jvm/jre/lib/javafx.properties > > > > Yes, and destination should be the absolute path of that specific JRE. > > sure > > > > > > > > where /usr/lib/jvm/openjfx is contract we will have, > > > > I continued to use /usr/lib/jvm/openjfx in my SPEC file, but this should be > > changed if others have better suggestions. It could be that a openjfxdir RPM > > macro would fit better as a contract. > > I think it is good decision. > > %{_jvmdir} is already existing macro of /usr/lib/jvm. > I would stcik on that. > > So the contract really is only openjfx (which I see as good), and be sure I > will use the macro. > > Or is there any other macro you would like to see? > > There is no other java macro for destination then _jvmdir whcih I'm aware > about. > The new macro you would like to introduce is competently another story (and > chapter) > > > > > > /usr/lib/jvm/{jre,java} is my "private path", and the lists are subject of > > > occasional bug/ping/email > > > > > > right? > > > > Yes, openjfx will not know where or what JRE/JDKs are installed. > > oook! > > > > > I will be happy to include those links to opanjdk packages in rawhide once > > > official review starts. Thoughts? > > > > As Miro Torre pointed out, these links should be owned/made by an optional > > sub-package. > > > I don't agree 100% with the statements but I will do it in this way. Mario > is more aware about javafx internals then me, and you seems to agree so lets > it happen. done: https://bugzilla.redhat.com/show_bug.cgi?id=1438673#c56
openjfx-8.0.152-10.b04.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b9d1a0520b
openjfx-8.0.152-10.b04.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-2f213a60e5
openjfx-8.0.152-10.b04.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-2f213a60e5
I am not sure what versions of Fedora we should support, it might be a good idea to introduce it into Fedora 26, that way there will be some extra PR.
openjfx-8.0.152-10.b04.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b9d1a0520b
(In reply to Jonny Heggheim from comment #98) > I am not sure what versions of Fedora we should support, it might be a good > idea to introduce it into Fedora 26, that way there will be some extra PR. Feel free to add it to any repo where it builds, and you believe it will keep building. I'm litte bit reluctant to backport openjdk subpackages to early, but sooner or later they will get merged from rawhide to at least f26. Btw, this is worthy change. Although it is late, it can be announced as https://fedoraproject.org/wiki/Releases/26/ChangeSet self contained change. If not here, then for f27 for sure. But it is up to you Thank you very much for your valuable contribution to openjdk on fedora!
(In reply to jiri vanek from comment #100) > Btw, this is worthy change. Although it is late, it can be announced as > https://fedoraproject.org/wiki/Releases/26/ChangeSet self contained change. > If not here, then for f27 for sure. But it is up to you I am open for both options, but it is not user friendly without the openjdk-openjfx subpackage. It would be nice to synchronize the two packages, so that the end-users do not get confused. > Thank you very much for your valuable contribution to openjdk on fedora! Thanks, you're welcome! Thanks to all the developers that started the inital spec-file, have giving me feedback, improved the setup and pushed forward the review and the openjdk-openjfx subpackage! I am glad to finally see that openjfx is in our official repository.
(In reply to jiri vanek from comment #100) > Feel free to add it to any repo where it builds, and you believe it will > keep building. > I'm litte bit reluctant to backport openjdk subpackages to early, but > sooner or later they will get merged from rawhide to at least f26. I think f27 is a nice target, then we can do some marketing with openjfx and applications that depend on openjfx. For me the most important is not to confuse users that might think that openjfx should work without the openjdk-subpackage.
(In reply to Jonny Heggheim from comment #101) > (In reply to jiri vanek from comment #100) > > Btw, this is worthy change. Although it is late, it can be announced as > > https://fedoraproject.org/wiki/Releases/26/ChangeSet self contained change. > > If not here, then for f27 for sure. But it is up to you > I am open for both options, but it is not user friendly without the > openjdk-openjfx subpackage. It would be nice to synchronize the two > packages, so that the end-users do not get confused. Fair enough. I see that you have built done *and* update in progress, so I will sync f26 with rawhide and do openjdk8 then release too. What to do with f25? I would incline to similar approach, once it is stable in f26, you can do update and once update will be in testing (feel free to ping me) I will update openjdk8. (In reply to Jonny Heggheim from comment #102) > (In reply to jiri vanek from comment #100) > > Feel free to add it to any repo where it builds, and you believe it will > > keep building. > > I'm litte bit reluctant to backport openjdk subpackages to early, but > > sooner or later they will get merged from rawhide to at least f26. > > I think f27 is a nice target, then we can do some marketing with openjfx and Yes please! The https://fedoraproject.org/wiki/Releases/27/ChangeSet is source for all release notes and comunity+press announcements. If you fill the self contained change here (ideally asap) it would be awesome. > applications that depend on openjfx. For me the most important is not to > confuse users that might think that openjfx should work without the > openjdk-subpackage. Spoiler alert :) Not exactly true. Michal was testing your original openjfx packages without my openjdk8 bridge on build of JIdea. And it was enough (/me aware it is minority, but still it is here, and I can imagine one can incline to not-connected fx+pure java.)
(In reply to jiri vanek from comment #103) > (In reply to Jonny Heggheim from comment #101) > > (In reply to jiri vanek from comment #100) > > > Btw, this is worthy change. Although it is late, it can be announced as > > > https://fedoraproject.org/wiki/Releases/26/ChangeSet self contained change. > > > If not here, then for f27 for sure. But it is up to you > > I am open for both options, but it is not user friendly without the > > openjdk-openjfx subpackage. It would be nice to synchronize the two > > packages, so that the end-users do not get confused. > > > Fair enough. I see that you have built done *and* update in progress, so I > will sync f26 with rawhide and do openjdk8 then release too. f26 merged form f27 and building. I will release update asap. > > What to do with f25? I would incline to similar approach, once it is stable > in f26, you can do update and once update will be in testing (feel free to > ping me) I will update openjdk8. Let me know how you decide here.
(In reply to jiri vanek from comment #104) > (In reply to jiri vanek from comment #103) > > (In reply to Jonny Heggheim from comment #101) > > > (In reply to jiri vanek from comment #100) > > > > Btw, this is worthy change. Although it is late, it can be announced as > > > > https://fedoraproject.org/wiki/Releases/26/ChangeSet self contained change. > > > > If not here, then for f27 for sure. But it is up to you > > > I am open for both options, but it is not user friendly without the > > > openjdk-openjfx subpackage. It would be nice to synchronize the two > > > packages, so that the end-users do not get confused. > > > > > > Fair enough. I see that you have built done *and* update in progress, so I > > will sync f26 with rawhide and do openjdk8 then release too. > > f26 merged form f27 and building. I will release update asap. > > > > What to do with f25? I would incline to similar approach, once it is stable > > in f26, you can do update and once update will be in testing (feel free to > > ping me) I will update openjdk8. > > Let me know how you decide here. I unpused the f25 update, I plan to keep the f26 in updates-testing till the openjdk-openjfx subpackage have been updated and we have built one or two packages that depend on openjfx. I am planning to add ReactFX https://github.com/TomasMikula/ReactFX, MSearch is about to be added (bug 1421366)
(In reply to jiri vanek from comment #103) > Spoiler alert :) Not exactly true. Michal was testing your original openjfx > packages without my openjdk8 bridge on build of JIdea. And it was enough > (/me aware it is minority, but still it is here, and I can imagine one can > incline to not-connected fx+pure java.) Most project built from Maven or Gradle will fail because there are no javafx packages in the classpath. The same when users run the programs from commandline or scripts made by upstream.
(In reply to Jonny Heggheim from comment #106) > (In reply to jiri vanek from comment #103) > > Spoiler alert :) Not exactly true. Michal was testing your original openjfx > > packages without my openjdk8 bridge on build of JIdea. And it was enough > > (/me aware it is minority, but still it is here, and I can imagine one can > > incline to not-connected fx+pure java.) > > Most project built from Maven or Gradle will fail because there are no > javafx packages in the classpath. The same when users run the programs from > commandline or scripts made by upstream. Sure, I'm aware of this. Still standalone openjfx packages have it usecase, and that should be remembered.
(In reply to Jonny Heggheim from comment #105) > (In reply to jiri vanek from comment #104) > > (In reply to jiri vanek from comment #103) > > > (In reply to Jonny Heggheim from comment #101) > > > > (In reply to jiri vanek from comment #100) > > > > > Btw, this is worthy change. Although it is late, it can be announced as > > > > > https://fedoraproject.org/wiki/Releases/26/ChangeSet self contained change. > > > > > If not here, then for f27 for sure. But it is up to you > > > > I am open for both options, but it is not user friendly without the > > > > openjdk-openjfx subpackage. It would be nice to synchronize the two > > > > packages, so that the end-users do not get confused. > > > > > > > > > Fair enough. I see that you have built done *and* update in progress, so I > > > will sync f26 with rawhide and do openjdk8 then release too. > > > > f26 merged form f27 and building. I will release update asap. > > > > > > What to do with f25? I would incline to similar approach, once it is stable > > > in f26, you can do update and once update will be in testing (feel free to > > > ping me) I will update openjdk8. > > > > Let me know how you decide here. > > I unpused the f25 update, Yah, I noted fate of f25. Thats oak and up to you. Just let me know if you will wish java-openjfx binding subpackages. > I plan to keep the f26 in updates-testing till the openjdk-openjfx subpackage I do not agree with that. Standalone openjfx, however small, have its target audience (eg custom build of icedtea web is also putting just fx.jar to classapth and is done with it). On contrary, java-openjfx binding have none. Actually it will produce broken package. Please move it to stable once possible. Otherwise I will need to keep updates to openjdk in testing for identical time. And ugh...for now openjdk need updates a bit more often then openjfx. All above would become invlaid, if you thikn I can public openjdk subpackages with broken dependencies.... > have been updated and we have built one or twopackages that depend on openjfx. I am planning to add ReactFX > https://github.com/TomasMikula/ReactFX, MSearch is about to be added (bug > 1421366) good!
(In reply to jiri vanek from comment #108) > I do not agree with that. Standalone openjfx, however small, have its target > audience (eg custom build of icedtea web is also putting just fx.jar to > classapth and is done with it). On contrary, java-openjfx binding have none. > Actually it will produce broken package. > > Please move it to stable once possible. Otherwise I will need to keep > updates to openjdk in testing for identical time. And ugh...for now > openjdk need updates a bit more often then openjfx. > > All above would become invlaid, if you thikn I can public openjdk > subpackages with broken dependencies.... Ok, then I will move it to stable when I am allowed. I can also make a new update for f25 so that we it it as standalone and that openjdx-openjfx do not have broken dependencies when/if it is updated.
f26 have been pushed to stable and f25 have been pushed to testing
(In reply to Jonny Heggheim from comment #111) > f26 have been pushed to stable and f25 have been pushed to testing Thanx! Hereis update for f26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-fac00cb010 ( i had one bad before where Miochal found broken link) and here is build for f25 sycned from f26: https://koji.fedoraproject.org/koji/taskinfo?taskID=19924405
openjfx-8.0.152-10.b04.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
I am making a package for ReactFX. The Requirements and BuildRequirements look like this: Requires: openjfx Requires: java-1.8.0-openjdk-openjfx BuildRequires: openjfx-devel BuildRequires: java-1.8.0-openjdk-openjfx BuildRequires: java-1.8.0-openjdk-openjfx-devel It would be nice to simplify this to something like: Requires: javafx BuildRequires: javafx-devel Any ideas?
(In reply to Jonny Heggheim from comment #115) > I am making a package for ReactFX. The Requirements and BuildRequirements > look like this: > > Requires: openjfx > Requires: java-1.8.0-openjdk-openjfx > BuildRequires: openjfx-devel > BuildRequires: java-1.8.0-openjdk-openjfx > BuildRequires: java-1.8.0-openjdk-openjfx-devel > > It would be nice to simplify this to something like: > Requires: javafx > BuildRequires: javafx-devel > > > Any ideas? Hi I'm strongly against replacing "openjfx" by "javafx". I'm in favour of preserving a clear distinction between the free software and the proprietary software, exactly as it's already done for OpenJDK and Oracle Java.
(In reply to Julien Gouesse from comment #116) > (In reply to Jonny Heggheim from comment #115) > > I am making a package for ReactFX. The Requirements and BuildRequirements > > look like this: > > > > Requires: openjfx > > Requires: java-1.8.0-openjdk-openjfx > > BuildRequires: openjfx-devel > > BuildRequires: java-1.8.0-openjdk-openjfx > > BuildRequires: java-1.8.0-openjdk-openjfx-devel > > > > It would be nice to simplify this to something like: > > Requires: javafx > > BuildRequires: javafx-devel > > > > > > Any ideas? > > Hi > > I'm strongly against replacing "openjfx" by "javafx". I'm in favour of > preserving a clear distinction between the free software and the proprietary > software, exactly as it's already done for OpenJDK and Oracle Java. Renaming is really out of way, But I think I can add virtual provides. Everybody ok? https://paste.fedoraproject.org/paste/Uf7R3bpeAgFrmRNMkGx-gQ
I think you should make it a versioned provides
(In reply to Sander Hoentjen from comment #118) > I think you should make it a versioned provides You are right
http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/commit/?id=a6e9c72894d56805cd1e28998dcd30970cfda412 https://koji.fedoraproject.org/koji/taskinfo?taskID=20046956 hth, feel free to comment
(In reply to jiri vanek from comment #120) > hth, feel free to comment Looks great. Btw, I forgot that the openjdk-openjfx(-devel) subpackages required openjfx(-devel), so the end result is now what I wanted :)
Thanks for the suggestions and the fix!
I was a bit optimistic making the openjfx-subpackage as noarch, this is now changed to the same arch as the parent. So I think openjdk-openjfx-devel need to update %{?_isa} suffix to the openjfx-devel requires.
(In reply to Jonny Heggheim from comment #123) > I was a bit optimistic making the openjfx-subpackage > as noarch, this is now changed to the same arch as the parent. So I think > openjdk-openjfx-devel need to update %{?_isa} suffix to the openjfx-devel > requires. http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/commit/?id=aaedfc554ed8429191b75a38108e92f516465fd3 https://koji.fedoraproject.org/koji/taskinfo?taskID=20054253 Here we go. I will merge to f26 and f25 once openjfx updates are in stable What proved noarch was wrong?
(In reply to jiri vanek from comment #124) > What proved noarch was wrong? Bug 1461984 + koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=20039018
openjfx-8.0.152-10.b04.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
The build failed. Anyone could take a look?
(In reply to Ricardo Martinelli de Oliveira from comment #127) > The build failed. Anyone could take a look? What build failed? Do you have more information?
https://koji.fedoraproject.org/koji/taskinfo?taskID=20039018
(In reply to Ricardo Martinelli de Oliveira from comment #129) > https://koji.fedoraproject.org/koji/taskinfo?taskID=20039018 That is an old build openjfx-8.0.152-11.b04.fc27 that triggered the noarch issue with sub-packages. This have been fixed in 8.0.152-12.b04.
(In reply to jiri vanek from comment #124) > Here we go. I will merge to f26 and f25 once openjfx updates are in stable The fix in 8.0.152-12.b04 have been pushed to f26 and f25 stable.
I ran this koji build as part of package review of reactfx bug 1467716: https://koji.fedoraproject.org/koji/taskinfo?taskID=20327854 The reson why it fails is because reactfx have BuildArch: noarch and is building on arm where javafx is missing. How should we resolve this issue?
Can someone help me co-maintain openjfx and/or look at bug 1472613?
Has anyone been able to build this package with WebKit support (COMPILE_WEBKIT = true) on Fedora 26? I was able to progress a little bit by adding a few extra missing dependencies and running "gradle" in ONLINE mode (is having gradle working OFFLINE a requirement?). However, I was soon hit by a bunch WebKit compilation warnings and errors. I was able to fix some of them by adding the "-Wimplicit-fallthrough=0 -Wnoexpansion-to-defined" flags to GCC/G++ but eventually I was hit by some error on a JavascriptCore .cpp file. I don't have the exact error I got right now, but it was something along the lines of: "passing ** as ‘this’ argument of *** discards qualifiers error". I attempted this a few days ago and I got a little frustrated. I just gave up on it and deleted everything with the intention of eventually starting from scratch on a dedicated environment, i.e., a VM with a Fedora 26 fresh install where I can just try to build OpenJFX using gradle directly just to know if it is possible or not to built it on Fedora. However, I feel that I will probably have to go even further and start to patch the underlying source code just to get it to finish building with no errors. Maybe this is caused by Fedora 26's build tools being too recent for the WebKit version that is bundled with OpenJFX, even though I had actually updated the package to be built from the the latest OpenJFX release (8u162-b00) that I found here: http://hg.openjdk.java.net/openjfx/8u/rt/tags What do you all think? Is it possible to get OpenJFX with web support working on Fedora or not? I mean, Debian has done it, why can't Fedora do it as well? They have lots of patches to get it working (see: https://anonscm.debian.org/cgit/pkg-java/openjfx.git/tree/debian/patches) However, from what I could tell, many of those patches are only there to ensure that it builds under as many architectures as possible. Fedora doesn't support nearly as many architectures as Debian does, so we don't need many of those patches. I think that they even have been able to have gradle work OFFLINE by replacing the "webview-deps" replaced by their own "equivalent" binaries that are already part of the distribution (check this file around line #43: https://anonscm.debian.org/cgit/pkg-java/openjfx.git/tree/debian/rules). I'd also like to try to build OpenJFX with "COMPILE_MEDIA=true" using RPMFusion packages. I know that such package could not be built and included with the "vanilla" Fedora. However, I think that media support is just a bunch of .so files that could be thought of as an addon to the "official" openjfx packaged, so the missing media support could eventually be shipped as a package on RPMFusion while keeping everything else on Fedora. What do you think?
I forgot to mention that Arch Linux also has a fully functioning OpenJFX build and they usually have build tools as recent (or newer) than Fedora: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/java-openjfx They only support x86_64 so they have just a couple of patches instead of about a dozen like Debian. If someone has the time, it could be a good starting point. I curently can't spend more time on this problem (I just had to use Oracle Java instead) but I'd love to see a fully functional OpenJFX on Fedora.
(In reply to Pedro Albuquerque Santos from comment #135) > is having gradle working OFFLINE a requirement? Yes. In Fedora everything must be built in our build system, Koji, with no Internet access.
(In reply to Pedro Albuquerque Santos from comment #135) > Has anyone been able to build this package with WebKit support > (COMPILE_WEBKIT = true) on Fedora 26? I was able to progress a little bit by > adding a few extra missing dependencies and running "gradle" in ONLINE mode > (is having gradle working OFFLINE a requirement?). However, I was soon hit > by a bunch WebKit compilation warnings and errors. I was able to fix some of > them by adding the "-Wimplicit-fallthrough=0 -Wnoexpansion-to-defined" flags > to GCC/G++ but eventually I was hit by some error on a JavascriptCore .cpp > file. I managed to build webkit and media running gradle on my laptop with ffmpeg installed from RPM Fusion, probably a year ago on Fedora 25.
(In reply to Pedro Albuquerque Santos from comment #135) > What do you all think? Is it possible to get OpenJFX with web support > working on Fedora or not? I mean, Debian has done it, why can't Fedora do it > as well? They have lots of patches to get it working (see: > https://anonscm.debian.org/cgit/pkg-java/openjfx.git/tree/debian/patches) > However, from what I could tell, many of those patches are only there to > ensure that it builds under as many architectures as possible. Fedora > doesn't support nearly as many architectures as Debian does, so we don't > need many of those patches. OpenJFX is requires a lot of manhours to improve and maintain. Problems: * Large with many bundled libraries * Installation/integration with OpenJDK is clumpsy * Upstream supports Intel only for Linux * Media depends on ffmpeg * webkit depends on media I welcome everyone who wants to contribute. > I think that they even have been able to have > gradle work OFFLINE by replacing the "webview-deps" replaced by their own > "equivalent" binaries that are already part of the distribution (check this > file around line #43: > https://anonscm.debian.org/cgit/pkg-java/openjfx.git/tree/debian/rules). Nice solution, that dependency was a "shit, what should we do with this gigantic blob?"
Hello all! I hadd added fx:javafx-desc support to icedtea-web: http://icedtea.classpath.org/hg/icedtea-web/rev/7251d3abc7ab (yes so simple:) With javafx claspsath hack form about year ago (http://icedtea.classpath.org/hg/icedtea-web/rev/200af1c71bb2 which allowed run of normal java applications and using fx as library) it seems that it is doing something! There is test in itw: http://icedtea.classpath.org/hg/icedtea-web/raw-file/f2717977a1b3/tests/reproducers/custom/JavaFx/resources/JavaFx.jnlp whic run nearly perfectly Also there is eg this https://nimhda-external-prod.s3.amazonaws.com/validationtool-client.jnlp real life example, which starts.. but... So several issues I woudl like to highlight are here: notes: * Unsigned javafx application (should not even exists..) must runwith --nosecurity, as javafx is doing something nasty with classlaoders. It is maybe bug in ITW, mayb enot. Not going to fix it unless t will be obstacle in real world. * itw do not build wit javafx rpms installed and plugin enabled (already RHEL only) - it is known - JSObject is redeclared in javafx jar and this implementation is not compatible with ITW's JSObject. Thats why the reproducer contains prebuild binary. I really donot wont to drag Javafx dependency into upstream. When running my automated testcase (both manually and automatically), I got 50/50 this error: (javaws:15748): Gdk-ERROR **: The program 'javaws' received an X Window System error. This probably reflects a bug in the program. The error was 'RenderBadPicture (invalid Picture parameter)'. (Details: serial 13007 error_code 141 request_code 138 minor_code 7) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Trace/breakpoint trap (core dumped) Fun is, that awt splash screen is visible before it, and ITW error dialogue rises after it correctly too. So it is some FX issue. On contrary, Unhappy is, that running simple java -cp JavaFx.jar Main (from url 2x above) do NOT cause the issue. So it is javafx+javaws specific thing... Crap. When running the validationtool-client.jnlp real-aplication it starts, but dies with "gov.nih.nimhda.ndar.validationtool.ValidationException: Missing API URL for ValidationToolService" -it is already nice fx skinned dialogue from app itself. It is later followed by ITW error dialogue of: net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch JNLP file. The application has not been initialized, for more information execute javaws/browser from the command line and send a bug report. at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:577) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:940) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:571) ... 1 more Caused by: java.lang.RuntimeException: Exception in Application start method at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:917) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$1(LauncherImpl.java:182) at java.lang.Thread.run(Thread.java:748) Caused by: javafx.fxml.LoadException: No resources specified. http://nimhda-external-prod.s3.amazonaws.com/validationtool-client-1.15.jar!/fxml/ValidationTool.fxml:20 at javafx.fxml.FXMLLoader.constructLoadException(FXMLLoader.java:2597) at javafx.fxml.FXMLLoader.access$100(FXMLLoader.java:103) at javafx.fxml.FXMLLoader$Element.resolvePrefixedValue(FXMLLoader.java:421) at javafx.fxml.FXMLLoader$Element.processValue(FXMLLoader.java:363) at javafx.fxml.FXMLLoader$Element.processPropertyAttribute(FXMLLoader.java:325) at javafx.fxml.FXMLLoader$Element.processInstancePropertyAttributes(FXMLLoader.java:235) at javafx.fxml.FXMLLoader$ValueElement.processEndElement(FXMLLoader.java:767) at javafx.fxml.FXMLLoader.processEndElement(FXMLLoader.java:2823) at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2532) at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2441) at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2409) at gov.nih.nimhda.ndar.validationtool.ValidationTool.showStage(ValidationTool.java:66) at gov.nih.nimhda.ndar.validationtool.ValidationTool.start(ValidationTool.java:59) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:863) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$7(PlatformImpl.java:326) at com.sun.javafx.application.PlatformImpl.lambda$null$5(PlatformImpl.java:295) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$6(PlatformImpl.java:294) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$5(GtkApplication.java:139) ... 1 more , probably caused by [3]. Not sure if it is itw error or our (javafx) packaging error. Full trace is at [2] Of course, when you uninstall our javafx packages, it will not even start [1]. Jonny/Mario - any ideas? Alex, can you check on your Wndows builds? If you guys hallow this as usable, I will backport the patches ot ITW 1.7, and do rpms for Fedora. For now, I will attach netx.jar to this bug so you can try it with current TIW installations. [1] java.lang.ClassNotFoundException: javafx.application.Application at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1798) at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1598) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at net.sourceforge.jnlp.runtime.JNLPClassLoader.access$1701(JNLPClassLoader.java:105) at net.sourceforge.jnlp.runtime.JNLPClassLoader$5.run(JNLPClassLoader.java:1744) at net.sourceforge.jnlp.runtime.JNLPClassLoader$5.run(JNLPClassLoader.java:1741) at java.security.AccessController.doPrivileged(Native Method) at net.sourceforge.jnlp.runtime.JNLPClassLoader.findClass(JNLPClassLoader.java:1740) at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1777) at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1577) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:552) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:940) java.lang.NoClassDefFoundError: javafx/application/Application at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at net.sourceforge.jnlp.runtime.JNLPClassLoader.access$1701(JNLPClassLoader.java:105) at net.sourceforge.jnlp.runtime.JNLPClassLoader$5.run(JNLPClassLoader.java:1744) at net.sourceforge.jnlp.runtime.JNLPClassLoader$5.run(JNLPClassLoader.java:1741) at java.security.AccessController.doPrivileged(Native Method) at net.sourceforge.jnlp.runtime.JNLPClassLoader.findClass(JNLPClassLoader.java:1740) at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1777) at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1577) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:552) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:940) Caused by: java.lang.ClassNotFoundException: javafx.application.Application at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1640) ... 18 more Exception in thread "Validation Tool" java.lang.RuntimeException: java.lang.NoClassDefFoundError: javafx/application/ApplicationSystem logger called with result of 0 [2] 15:03:30.844 INFO [Thread-12] g.n.n.n.v.t.d.LocalLoggerDispatcher - {"session":"f906712d-79e8-4f69-96cf-57517bf14304","message":{"name":"void org.slf4j.Logger.error(String, Throwable)","type":"Error","message":"Error initializing application","exception":{"cause":null,"stackTrace":[{"methodName":"constructWebService","fileName":"ValidationTool.java","lineNumber":103,"className":"gov.nih.nimhda.ndar.validationtool.ValidationTool","nativeMethod":false},{"methodName":"initializeWebServices","fileName":"ValidationTool.java","lineNumber":79,"className":"gov.nih.nimhda.ndar.validationtool.ValidationTool","nativeMethod":false},{"methodName":"start","fileName":"ValidationTool.java","lineNumber":52,"className":"gov.nih.nimhda.ndar.validationtool.ValidationTool","nativeMethod":false},{"methodName":"lambda$launchApplication1$8","fileName":"LauncherImpl.java","lineNumber":863,"className":"com.sun.javafx.application.LauncherImpl","nativeMethod":false},{"methodName":"lambda$runAndWait$7","fileName":"PlatformImpl.java","lineNumber":326,"className":"com.sun.javafx.application.PlatformImpl","nativeMethod":false},{"methodName":"lambda$null$5","fileName":"PlatformImpl.java","lineNumber":295,"className":"com.sun.javafx.application.PlatformImpl","nativeMethod":false},{"methodName":"doPrivileged","fileName":"AccessController.java","lineNumber":-2,"className":"java.security.AccessController","nativeMethod":true},{"methodName":"lambda$runLater$6","fileName":"PlatformImpl.java","lineNumber":294,"className":"com.sun.javafx.application.PlatformImpl","nativeMethod":false},{"methodName":"run","fileName":"InvokeLaterDispatcher.java","lineNumber":95,"className":"com.sun.glass.ui.InvokeLaterDispatcher$Future","nativeMethod":false},{"methodName":"_runLoop","fileName":"GtkApplication.java","lineNumber":-2,"className":"com.sun.glass.ui.gtk.GtkApplication","nativeMethod":true},{"methodName":"lambda$null$5","fileName":"GtkApplication.java","lineNumber":139,"className":"com.sun.glass.ui.gtk.GtkApplication","nativeMethod":false},{"methodName":"run","fileName":"Thread.java","lineNumber":748,"className":"java.lang.Thread","nativeMethod":false}],"message":"Missing API URL for ValidationToolService","localizedMessage":"Missing API URL for ValidationToolService","suppressed":[]}},"created":"2018-02-04T14:03:30.242Z"} java.lang.ClassNotFoundException: ValidationTool_i18n/ValidationTool_en_US at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1798) at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1598) at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2649) at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1510) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1474) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1370) at java.util.ResourceBundle.getBundle(ResourceBundle.java:782) at gov.nih.nimhda.ndar.validationtool.Msg.<clinit>(Msg.java:7) at gov.nih.nimhda.ndar.validationtool.ui.view.JavaFxDialogFactory.showError(JavaFxDialogFactory.java:65) at gov.nih.nimhda.ndar.validationtool.ui.view.DialogUtil.showError(DialogUtil.java:31) at gov.nih.nimhda.ndar.validationtool.ValidationTool.start(ValidationTool.java:57) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:863) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$7(PlatformImpl.java:326) at com.sun.javafx.application.PlatformImpl.lambda$null$5(PlatformImpl.java:295) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$6(PlatformImpl.java:294) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$5(GtkApplication.java:139) at java.lang.Thread.run(Thread.java:748) java.lang.ClassNotFoundException: ValidationTool_i18n/ValidationTool_en at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1798) at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1598) at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2649) at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1510) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1474) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1428) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1370) at java.util.ResourceBundle.getBundle(ResourceBundle.java:782) at gov.nih.nimhda.ndar.validationtool.Msg.<clinit>(Msg.java:7) at gov.nih.nimhda.ndar.validationtool.ui.view.JavaFxDialogFactory.showError(JavaFxDialogFactory.java:65) at gov.nih.nimhda.ndar.validationtool.ui.view.DialogUtil.showError(DialogUtil.java:31) at gov.nih.nimhda.ndar.validationtool.ValidationTool.start(ValidationTool.java:57) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:863) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$7(PlatformImpl.java:326) at com.sun.javafx.application.PlatformImpl.lambda$null$5(PlatformImpl.java:295) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$6(PlatformImpl.java:294) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$5(GtkApplication.java:139) at java.lang.Thread.run(Thread.java:748) java.lang.ClassNotFoundException: ValidationTool_i18n/ValidationTool at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1798) at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1598) at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2649) at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1510) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1474) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1428) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1428) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1370) at java.util.ResourceBundle.getBundle(ResourceBundle.java:782) at gov.nih.nimhda.ndar.validationtool.Msg.<clinit>(Msg.java:7) at gov.nih.nimhda.ndar.validationtool.ui.view.JavaFxDialogFactory.showError(JavaFxDialogFactory.java:65) at gov.nih.nimhda.ndar.validationtool.ui.view.DialogUtil.showError(DialogUtil.java:31) at gov.nih.nimhda.ndar.validationtool.ValidationTool.start(ValidationTool.java:57) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:863) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$7(PlatformImpl.java:326) at com.sun.javafx.application.PlatformImpl.lambda$null$5(PlatformImpl.java:295) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$6(PlatformImpl.java:294) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$5(GtkApplication.java:139) at java.lang.Thread.run(Thread.java:748) 15:03:30.327 INFO [JavaFX Application Thread] g.n.n.n.v.u.view.JavaFxDialogFactory - Constructed as dialog handler 15:03:30.241 DEBUG [JavaFX Application Thread] g.n.n.n.v.t.TelemetryMessageAspects - Sending message: gov.nih.nimhda.ndar.validationtool.telemetry.TelemetryErrorMessage@9b66c02 15:03:30.238 ERROR [JavaFX Application Thread] g.n.n.n.v.ValidationTool - Error initializing application gov.nih.nimhda.ndar.validationtool.ValidationException: Missing API URL for ValidationToolService at gov.nih.nimhda.ndar.validationtool.ValidationTool.constructWebService(ValidationTool.java:103) ~[validationtool-client-1.15.jar:na] at gov.nih.nimhda.ndar.validationtool.ValidationTool.initializeWebServices(ValidationTool.java:79) ~[validationtool-client-1.15.jar:na] at gov.nih.nimhda.ndar.validationtool.ValidationTool.start(ValidationTool.java:52) ~[validationtool-client-1.15.jar:na] at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:863) [jfxrt.jar:na] at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$7(PlatformImpl.java:326) ~[jfxrt.jar:na] at com.sun.javafx.application.PlatformImpl.lambda$null$5(PlatformImpl.java:295) ~[jfxrt.jar:na] at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_161] at com.sun.javafx.application.PlatformImpl.lambda$runLater$6(PlatformImpl.java:294) ~[jfxrt.jar:na] at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) ~[jfxrt.jar:na] at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) ~[jfxrt.jar:na] at com.sun.glass.ui.gtk.GtkApplication.lambda$null$5(GtkApplication.java:139) ~[jfxrt.jar:na] at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_161] 15:03:30.223 DEBUG [JavaFX Application Thread] g.n.n.n.v.ValidationTool - Initializing web services 15:03:29.894 INFO [Validation Tool] g.n.n.n.v.ValidationTool - Starting application java.lang.ClassNotFoundException: ch.qos.logback.core.FileAppenderCustomizer at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1798) at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1598) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:67) at com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:110) at java.beans.Introspector.findCustomizerClass(Introspector.java:1301) at java.beans.Introspector.getTargetBeanDescriptor(Introspector.java:1295) at java.beans.Introspector.getBeanInfo(Introspector.java:425) at java.beans.Introspector.getBeanInfo(Introspector.java:173) at ch.qos.logback.core.joran.util.PropertySetter.introspect(PropertySetter.java:79) at ch.qos.logback.core.joran.util.PropertySetter.getMethod(PropertySetter.java:393) at ch.qos.logback.core.joran.util.PropertySetter.findAdderMethod(PropertySetter.java:203) at ch.qos.logback.core.joran.util.PropertySetter.computeAggregationType(PropertySetter.java:177) at ch.qos.logback.core.joran.action.NestedComplexPropertyIA.isApplicable(NestedComplexPropertyIA.java:61) at ch.qos.logback.core.joran.spi.Interpreter.lookupImplicitAction(Interpreter.java:237) at ch.qos.logback.core.joran.spi.Interpreter.getApplicableActionList(Interpreter.java:256) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:144) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:129) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:149) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:135) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:99) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:49) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:77) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:152) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:129) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:302) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288) at gov.nih.nimhda.ndar.validationtool.ValidationTool.<clinit>(ValidationTool.java:42) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:571) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:940) java.lang.ClassNotFoundException: ch.qos.logback.core.FileAppenderCustomizer at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1798) at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1598) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:103) at java.beans.Introspector.findCustomizerClass(Introspector.java:1301) at java.beans.Introspector.getTargetBeanDescriptor(Introspector.java:1295) at java.beans.Introspector.getBeanInfo(Introspector.java:425) at java.beans.Introspector.getBeanInfo(Introspector.java:173) at ch.qos.logback.core.joran.util.PropertySetter.introspect(PropertySetter.java:79) at ch.qos.logback.core.joran.util.PropertySetter.getMethod(PropertySetter.java:393) at ch.qos.logback.core.joran.util.PropertySetter.findAdderMethod(PropertySetter.java:203) at ch.qos.logback.core.joran.util.PropertySetter.computeAggregationType(PropertySetter.java:177) at ch.qos.logback.core.joran.action.NestedComplexPropertyIA.isApplicable(NestedComplexPropertyIA.java:61) at ch.qos.logback.core.joran.spi.Interpreter.lookupImplicitAction(Interpreter.java:237) at ch.qos.logback.core.joran.spi.Interpreter.getApplicableActionList(Interpreter.java:256) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:144) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:129) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:149) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:135) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:99) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:49) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:77) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:152) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:129) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:302) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288) at gov.nih.nimhda.ndar.validationtool.ValidationTool.<clinit>(ValidationTool.java:42) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:571) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:940) java.lang.ClassNotFoundException: ch.qos.logback.core.FileAppenderBeanInfo [3]gov.nih.nimhda.ndar.validationtool.ValidationException: Missing API URL for ValidationToolService at gov.nih.nimhda.ndar.validationtool.ValidationTool.constructWebService(ValidationTool.java:103) at gov.nih.nimhda.ndar.validationtool.ValidationTool.initializeWebServices(ValidationTool.java:79) at gov.nih.nimhda.ndar.validationtool.ValidationTool.start(ValidationTool.java:52) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:863) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$7(PlatformImpl.java:326) at com.sun.javafx.application.PlatformImpl.lambda$null$5(PlatformImpl.java:295) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$6(PlatformImpl.java:294) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$5(GtkApplication.java:139) at java.lang.Thread.run(Thread.java:748) [4]net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch JNLP file. The application has not been initialized, for more information execute javaws/browser from the command line and send a bug report. at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:577) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:940) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:571) ... 1 more Caused by: java.lang.RuntimeException: Exception in Application start method at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:917) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$1(LauncherImpl.java:182) at java.lang.Thread.run(Thread.java:748) Caused by: javafx.fxml.LoadException: No resources specified. http://nimhda-external-prod.s3.amazonaws.com/validationtool-client-1.15.jar!/fxml/ValidationTool.fxml:20 at javafx.fxml.FXMLLoader.constructLoadException(FXMLLoader.java:2597) at javafx.fxml.FXMLLoader.access$100(FXMLLoader.java:103) at javafx.fxml.FXMLLoader$Element.resolvePrefixedValue(FXMLLoader.java:421) at javafx.fxml.FXMLLoader$Element.processValue(FXMLLoader.java:363) at javafx.fxml.FXMLLoader$Element.processPropertyAttribute(FXMLLoader.java:325) at javafx.fxml.FXMLLoader$Element.processInstancePropertyAttributes(FXMLLoader.java:235) at javafx.fxml.FXMLLoader$ValueElement.processEndElement(FXMLLoader.java:767) at javafx.fxml.FXMLLoader.processEndElement(FXMLLoader.java:2823) at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2532) at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2441) at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2409) at gov.nih.nimhda.ndar.validationtool.ValidationTool.showStage(ValidationTool.java:66) at gov.nih.nimhda.ndar.validationtool.ValidationTool.start(ValidationTool.java:59) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:863) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$7(PlatformImpl.java:326) at com.sun.javafx.application.PlatformImpl.lambda$null$5(PlatformImpl.java:295) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$6(PlatformImpl.java:294) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$5(GtkApplication.java:139) ... 1 more
Created attachment 1392650 [details] first netx.jar with fx:javafx-desc support
AWt splash screen was marked as guilty. Indeed, running /javaws.sh --headless or with ICEDTEA_WEB_SPLASH=false is maing the X error to disapear.
(of course the missning fx classes are still an issue)
Is there a solution yet? I am hosting a webapp on Amazon EB EC2 and the machine has RedHat, I can't install javafx and I really need it to compile some codes on the server! I have installed openjdk.
(In reply to Ahmed Hamdy from comment #145) > Is there a solution yet? > I am hosting a webapp on Amazon EB EC2 and the machine has RedHat, I can't > install javafx and I really need it to compile some codes on the server! > > I have installed openjdk. You can compile OpenJFX on RHEL, and it should work fine. This bug is really for tracking the package for Fedora (which has been shipped). Please, refer to this https://bugzilla.redhat.com/show_bug.cgi?id=1275610 for the RHEL tracking bug. Cheers, Mario
(In reply to Mario Torre from comment #146) > (In reply to Ahmed Hamdy from comment #145) > > Is there a solution yet? > > I am hosting a webapp on Amazon EB EC2 and the machine has RedHat, I can't > > install javafx and I really need it to compile some codes on the server! > > > > I have installed openjdk. > > You can compile OpenJFX on RHEL, and it should work fine. This bug is really > for tracking the package for Fedora (which has been shipped). > > Please, refer to this https://bugzilla.redhat.com/show_bug.cgi?id=1275610 > for the RHEL tracking bug. > > Cheers, > Mario Is there a link you can direct me to compile OpenJFX on RHEL? My server station is Red Hat 7.2.1-2 Thank you very much.
(In reply to Ahmed Hamdy from comment #147) > (In reply to Mario Torre from comment #146) > > (In reply to Ahmed Hamdy from comment #145) > > > Is there a solution yet? > > > I am hosting a webapp on Amazon EB EC2 and the machine has RedHat, I can't > > > install javafx and I really need it to compile some codes on the server! > > > > > > I have installed openjdk. > > > > You can compile OpenJFX on RHEL, and it should work fine. This bug is really > > for tracking the package for Fedora (which has been shipped). > > > > Please, refer to this https://bugzilla.redhat.com/show_bug.cgi?id=1275610 > > for the RHEL tracking bug. > > > > Cheers, > > Mario > > Is there a link you can direct me to compile OpenJFX on RHEL? My server > station is Red Hat 7.2.1-2 > > Thank you very much. The standard OpenJFX wiki should provide you all the instructions: https://wiki.openjdk.java.net/display/OpenJFX/Main Cheers, Mario
The JavaFX package has been orphaned in Fedora. What is happening? Why?
(In reply to Christian Stadelmann from comment #149) > The JavaFX package has been orphaned in Fedora. What is happening? Why? It takes too much time to maintain it, it would be great if someone could continue the maintenance.
Right now OpenJFX 8 is maintained as part of the RH ojdkbuild project. Cherry-picking the patches from there plus some trivial build fixes gives an up to date OpenJFX 8: https://github.com/jschwartzenberg/openjfx8 As most of the effort is already done by a RH employee, I would say it makes sense to roll this effort into a Fedora RPM too. Now I'm cherry-picking the latest patches from ojdkbuild and rebuilding OpenJFX 8 manually when I see an OpenJDK 8 update coming in through 'dnf update'.
openjfx have been included in Fedora.