Package Details: jabref 3.8.2-4

Git Clone URL: https://aur.archlinux.org/jabref.git (read-only)
Package Base: jabref
Description: GUI frontend for BibTeX, written in Java
Upstream URL: https://www.jabref.org/
Licenses: MIT
Submitter: Allan
Maintainer: Bevan
Last Packager: Bevan
Votes: 165
Popularity: 2.482640
First Submitted: 2012-06-07 22:47
Last Updated: 2017-11-18 22:04

Pinned Comments

Bevan commented on 2017-11-25 18:48

Since people keep commenting without reading through the comments before, here's a summary on why this is not updated to JabRef 4.0:

- JabRef 4.0 has a series of serious bugs (won't start, won't stop, will eat gigabytes of memory, ...).
- Most of these bugs are fixed in git by now but no release includes them yet.
- Applying these patches to this package would require everyone to rebuild the JAR file and install several build-time dependencies.
- People wanting to build the JAR from current git can use the jabref-git package here in AUR.
- There is no need to duplicate jabref-git in this package, it is already there. Use it.
- If you really really want to install JabRef 4.0 without these patches, take this PKGBUILD: https://github.com/michaellass/AUR/tree/jabref-4/jabref
- You can also download a prebuilt jar file from https://builds.jabref.org/master/
- Unfortunately these jar files are not archived which is why I cannot use them here.

Please refrain from asking why this has not been updated yet, why I do not apply patches from git, or when I will update this package. I will likely just ignore these questions in future.

Latest Comments

Huulivoide commented on 2017-12-10 15:13

Java 9 support would be nice. Just need to add '--add-modules java.xml.bind' to the command line if Java 9 is used.

Bevan commented on 2017-11-25 18:48

Since people keep commenting without reading through the comments before, here's a summary on why this is not updated to JabRef 4.0:

- JabRef 4.0 has a series of serious bugs (won't start, won't stop, will eat gigabytes of memory, ...).
- Most of these bugs are fixed in git by now but no release includes them yet.
- Applying these patches to this package would require everyone to rebuild the JAR file and install several build-time dependencies.
- People wanting to build the JAR from current git can use the jabref-git package here in AUR.
- There is no need to duplicate jabref-git in this package, it is already there. Use it.
- If you really really want to install JabRef 4.0 without these patches, take this PKGBUILD: https://github.com/michaellass/AUR/tree/jabref-4/jabref
- You can also download a prebuilt jar file from https://builds.jabref.org/master/
- Unfortunately these jar files are not archived which is why I cannot use them here.

Please refrain from asking why this has not been updated yet, why I do not apply patches from git, or when I will update this package. I will likely just ignore these questions in future.

d4muck commented on 2017-11-25 10:33

@Bevan when will you update to v4?

As I understood you wrote in your pinned comment that you solved both issues

Bevan commented on 2017-11-13 10:28

hseara: This looks to me like another instance of JabRef is running but has somehow crashed. Could you check for any running java instances with ps and kill them if they relate to jabref? Or, alternatively, reboot.

hseara commented on 2017-11-13 10:20

@Bevan Thanks your suggestion.

If you cannot open jabref and you get the following message:

11:16:21.281 [AWT-EventQueue-0] WARN org.jabref.logic.remote.server.RemoteListenerServerLifecycle - Port is blocked
java.net.BindException: Address already in use (Bind failed)
....
11:16:21.357 [AWT-EventQueue-0] INFO org.jabref.JabRefMain - Arguments passed on to running JabRef instance. Shutting down.

check for open instances of jabref and kill them.

