Reduce JabRef release size by not bundling WebKit for both Windows and Linux in all installers

[Sethur]

Since JabRef 3.x and JabRef 4.x had release sizes of around 35 to 55 MB while JabRef 5.x now vastly ramped this up to over 330 MB, I did some digging and found that this stems from:

1. At least for the windows build, there is quite a number of redundant api-ms-win DLLs both on the lowest level and in the main JAR-file. These are small though.
2. The JRE is now always bundled, there are no packages any more for users who want to stick with the Java version they have installed.
3. WebKit is bundled once for every OS, no matter the OS the release targets.

I would suggest to get rid of at least the WebKit redundancy. That would already take away some 80 MBs or so.

EDIT: I understand that JabRef 5.x is using the Java Platform Module System (JPMS) now, so developers are supposed to bundle the JDK with their apps, but a runtime directory of >210 MB while the size of the whole JDK 14 is only around 300MB seem suspicious to me.

[AEgit]

Probably duplicate of #5771

[tobiasdiez]

I think there is a problem with the merged module (build/jlinkbase/jilinkjars/JabRef.merged.module). It should only contain class files (and resources) and no dlls at all. This should indeed reduce the size of the installer by 150mb.

@koppor @LyzardKing do you have time to investigate this further?

[tobiasdiez]

The size of the installer should now be drastically smaller. Can you please check if the webkit issue is still present, and in case it is how you discovered that all os-specific versions are shipped. Thanks!

http://builds.jabref.org/master/

[ilippert]

JabRef 5.1--2020-07-29--00a4fb2
Linux 5.7.10-201.fc32.x86_64 amd64
Java 14.0.2

my perception is that the file size is smaller, and jabref runs as before.

[Sethur]

Looks good to me on Windows 10 as well.

If you now package only the truely required Java modules you can maybe even get the installer close to 100 MB again.

[koppor]

@Sethur Your wish is hard to do, since it is not a quick win. Quickly checking

jabref/build.gradle

Line 562 in 125a0c1

mergedModule {

, it seems that we already do that. I created a follow-up issue JabRef#444.

Maybe, our third party libraries (such as citeproc-java) need many modules (refs #6010).

A plugin system enabling the user to choose the featuers (s)he needs could help to reduce the sice. We removed the plugin system a few years ago by purpose to ease maintaining the plugins. We observed that most plugins were maintained for a year or so and then became incompatible with JabRef.