Package Details: jabref 5.15-5

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)

Dependencies (4)

Required by (0)

Sources (11)

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

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.

Latest Comments

« First ‹ Previous 1 .. 17 18 19 20 21 22 23 Next › Last »

Francois_B commented on 2015-12-16 14:51 (UTC)

I have this error: $ jabref Exception in thread "main" java.lang.UnsupportedClassVersionError: net/sf/jabref/JabRefMain : Unsupported major.minor version 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482) Anybody has an idea?

anntzer commented on 2015-12-15 19:34 (UTC)

In order to make this work even when the default Java installed is Java7, you may want to apply the following solution to jabref.sh: https://wiki.archlinux.org/index.php/Java#Launching_an_application_with_the_non-default_java_version

Bevan commented on 2015-12-01 10:08 (UTC)

@etienne: Ah, yet another Java application that needs this hack. Update will come in a minute. Thanks! :)

<deleted-account> commented on 2015-12-01 10:06 (UTC)

On Gnome Shell the starter of Jabref is not the same as the one of the opened application, so I get two Jabref symbols in the starter panel when running. To avoid this, I simply had to add the line StartupWMClass=net-sf-jabref-JabRefMain to my jabref.desktop. To keep the change I copied /usr/share/applications/jabref.desktop to ~/.local/share/applications/ and applied the modification there.

Bevan commented on 2015-12-01 09:50 (UTC)

It seems like JabRef 3 deliberately requires Java 8: http://sourceforge.net/p/jabref/mailman/message/34657526/ I will change the dependencies accordingly. If people would rather stick with Java 7 they can get the old PKGBUILD for JabRef 2.11.1 here: https://aur.archlinux.org/cgit/aur.git/tree/?h=jabref&id=7cab7b0cfdc458d429f39fa80583eb22da48d08d

bayone commented on 2015-12-01 01:30 (UTC) (edited on 2015-12-01 01:36 (UTC) by bayone)

@Bevan: jabref 3.0 crashes with jre7-openjdk. I had to switch to jre8-openjdk to get it to work. It also says on sourceforge it requires java 1.8 (jre8).

Bevan commented on 2015-07-16 20:14 (UTC)

@torta: sourceforge.net seems to have problems with their load balancing at the moment. You may replace the first entry in source by http://ufpr.dl.sourceforge.net/project/jabref/jabref/2.10/JabRef-2.10.jar to work around this temporarily.

torta commented on 2015-07-16 20:06 (UTC)

@magno, i'am having the same problem. How do you solve it? ==> Validando las fuentes con sha1sums... JabRef-2.10.jar ... HA FALLADO jabref.sh ... Aprobado jabref.desktop ... Aprobado ==> ERROR: ¡Uno o más archivos no superaron el control de validación! ==> ERROR: Makepkg no ha podido compilar jabref.

hseara commented on 2015-07-11 18:12 (UTC)

I had little time to deal with the AUR4 migration lately. Therefore, I do not mind if you want to maintain it from this point on.

Bevan commented on 2015-07-08 12:21 (UTC)

I just migrated this package to AUR4. If the original maintainer (hseara) wants it back I will transfer the ownership back of course. Otherwise I will keep maintaining it.

« First ‹ Previous 1 .. 17 18 19 20 21 22 23 Next › Last »