| 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: | 217 |
| Popularity: | 0.34 |
| First Submitted: | 2012-06-07 22:47 (UTC) |
| Last Updated: | 2026-02-03 22:03 (UTC) |
How about add an extra JavaOptions variable in launch script /usr/bin/jabref like this?
............
--module-path ${ROOT}/lib \
${JABREF_EXT_Options} \
--patch-module .............
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.
JABREF_EXT_Options='-Dglass.gtk.uiScale=144dpi -Djdk.gtk.version=2' jabref
I would suggest you to replace your archlinux-java-runtime with the packages official supports, it would make makepkg easier
@eyolf Thanks for the hint! CSL styles and locales are now included in 5.3-3.
There is a number of CLS entry preview files included in JabRef, which need to be added in the build stage by adding
cp buildres/csl/csl-locales/* src/main/resources/csl-locales/
according to the developers.
JabRef will need to add option dependency grobid in the later version (maybe). I would like to update it but seems an error presents. https://github.com/kermitt2/grobid/issues/817
Jabref 5.3 supports java 16
The following comment is now obsolete!
As MartinX3 pointed out, the current version of Jabref only builds with Java 14 or Java 15. This gives us two problems:
'java-runtime>=14' 'java-runtime<16' will also be satisfied if people have Java 11 and Java 16 installed.I therefore added a dependency on Java 15. To satisfy this dependency, you can install either of the following packages:
General error during semantic analysis: Unsupported class file major version 60
Because it uses gradle 6.5 and java 17 to build the software. But java 16 support got introduced with gradle 7.0
Their graddlewrapper got upgraded to 7.0 on May 3, 2021 So either this package should force a java version < 16 or containing a hotfix to update the gradle wrapper version.
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.
@juiin: Could you please test if you have the same problem with official build from https://www.fosshub.com/JabRef.html?dwl=JabRef-5.0-portable_linux.tar.gz ?
Pinned Comments
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/jabreflike this?So we can add the
-Djdk.gtk.version=2flag or-Dglass.gtk.uiScale=144dpiflag by cmdline, no need to edit/usr/bin/jabrefafter 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=2flag 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.