Note: In multi-user system environments check the following issue: (https://github.com/JabRef/jabref/issues/2282)

Rhinoceros commented on 2017-10-25 10:29

@Bevan Ah, fair enough. Thank you for the explanation.

Bevan commented on 2017-10-25 08:44

Rhinoceros: Currently this package uses a prebuilt jar-file. To apply the changes, this would have to be changed to build the jar-file from source on PKGBUILD. That is possible for sure, but then again there is also a jabref-git package here in the AUR which pretty much does exactly that.

By the way: There are also prebuilt jar-files for the current git revision, but as far as I can see they only keep the most recent version on the server, so we cannot just use that: https://builds.jabref.org/master/

Rhinoceros commented on 2017-10-25 00:52

@Bevan Could you possibly backport the fixes into 4.0 instead? That's what normally happens on "official" Arch packages. You can get the fixes in patch format by appending `.patch` to the github urls that you list in your comment.

Zebra commented on 2017-10-07 17:16

Bevan: Reasonable enough. Thanks for maintaining!

Bevan commented on 2017-10-07 14:39

Zebra: Thanks for the feedback! The issue of not properly exiting is now fixed in git by the following three commits:
https://github.com/JabRef/jabref/commit/7ef2b3a01687648d7cdeca1498551426117bdf84
https://github.com/JabRef/jabref/commit/85363d077e42c28ffe7b3cac7cd854c8c8786273
https://github.com/JabRef/jabref/commit/fae290caa38aedbea3a2d093419e5ade4e62d620

I'd like to wait for a release including these fixes before pushing JabRef 4 to AUR.

The other issue of long starting time seemed to be an issue with leftover configuration from an older JabRef version, I could fix it by cleaning that up.

Ogion: Good point, JabRef 4 uses JavaFX now so that package is required. I will add it as a dependency.

Ogion commented on 2017-10-07 13:53

The aur Package from your github link works just fine for me, except for one thing: I had to install `java-openjfx` from the repo, before JabRef would actually run. You should probably add that to the Depends.

Zebra commented on 2017-10-07 10:44

Bevan: I testet your package just now (4.0.1) and cannot reproduce your issues. Stops at once. start up time is 3.5 seconds max.

Bevan commented on 2017-10-04 16:51

I have an update for JabRef 4.0 but I have serious issues with this version:
* JabRef does not quit, it stays active after exit waiting for some futex.
* On one machine JabRef needs many minutes to start, checking for duplicate aliases

If you want to try the new package, you can get it from here:
https://github.com/michaellass/AUR/tree/jabref-4/jabref

I will only push it to the AUR as soon as those major issues are solved.

Update: Problem no. 1 is now solved in git, problem no. 2 was a local issue with leftover data from older JabRef versions.

Bevan commented on 2017-08-24 08:14

koppor: Thanks for the updates! The new package release now explicitly calls java 8. I also looked into the .desktop file and the start script. The first has slightly different entries (Icon and StartupWMClass), so we cannot use it as is. But I changed the one provided by this package to be as close as possible. The start script provided here is very specific to Arch Linux as it calls archlinux-java to find out what JVM was selected by the user. So I'm not sure how valuable this is for upstream. It could be a starting point for a more universal start script that supports multiple distributions though.

koppor commented on 2017-08-18 08:26

JabRef will soon release version 4.0, which depends on JavaFX. I think, one has only to add "java-openjfx" to the list of dependencies.

The java-runtime should be set to precisely 8, as JabRef currently does not run at Java9: https://github.com/JabRef/jabref/issues/2594

koppor commented on 2017-08-18 08:24

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

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

@Rhinoceros: Thanks a lot! :)

Rhinoceros commented on 2017-02-02 23:30

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

@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

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

The license has changed to MIT since version 3.6.

Bevan commented on 2016-07-16 09:23

@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

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

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

chicomag commented on 2016-07-15 22:00

Please, add noextract=("JabRef-${pkgver}.jar") to the PKGBUILD, because makepkg is extracting the file, and this is not intended.

koppor commented on 2016-06-05 17:43

BibLaTeX mode is a file-based mode now. Switch the mode using File -> "Switch to BibLaTeX mode".

See also blog entry "April 19, 2016 – Release of JabRef 3.3" on http://www.jabref.org/blog/. (Sorry, currently no deep links possible).

