That we get openjfx for newer Java versions is great news! I'll update the dependencies for this package as soon as the change reaches the stable repos. People using testing that want to install openjfx 11 probably need to modify this package to get around dependency issues.
Search Criteria
Package Details: jabref 5.15-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/jabref.git (read-only, click to copy) |
---|---|
Package Base: | jabref |
Description: | Graphical Java application for managing BibTeX and biblatex (.bib) databases |
Upstream URL: | https://www.jabref.org/ |
Licenses: | MIT |
Submitter: | Allan |
Maintainer: | Bevan |
Last Packager: | Bevan |
Votes: | 213 |
Popularity: | 0.23 |
First Submitted: | 2012-06-07 22:47 (UTC) |
Last Updated: | 2024-09-23 19:59 (UTC) |
Dependencies (4)
- archlinux-java-runAUR
- java-environment (jdk12AUR, jdk10AUR, jdk10-openj9-binAUR, jdk7AUR, amazon-corretto-16AUR, jdk8-graalvm-binAUR, jdk16-graalvm-binAUR, jdk16-adoptopenjdkAUR, jdk8-armAUR, liberica-jre-11-binAUR, jdk11-j9-binAUR, jdk11-jbr-xdgAUR, jdk16-openjdkAUR, jdk14-openjdkAUR, jdk18-openjdkAUR, amazon-corretto-19-binAUR, jdk19-graalvm-binAUR, liberica-jre-11-full-binAUR, jdk19-graalvm-ee-binAUR, jdk13-openjdk-binAUR, liberica-jre-8-full-binAUR, jdk11-graalvm-binAUR, jdk-openj9AUR, jdk11-graalvm-ee-binAUR, jdk12-openjdkAUR, jdk11-dragonwell-standard-binAUR, jdk11-jetbrains-binAUR, jdk20-graalvm-binAUR, jdk17-graalvm-binAUR, jdk8-graalvm-ee-binAUR, zulu-15-binAUR, jdk20-openj9-binAUR, zulu-13-binAUR, jdk8-dragonwell-extended-binAUR, jdk8-dragonwell-standard-binAUR, jdk11-dragonwell-extended-binAUR, jdk17-dragonwell-standard-binAUR, jdk11AUR, jdk8-j9-binAUR, jdk7-j9-binAUR, jdk7r1-j9-binAUR, jdk8-dragonwell-extendedAUR, jdk13-openjdkAUR, jdk15-openjdkAUR, jdk21-graalvm-binAUR, jdk17-jetbrainsAUR, jdk8-openj9-binAUR, jdk-ltsAUR, microsoft-openjdk-11-binAUR, microsoft-openjdk-17-binAUR, microsoft-openjdk-21-binAUR, liberica-nik-24-full-binAUR, jdk21-jetbrains-gitAUR, zulu-17-binAUR, zulu-11-binAUR, zulu-8-binAUR, mandrel-binAUR, mandrel24-binAUR, liberica-jdk-17-full-binAUR, liberica-jdk-11-lite-binAUR, liberica-jdk-11-full-binAUR, liberica-jdk-11-binAUR, jdk17-graalvm-ee-binAUR, jdk21-graalvm-ee-binAUR, jdk22-graalvm-ee-binAUR, jdk20-graalvm-ee-binAUR, jdk22-graalvm-binAUR, jdk19-openjdkAUR, jdk17-jetbrains-binAUR, zulu-jdk-fx-binAUR, jabba-binAUR, jdk21-jetbrainsAUR, jdk17-zulu-prime-binAUR, zing-21-binAUR, zing-8-binAUR, jdk23-graalvm-ee-binAUR, jdk-android-studioAUR, java-openjdk-binAUR, amazon-corretto-17AUR, amazon-corretto-21-binAUR, jdk21-temurinAUR, amazon-corretto-8AUR, amazon-corretto-11AUR, jdk11-temurinAUR, liberica-jdk-full-binAUR, liberica-jdk-21-full-binAUR, liberica-jdk-8-full-binAUR, jdk17-temurinAUR, jdk8-temurinAUR, zulu-21-binAUR, jdk-temurinAUR, jdk8AUR, zulu-17-fx-binAUR, jdk8-perfAUR, zulu-fx-binAUR, zulu8-fx-binAUR, zulu11-fx-binAUR, zulu17-fx-binAUR, zulu21-fx-binAUR, jdk-openj9-binAUR, jdk11-openj9-binAUR, jdk17-openj9-binAUR, jre-jetbrainsAUR, jdk-openjdk-wakefieldAUR, jdk21-openj9-binAUR, java-openjdk-ea-binAUR, zulu-23-binAUR, jdkAUR, jdk21-jetbrains-binAUR, jdk21-dragonwell-standard-binAUR, jdk21-dragonwell-extended-binAUR, jdk-openjdk, jdk11-openjdk, jdk17-openjdk, jdk21-openjdk, jdk8-openjdk)
- gradle (gradle7) (make)
- python (python37AUR, python311AUR, python310AUR) (optional) – browser extension
Required by (0)
Sources (7)
Latest Comments
« First ‹ Previous 1 .. 9 10 11 12 13 14 15 16 17 18 19 .. 21 Next › Last »
Bevan commented on 2019-06-18 08:05 (UTC)
totsilence commented on 2019-06-18 07:58 (UTC)
There is a new package (currently in testing): java8-openjfx. I think (at least when java8-openjfx leaves testing) this package should depend on that package, as java-openjfx was upgraded to java 11.
dschrempf commented on 2019-02-05 12:40 (UTC)
Sorry for the late response, I didn't have notifications enabled. Both of your commands give the same output:
openjdk version "1.8.0_202" OpenJDK Runtime Environment (build 1.8.0_202-b26) OpenJDK 64-Bit Server VM (build 25.202-b26, mixed mode)
At the moment, I am using the latest jar file provided at "https://builds.jabref.org/master/"! This seems to work better.
Bevan commented on 2019-01-11 09:40 (UTC)
@dschrempf: I think there are known issues like this with the current JabRef version that will be fixed in version 5 (e.g. https://github.com/JabRef/jabref/issues/4458).
However, this may very well depend on the version of the JRE used. Could you please run the following two commands and post the output here?
archlinux-java-run --min 8 --max 8 --feature javafx -- -version
archlinux-java-run --min 8 --max 8 -- -version
Thanks!
dschrempf commented on 2019-01-11 09:33 (UTC)
I noticed that java was not quitting after closing JabRef (this led to memory problems when reopening for a few times). I removed '--feature javafx' from 'archlinux-java-run' and then it worked. I am not sure if this breaks something, just wanted to let you know!
<deleted-account> commented on 2018-11-14 12:09 (UTC)
pikaur -S jabref Reading repository package databases... Reading local package database... Resolving AUR dependencies... :: New dependency will be installed from repository: java-openjfx (for jabref) -> 8.u172-2 :: AUR package will be installed: jabref -> 4.3.1-2 :: New dependency will be installed from AUR: archlinux-java-run (for jabref) -> 4-1
archlinux-java status Available Java environments: java-8-openjdk/jre (default)
Okay, the problem is that the installation of java-openjfx implicitly makes PyCharm search for JDK, which is not installed. Probably, a PyCharm bug.
Bevan commented on 2018-11-14 09:41 (UTC)
@alleut: This package should not affect other software at all. At least I don't know how it would.
I can however imagine that this package required you to install a different JDK and now your java installation is not configured proberly. Can you try running "archlinux-java fix"? If it does not help, please post the output of "archlinux-java status". Also see https://wiki.archlinux.org/index.php/java#Switching_between_JVM
<deleted-account> commented on 2018-11-14 00:45 (UTC)
Installation breaks PyCharm Community: "No JDK found. Please validate either PYCHARM_JDK, JDK_HOME or JAVA_HOME environment variable points to valid JDK installation."
Bevan commented on 2018-07-19 17:42 (UTC)
Unia: Thanks for the report! Indeed, gtk2 seems to be required for JavaFX, however it's only a make dependency of java-openjfx. I just added a bunch of JavaFX dependencies here, including gtk2.
Unia commented on 2018-07-19 14:31 (UTC)
This needs gtk2
to be added as a dependency. Without it, I get
Graphics Device initialization failed for : es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
Installing gtk2
fixes this.
Pinned Comments
Bevan commented on 2024-03-28 17:57 (UTC)
Everyone who struggles to update right now: Please install the jdk21-openjdk package. It provides java-environment=21.
Bevan commented on 2022-03-14 20:04 (UTC)
@shmilee: I like that idea. Implemented in 5.5-2 using JABREF_OPTIONS as variable name.
Note that you can then also put that environment variable into your .bashrc, .pam_environment or something similar to be automatically applied.
shmilee commented on 2022-03-12 13:51 (UTC)
How about add an extra JavaOptions variable in launch script
/usr/bin/jabref
like this?So we can add the
-Djdk.gtk.version=2
flag or-Dglass.gtk.uiScale=144dpi
flag by cmdline, no need to edit/usr/bin/jabref
after upgrade.matteodelabre commented on 2020-11-17 14:25 (UTC)
Using JabRef with i3wm, I’m running into the issue described at https://github.com/JabRef/jabref/issues/5867 in which clicking the menu bar sometimes opens then immediately closes the associated menu, rendering it unusable.
I was able to fix this issue by adding the
-Djdk.gtk.version=2
flag after line 9 in https://aur.archlinux.org/cgit/aur.git/tree/jabref.sh?h=jabref (as suggested in the related bug report https://bugs.openjdk.java.net/browse/JDK-8251240). This change also removes the “XSetErrorHandler() called with a GDK error trap pushed. Don't do that.” warning mentioned by ruiin in a previous comment.So far, I have not encountered any adverse side-effect from this workaround.