Jabref: Add file associations when installing

[tobiasdiez]

Latest development version does not associate bib files with JabRef (using Windows installer, but probably applies to Linux and Mac as well).

jpackage has the following option:

--file-associations — Path to a Properties file that contains list of key, value pairs (absolute path or relative to the current directory). The keys "extension", "mime-type", "icon", and "description" can be used to describe the association. This option can be used multiple times.

The documentation is a bit sparse at this point. Probably needs a bit of experimentation using different formats. Relevant part of the build script: https://github.com/JabRef/jabref/blob/9fd49bcb2560a46c7f319dd59fdd9a58845415ce/build.gradle#L565-L607

[UltimaBGD]

Can I poke around at this?

[tobiasdiez]

Welcome @UltimaBGD! Feel free to work on this issue. Also have a look at our contribution guide and feel free to drop by in our developer chat if you have questions!

[UltimaBGD]

As of now, I have tried to input the
--file-associations
option within the Installer Options list with a path to a properties file. As of now it seems to be locating the file, but fails building with a null pointer exception for reasons I am not sure of.

[tobiasdiez]

Thanks for having a look at this. Could you please post the full exception details here, then I'll have a look.

[UltimaBGD]

Sorry for the late response, I will post a write-up of my attempts and the scan from Gradle, and we will see if I am missing something obvious. I will try to get to it later today.

[UltimaBGD]

Okay, so I added an additional line to the installerOptions for Windows following the same format as the other file paths.

I know it is able to locate the properties file I was creating as I tried specifying an incorrect pathname a number of times, and it would give an error stating that the filename could not be found in addition to the null pointer exception. When adding --file-associations is the only time it gives that null pointer exception. Had I removed it and changed nothing I am able to build an MSI successfully. I have tried a few pathnames, but as stated before it does seem to actually be locating the file. I do not know if it is the properties file itself or something with the command that is causing this at the moment.

Running the jpackage command through the scan option produces this:

https://scans.gradle.com/s/277hsazt3rx6w

It does note that it is a configuration problem, but I am not sure wherein the issue is. I could honestly be missing something really obvious.

[Siedlerchr]

I found this bug report which seems to be related:
https://bugs.openjdk.java.net/browse/JDK-8232935?filter=37667

[UltimaBGD]

So it seems to be isolated to when no mimetype is provided. I will check it out.

[Siedlerchr]

Note that there has been a new release of the jpackage tool (v64)
Build 14-jpackage+1-64 (2019/10/28)

Edit:// After the update oft the jpackage, the windows build fails. It would be cool if you could look into that as well: https://github.com/JabRef/jabref/runs/278995661

[UltimaBGD]

On the version we are currently on, that bug report is indeed the same cause. Adding a mime-type does allow for the build to continue.

[Siedlerchr]

@UltimaBGD Thanks for your testing and your digging into the issue! It would be reall nice if you could prepare a Pull Request to fix this issue and to fix our build.

[UltimaBGD]

I'm poking around with the new version to see if I can figure out what's making it go wrong, after that I can make a PR.

[UltimaBGD]

I poked around a bit with the version update, and I'm not too sure what's going on. It seems like there's an issue in the windows script Jabref-post-image.wsf. This is in the build folder, so this file does seem to be generated. It could be that something else doesn't have support for the newest version, or something else entirely. Unfortunately I am going to be busy for a couple of days and won't get to look at it a bit more in-depth for a little bit. Just wanted to give a bit of an update.

[Siedlerchr]

Hi, thanks for investigating. The wsf script is located under the buildres folder.

[UltimaBGD]

Oh, I see, it ultimately gets moved. So, what I did find is that in the script it opens

var wxsFilePath = installerConfig + "JabRef.wxs";

This .wxs file, which according to the installer config, should be here:

var jabRefRoot = fileSystem.GetFolder(".").ParentFolder.ParentFolder.ParentFolder.ParentFolder.Path; var installerConfig = jabRefRoot + "/build/installer/config/";

This is, for whatever reason, not the case in the new version. It does exist in the old version, as it seems to get moved to this spot and then picked up by the script, but when the new version errors running this script and exiting with code 1, I believe it is because it cannot find this file.

If this is a file you know the location of, please let me know.

The .wxs is a wix file, which does explain why this is a windows only problem, and most likely only for the .msi installers.

As a test, I copied the JabRef.wxs from a previous compilation and saved it elsewhere in the project, and redirected the script to look to that file. It compiled successfully. So:

The issue is the sudden disappearance of the JabRef.wxs files, as it seems to not be created or moved there (unsure if it's preexisting) and the script cannot find it. My solution is a workaround at best there.

[tobiasdiez]

Thanks for digging into this! There were some recent changes to how the main.wxs file (which is the general version of JabRef.wxs) is treated: https://hg.openjdk.java.net/jdk/sandbox/rev/bc43733cd5cf
Probably, this contains some bugs leading to the error now.

As this is very critical, I would propose we add the wxs file for now and hope the bug is fixed upstream in jpackage. @UltimaBGD could you please create a PR for this? Thanks!

[UltimaBGD]

I will have to do a bit more testing as I tried running the .msi file and it ends with error code 2343.

The build definitely runs, but for the time being, the MSI installer is broken. I will look more around at that.

In addition, just as an update as to the original point of this issue, I have not implemented the file associations yet as I thought this would take precedence, and in the event there were any internal changes I should test on the new version. I have learned some confusing things about it though.

[Siedlerchr]

Thanks for your ongoing investigation!
Seems like the jdk people fixed that with a recent commit https://hg.openjdk.java.net/jdk/sandbox/rev/920f6770d71c

[UltimaBGD]

Okay, so what should the recommended course of action be for now?

I can still ensure the windows build passes for now with a PR, or we can wait.

[tobiasdiez]

You can also try to put this file https://hg.openjdk.java.net/jdk/sandbox/file/bc43733cd5cf/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs into buildres/windows (maybe renamed to Jabrex.wxs).

[tobiasdiez]

If this is really the fix, then temporarily disabling win-dir chooser should also work, right?

[UltimaBGD]

I'll test both of those and get back to you in a bit

[UltimaBGD]

Disabling win-dir chooser seems to prevent the MSI from opening. It gives me no other information other than a hard crash.

Running it with the new file still gives error 2343.

[UltimaBGD]

More testing, I found out this new version does create a main.wxs file! I moved the script to use that, except now this error occurs

java.io.IOException: Command [C:\Program Files (x86)\WiX Toolset v3.11\bin\light.exe, -nologo, -spdb, -ext, WixUtilExtension, -out, C:\Users\Altima\Desktop\gitDocuments\jabref\build\distribution\JabRef-5.0.0.msi, -ext, WixUIExtension, -loc, C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\config\MsiInstallerStrings_en.wxl, -b, C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\config, C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\wixobj\main.wixobj, C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\wixobj\bundle.wixobj]in C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\images\win-msi.image\JabRef exited with 92 code

The exit code 92 does mean there is a duplicate symbol. I'm going to compare the .wxs from last version and this version and see if I can tell what the issue may be.

Running that command in the command line itself provides me with these results
C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\config\main.wxs(86) : error LGHT0091 : Duplicate symbol 'Component:RegistryJabFoxEntries' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique. C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\config\main.wxs(86) : error LGHT0092 : Location of symbol related to previous error. C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\config\main.wxs(86) : error LGHT0091 : Duplicate symbol 'Feature:JabFox' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique. C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\config\main.wxs(86) : error LGHT0092 : Location of symbol related to previous error. C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\config\main.wxs(86) : error LGHT0091 : Duplicate symbol 'Property:ARPPRODUCTICON' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique. C:\Users\Altima\Desktop\gitDocuments\jabref\build\installer\config\main.wxs(86) : error LGHT0092 : Location of symbol related to previous error.

With this in mind, I may be able to edit the scripts to fix this error.

[UltimaBGD]

So: Today I learned the hard crashes were NOT crashes. Just when the win-dir chooser is not set, it doesn't open up in a way I expected. That DID work.

That being said, still testing this to see if we can get the directory chooser back, and if so I will clean my workspace entirely and redo the work and prep for a PR.

[UltimaBGD]

Installer still closes with 2343.

So, for the other PR, I can either change the script to point to "main.wxs" when it is generated or I can take that file, rename it to JabRef.wxs, and place it into the buildres folder and tell the script to look there instead. Is there any preference to the approach?

[tobiasdiez]

Good job! I would prefer to put the file in the buildres folder.

[UltimaBGD]

Okay, there is a PR up to support the latest version of Jpackage, which got merged.

I will get back to the file associations in a few days.

[UltimaBGD]

My apologies, it seems like I won't have the time to get back to this for a week or two. If it is still an issue when I have time, I will work on it. Hopefully all I wrote in here thus far will provide help if anyone else works on it.

[tobiasdiez]

No problem! Thanks for your good work on this issue (and to get the installer working again).

[LyzardKing]

In the linux launcher I removed the properties file since it only had the reference to the bib resource
(MimeType=text/x-bibtex) and it was only used in linux at the time.
I had introduced it in the attempt to build the deb/rpm info with jpackage,
but it seemed to me to be confusing to have an additional file for a single line declaration.
If it ends up being shared with the windows (and mac?) builds it can be reintroduced!
Is this a supported strategy by upstream jpackage?

[UltimaBGD]

The properties file should be able to be shared amongst the installers considering the only information in it should be the mimetype, extension, icon and description. If the icon is different across operatin systems, then potentially not.

[LyzardKing]

Is it not only for information on what it should open?
I might have misunderstood the description on https://jdk.java.net/jpackage/
but it seemed to me that the properties file should contain associations to allow launching the application.
In the case of jabref this would be mimetype and extension..
I'm not sure about the other two..
I thought they were other associations..
Or they could be an icon/description set to the file that has the mimetype/extension?
I guess that in the last case everything could be shared..
@tobiasdiez

[UltimaBGD]

I think the icon would ultimately be what you see when you have the association made, like how you see a small notepad when a txt file is associated to open in notepad.

[LyzardKing]

Yes, so the last thing I said and thought of.. I had dismissed it too soon :)
In that case I think that it could be useful to share a single file, since I believe all the parts should be common to the different systems..

[LyzardKing]

Windows could need an .ico instead of a .png though..
so our dream of a shared file might be short lived..
I seem to remember macos accepting png for icons..but this was back in the olden days...
A test seems like a good idea!

[tobiasdiez]

The best "documentation" I could find are the jpackage unit tests

• File format: https://hg.openjdk.java.net/jdk/sandbox/file/fbaf2e6402ad/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/FileAssociations.java
• Icon path: https://hg.openjdk.java.net/jdk/sandbox/file/fbaf2e6402ad/test/jdk/tools/jpackage/share/FileAssociationsTest.java references TKit.ICON_SUFFIX which according to https://hg.openjdk.java.net/jdk/sandbox/file/fbaf2e6402ad/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java is indeed depending on the OS. This suggests that one need a properties file for each OS.

[tobiasdiez]

@UltimaBGD Thanks for your investigations. With your help, I was now able to fix this issue. (There still might be some problems with the file icon on Linux...)

[UltimaBGD]

I'm glad I was able to help!