Bevan commented on 2016-04-19 20:36

@Moneysac: Will push the new version in a moment but please use the "flag out-of-date" function in future.

Regarding the BibLaTeX mode: I think the option just moved. In Preferences->General you can change the standard mode from BibTeX to BibLaTeX.

Moneysac commented on 2016-04-19 11:25

Version 3.3 is available. This package does not provide the biblatex mode which is important for online references.

anntzer commented on 2016-02-04 08:58

jabref.sh should just force Java 8 (like the jabref-git package does: https://aur.archlinux.org/cgit/aur.git/tree/jabref.sh?h=jabref-git), otherwise jabref will fail to start on environments where Java 7 is the default.

zzjjzzgggg commented on 2016-01-11 13:54

It seems that the 3.2 version has been released. Shall we update this package now?

http://www.jabref.org/

gbc921 commented on 2015-12-31 10:35

The link is working now. The problem seemed to on Sourceforge, that did not have any mirrors available at that time.
Thanks,

gbc921 commented on 2015-12-31 00:13

Jabref source link on sourceforge is broken (even trying to download through the browser redirects to the initial page).
I'm not sure if it is related to Sourceforge or upstream, will contact dev and post any news here.

Francois_B commented on 2015-12-17 14:03

That sounds. I tried to remove java7 before asking you but I still have few packages that depends on java7, and one critical for me. They may work with java8. I'll contact the maintainers to check that.

note for others, small typo in the command path: /usr/lib/jvm/java-8-openjdk/jre/bin/java -jar /usr/share/java/jabref/JabRef-3.0.jar

Thank you.

Bevan commented on 2015-12-16 14:58

@Francois_B: It looks to me like you try running it with an older Java version. Please try running it by executing:
/usr/lib/jvm/java-8-openjdk/bin/java -jar /usr/share/java/jabref/JabRef-3.0.jar

For a permanent solution you may copy this into a custom start script in /usr/local/bin. But it may need adjustments on future JabRef updates.

A clean solution would probably be to remove Java 7 from your system instead, if you do not need it for some reason.

Francois_B commented on 2015-12-16 14:51

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

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

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

etienne commented on 2015-12-01 10:06

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

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

@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

@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

@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

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

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.

hseara commented on 2015-02-11 17:27

@magno everything works fine. The problem is in your side

==> Retrieving sources...
-> Downloading JabRef-2.10.jar...
% Total % Received % Xferd Average Speed Time Time Time Current
100 14.5M 100 14.5M 0 0 8937k 0 0:00:01 0:00:01 --:--:-- 26.7M
-> Found jabref.sh
-> Found jabref.desktop
==> Validating source files with sha1sums...
JabRef-2.10.jar ... Passed
jabref.sh ... Passed
jabref.desktop ... Passed

magno commented on 2015-02-10 16:54

==> Making package: jabref 2.10-2 (Tue Feb 10 16:52:07 WET 2015)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found JabRef-2.10.jar
-> Found jabref.sh
-> Found jabref.desktop
==> Validating source files with sha1sums...
JabRef-2.10.jar ... FAILED
jabref.sh ... Passed
jabref.desktop ... Passed
==> ERROR: One or more files did not pass the validity check!
The build failed.

If checksums are corrected with updpkgsums, the this error:
install: cannot stat ‘images/JabRef-icon-48.png’: No such file or directory

hseara commented on 2014-05-08 06:41

As web search is not required feature to use jabref and to avoid enforcing too many dependencies on installation I have added "gsettings-desktop-schemas" package as an optional dependency. Thanks for the tip, I did not realize as I have whole gnome installed.

anntzer commented on 2014-05-07 22:11

Please add a dependency on gsettings-desktop-schemas, as jabref core-dumps in its absence when trying to perform a web search.

Anonymous comment on 2013-04-05 04:28

users of non reparenting window managers such as dwm edit /usr/bin/jabref and add the line;

export _JAVA_AWT_WM_NONREPARENTING=1