Arch Linux User Repository

@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.

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

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.

@Bevan Great, thanks for your response and for your work on this package :-). That all sounds sensible.

The package now only contains Java resources again and no JRE.

For now, it requires jdk-openjdk in version 13. I will make this more flexible in future, since JabRef seems to work fine with JDK 14 as well.

billypilgrim: This package is not supposed to ship the prebuilt portable version for long, so no, it is not becoming a jabref-bin.

I would love to get rid of the JRE. If this is not possible, I at least would like to build the package from scratch to use our own JRE instead of someone's. This is however a non-trivial process. Pull requests are always welcome :)

Since people started asking if this package is still maintained at all, I decided to temporarily distribute the portable version until a better solution is found.

@Bevan Thanks for updating this to v5. The only issue is that I think this package should be called jabref-bin as per the standard AUR naming conventions. It would be nice not to have an entire bundled JRE with the package.

Ah yes good point. I always forget "the downloaded source filename must be unique" in my PKGBUILDs. Thanks for the reply.

Rhinoceros: The plan is to rename the downloaded files to include package name and version. So with an update of the package, they get new names and old versions lying around are not used. See https://wiki.archlinux.org/index.php/PKGBUILD#source

@Bevan Thank you for maintaining this package! Out of interest, how can you actually prevent this issue? I had similar errors in yay, but as you say, it was just the previous version, so I cleanbuilt. However, as a package maintainer, can you actually force a re-download by the users?

blegat: You likely still have an old version of LICENSE.md lying around in the folder where makepkg is running. Removing it should solve the problem.

I will make the package more robust against this issue in future.

I just tried to update and I got:

==> Validating source files with sha256sums...
    JabRef-5.0-portable_linux.tar.gz ... Passed
    LICENSE.md ... FAILED

Sorry that the update to JabRef 5 takes a while. I'm planning to do it within the next couple of days.