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 .. 15 16 17 18 19 20 21 22 23 Next › Last »

koppor commented on 2017-08-18 08:24 (UTC)

JabRef now also tries to maintain a .desktop file. See https://github.com/JabRef/jabref/blob/master/buildres/snapcraft/jabref.desktop. Maybe, that file can be used? We can also place it somehwere else in the src tree. Maybe directly at buildres/? The JabRef team is also often asked to provide a jabref.sh (see https://github.com/JabRef/JabFox/issues/19). Maybe, you could provide your jabref.sh as pull request to JabRef's main repository? I would propose the scripts/ folder as the location.

n-st commented on 2017-06-03 20:40 (UTC)

JabRef has recently had its license updated. The PKGBUILD contains the checksum of the v3.8.2 license, but downloads the license from the master branch (currently v4.x beta), so the checksum test fails. Try this patch as a fix: http://x7f.uk/jamaxa.patch

Bevan commented on 2017-02-03 14:14 (UTC)

@Rhinoceros: Thanks a lot! :)

Rhinoceros commented on 2017-02-02 23:30 (UTC)

Thanks @Bevan. Here's a replacement to jabref.sh that works for me. It checks if java 8 is selected as the default java, and if not, reverts to your original script of selecting the alphabetically-last java. This *should* keep everyone happy! :) #!/bin/sh if [[ "$(archlinux-java get)" == java-8-* ]] then exec /usr/bin/java -jar /usr/share/java/jabref/JabRef-VERSION.jar "$@" else # Force usage of latest java version JVM_PATH=$(find /usr/lib/jvm/* -maxdepth 0 -type d | sort | tail -n1) exec $JVM_PATH/jre/bin/java -jar /usr/share/java/jabref/JabRef-VERSION.jar "$@" fi

Bevan commented on 2017-02-02 21:37 (UTC)

@Rhinoceros: I guess you are right. It's difficult to find something here to make everybody happy but I will try soon.

Rhinoceros commented on 2017-01-23 00:16 (UTC)

It looks like jabref.sh selects the latest version of java installed, rather than following the default, as set in archlinux-java. This can cause problems, because it selects the buggy version in my case [1]. I understand that jabref needs java 8, not java 7, but it might be worth following archlinux-java if a version 8 is selected, otherwise defaulting to one of the version 8s. Hard-coding the version seems wrong IMO. [1] https://bugs.archlinux.org/task/52625

danmc commented on 2016-12-15 15:57 (UTC)

The license has changed to MIT since version 3.6.

Bevan commented on 2016-07-16 09:23 (UTC)

@antony: This issue occured when there was already a "src" directory lying around from the last build. I now changed the PKGBUILD to only extract from the JAR what is needed which solves this issue.

anntzer commented on 2016-07-16 01:16 (UTC)

Cuurently fails to build: ==> Extracting sources... -> Extracting JabRef-3.5.jar with bsdtar com/: Can't replace existing directory with non-directory <elided> META-INF/maven/org.apache.httpcomponents/httpcore-nio/: Can't replace existing directory with non-directory bsdtar: Error exit delayed from previous errors. ==> ERROR: Failed to extract JabRef-3.5.jar Aborting... :: failed to build jabref package(s)

Bevan commented on 2016-07-15 22:20 (UTC)

@chicomag: The .jar file needs to be extracted because this is where we get the application icon get from, so extracting is actually intended. I don't see any disadvantage of this, because we package only what is needed (jar file, icon, start script, desktop file).

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