jabref: JabRef not working on Arch Linux
- I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists
I am on an Arch Linux machine with the following:
~/JabRef> git branch -vv
* master 4add3167c [origin/master] Bump jaxb-xjc from 2.2.4-1 to 2.3.2 (#4956)
~/JabRef> pacman -Q | grep -i java
java-environment-common 3-1
java-runtime-common 3-1
~/JabRef> archlinux-java status
Available Java environments:
java-11-openjdk (default)
~/JabRef> java --version
openjdk 11.0.4 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11)
OpenJDK 64-Bit Server VM (build 11.0.4+11, mixed mode)
~/JabRef> git submodule status
e89e6b08b5c621a414fc7114f2129efac5f8c7d5 src/main/resources/csl-locales (heads/master)
83603de7a7f4652f8d1733f18f0c00be8974948e src/main/resources/csl-styles (heads/master)
Steps to reproduce the behavior:
gradle releaseJarorgradle shadowJar(see log)java -jar build/releases/JabRef-5.0-dev.jar
I have a failure with the following error:
Error: Could not find or load main class org.jabref.org.jabref.JabRefLauncher
Caused by: java.lang.ClassNotFoundException: org.jabref.org.jabref.JabRefLauncher
Log File
> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy
> Task :buildSrc:processResources NO-SOURCE
> Task :buildSrc:classes
> Task :buildSrc:jar
> Task :buildSrc:assemble
> Task :buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:test NO-SOURCE
> Task :buildSrc:check UP-TO-DATE
> Task :buildSrc:build
> Configure project :
Found module name 'org.jabref'
> Task :generateBibtexmlSource
> Task :generateBstGrammarSource
> Task :generateEndnoteSource
> Task :generateMedlineSource
> Task :generateModsSource
> Task :generateSearchGrammarSource
> Task :generateSource
> Task :compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
> Task :processResources
> Task :classes
> Task :shadowJar
> Task :releaseJar
Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.6.1/userguide/command_line_interface.html#sec:command_line_warnings
BUILD SUCCESSFUL in 37s
10 actionable tasks: 10 executed
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 57 (21 by maintainers)
Commits related to this issue
- Update Installation.md (#217) * Update Installation.md Updated the installation procedure for JabRef 5.x and on. Following the [comment](https://github.com/JabRef/jabref/issues/5299#issuecomment-5... — committed to JabRef/user-documentation by deleted user 5 years ago
- Squashed 'buildres/csl/csl-styles/' changes from 737ffa1505..30fb68eb20 30fb68eb20 Create BJEDIS-ABNT-Number (#5255) aafb868fac Update geochimica-et-cosmochimica-acta.csl (#5321) 60ba25f156 british-j... — committed to JabRef/jabref by Siedlerchr 3 years ago
Debian packages are fine to convert; that might be the more reliable way. The filename will remain stable as it has been for the jar, right?
It runs. This is the log:
@tobiasdiez IMHO, the last one is necessary and sufficient. Of course, Arch’s packaging system knows how to interpret/unpack
debandrpmpackages/archives so that we can just point to those files inPKGBUILDand do necessary directory changes (move parts to places which Arch suggests). However, atarortar.gzarchive is more generic and already enough. In a sense, you decide (as the developers) what files are needed for the application to run, pack them properly, and let the package maintainers do their work.debis good for your Debian-based users (Debian and *buntu distros) whilerpmwill cover RedHat-based users (RedHat, Fedora, etc.). In any case, if you want to let other distros use JabRef easily, youtar.gzin this case) that contains the self-contained cross-platform compatible binaries.For this reason, I think that
tar.gzis necessary and sufficient. A nice talk on this is here if you have some time to spend and smile 😄Thanks for the feedback. I will try to modify our Circle CI script to include that
It runs, and open a graphical installer that looks like the ones that Windows has. I canceled it when it wanted to write to system directories; which is not possible for a regular user and I would never execute a script like that with root.
I looked into the code and there seems to be no other option than running that installer. So, from my point of view, it’s of little use for linux users. I don’t see how to use it for packaging Jabref.
Ok, I think it should be sufficient to package only
build/image, i.e. changeto
This should reduce the size of the package considerably. (For example,
jlinkbaseis used duringjlinkbut not required afterwards.)As a side note, I will experiment with jpackage during the next days. This should give
rpmordebpackages for linux (not sure if they are also usable with arch).