I am using the Solus Linux Distribution and I have compiled Jabref v5.15 from source. The compile and build seems successful. Great so far.
However, when I attempt to start JabRef, I get the following error:
2024-07-21 15:54:18 [main] org.jabref.logic.journals.JournalAbbreviationLoader.loadRepository()
WARN: There is no journal-list.mv. We use a default journal list
2024-07-21 15:54:18 [main] org.jabref.Launcher.main()
ERROR: Unexpected exception: java.nio.file.FileSystemNotFoundException
at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.getFileSystem(ZipFileSystemProvider.java:156)
at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.getPath(ZipFileSystemProvider.java:142)
at java.base/java.nio.file.Path.of(Path.java:209)
at org.jabref@5.15/org.jabref.logic.protectedterms.ProtectedTermsParser.readTermsFromResource(ProtectedTermsParser.java:33)
at org.jabref@5.15/org.jabref.logic.protectedterms.ProtectedTermsLoader.readProtectedTermsListFromResource(ProtectedTermsLoader.java:121)
at org.jabref@5.15/org.jabref.logic.protectedterms.ProtectedTermsLoader.update(ProtectedTermsLoader.java:48)
at org.jabref@5.15/org.jabref.logic.protectedterms.ProtectedTermsLoader.(ProtectedTermsLoader.java:35)
at org.jabref@5.15/org.jabref.Launcher.main(Launcher.java:78)
Any thoughts on what this issue could be? I am not sure how to determine what File, Path, or Filesystem it is looking for.
To look into the issue, I would need a VM with the same setup. May I ask if you could create a Vagrant file creating a Solus Linux VM? Similar to the Vagrant files for Fedora and Ubuntu available at jabref/scripts/vms at main · JabRef/jabref · GitHub.
If I compile with “./gradlew run” it works. So that is great.
But when I use the Solus OS build tools (solbuild) to create a package I still get the error i mentioned above.
A bit more info for you - I am a very noob trying to contribute to the Solus OS project and this is my first time trying anything like this. So there is so much newness for me, but i’m leaning in trying to figure it out. They have an open issue related to Jabref packaging which I am trying to address. Of course Solus is a bit unique and doesn’t use rpm’s or deb’s. Currently Solus has Jabref 5.5 packaged and that works - I was able to re-package it successfully. So I am going to continue digging in on Jabref 5.15.
I looked deeper into the how Solus was trying to build this and it is using the standard gradle assemble command. I changed this to ./gradlew assemble, and then ./gradlew build and both completed successfully but I am still getting my original error. So I think the issue is in a subsequent step of the solbuild process which I am still trying to figure out.
But this leads me to another question - If I use ./gradlew build (or assemble) how would I then be able to run Jabref? What environment vars would I need to set or parameters would need to be passed to the startup? …and what is the startup command?
If you could point me to documentation that would also be helpful. I’m trying to learn several different things in order to piece this together.
For the snap and flatpak build we use the linux portable versions. Have you tried using those as well? Otherwise we use ./gradlew jpackage to build a native JabRef package, this includes the jdk
Edit// Did you check out the submodules? git submodule init && git submodule update?
But regarding the error, this seems to be something else, I will try to create a fix for this later
Hell Christoph (or anyone)_ - Did you have a chance to consider this issue any more?
I am still getting a similar error after trying a few more things. So I am not sure.
Are you able to successfully build from source and then run?
I am still unable to determine what I am doing wrong.
Thank you for the offer. I might have go down that route and try to create one for you. After compiling the source from the latest main branch as also suggested, I got a different error. I just tried that between real work a few days ago. I need to get back to it and see if it was just me I didn’t have time to look at it too much at that point, but I’ll try to dig into it again this weekend. If I can’t make any progress I’ll take you up on the offer and try to create a new Vagrant file for you.
Thank your both again for your feedback and willingness to help. I’ll keep you updated.
I thought I would try again tonight and build it manually outside of the Solus Packaging tools. (maybe that is the actual problem).
I am following the Build from Source instructions from here.
The ./gradlew assemble was successful. But the ./gradlew jlink was not. Basically it gave this error: Error: java.io.IOException: Cannot run program “objcopy”: error=2, No such file or directory
Here is the full output if you want to take a look. It seems like I must be missing something.
Thank you both very much for your patience and advice. I am able to get this built now. I still need to address a couple things in actual packaging. But I can now build it and run it.
I do appreciate your help.
And actually, this is a great application. I didn’t know about it until I started down this packaging rabbit hole. But I have research project where I can use this. It is very applicable. Thanks again !!!
I hope you don’t mind me continuing this topic a bit more. As I mentioned, now that I know I can build and run, I was looking further into the actual packaging for Solus.
Following the build instructions it indicates that the output is in build/image. I can run the application from this location.
However, there is also a directory called build/distributions -which does have a linux tar file. If I try to extract that and run from there, I get the original error that started this thread: “ERROR: Unexpected exception: java.nio.file.FileSystemNotFoundException”
I could definitely just package up the build/image directory structure. It seems to have many more things than build/distributions, but then also the tar extract has many different things that the image dir doesn’t have. But which way would you suggest?
Just based on the name, I am probably (incorrectly) assuming that “distributions” would also have everything needed to run but already zipped up.
I would rather not package up lot of extra stuff from the image directory if it is not needed at run time. I’m obviously not a developer, but for example there are things in the image/bin directory like jimage, jlink jpackage, etc., which doesn’t seem like would be required at runtime.
Any recommendations on how much of the image directory (or distributions) directory I should use for my packaging requirements?
So I downloaded a deb and a rpm to see what the “experts” and included and they basically had the image directory. Including the files I had highlighted above. So I am probably over-thinking it. I’ll package it up similar to what is included for the other linux distributions. I’ll let you know how it goes.
Thanks again for your support.
Unfortunately, I am back and I am still on this general topic.
My pull request for packaging this was reviewed and there is a question about the Java Runtime environment that I bundled and which is included as part of the build/image directory. (which you have documented)
Although this works, the preference from the maintainers is to avoid this if possible.
What is the difference between the build/distributions content vs the buld/image content?
Is there way way to run JabRef via only the content from the distributions folder?
Actually this is where my initial problem started. If I try to run via the content in the distributions folder I get the original error of this thread: Unexpected exception: java.nio.file.FileSystemNotFoundException
I did a little debugging and it is looking for “/protectedterms/months_weekdays.terms”
JabRef is a modularized app that uses jlink to create a custom runtime:
jlinkis a tool that generates a custom Java runtime image that contains only the platform modules that are required for a given application.
Such a runtime image acts exactly like the JRE but contains only the modules we picked and the dependencies they need to function. The concept of modular runtime images was introduced in JEP 220.
The idea is that you no longer need to install any JDK/JRE on your system and thus avoid having troubles with programs using different java versions etc.
I didn’t have time to look at it too much at that point, but I’ll try to dig into it again this weekend. If I can’t make any progress I’ll take you up on the offer and try to create a new Vagrant file for you.
