Generate license on demand

[infeo]

Summary

The EULA/license of the mac & windows installers are generated during the build process and are not static anymore.

Motivation

With every dependency update the content of the license file displayed in our app and installers changes. But for the changes to appear in our released artifacts, it needs to be commited. This causes a lot of boilerplate commits ("updating license" ) and additionally, during a release one can easily forget to update the license file.

This PR removes this commit necessity and generates the most up-to-date license on the fly during build of release artifacts for macOS and Windows.

[overheadhunter]

I support the general idea to automate this, but I have two remarks:

1. Since we now have three different .ftl files, the build step should be more specific than "Generate license", e.g. "Generate license shown in .dmg"
2. Please deduplicate licenseMerges.xml, if possible including the merges inside the pom.xml

[overheadhunter]

THIRD-PARTY.txt will be regenerated, so either add it to .gitignore or - and this is probably even cleaner - make sure it is generated in /target, which is preferred for generated resources but requires you to test it (both when starting from IDE as well as when building the jar)

Edit: Also, now the .ftl file that is used "inside the app" lies outside the app's sources. Which makes it even harder to know the exact purpose of those three competing templates.

[infeo]

Which makes it even harder to know the exact purpose of those three competing templates.

The three (actual four) templates are:

• generating a txt-file to be used inside the app
• generating a rtf-file used for the installers (windwos and mac)

In dc38942 @tobihagemann adjusted the existing rtf-template for macOS..

---

make sure it is generated in /target, which is preferred for generated resources but requires you to test it

Fixed in bcfba21. By default, the Third-Party file is placed inside target/generated-sources/license and later (automagically) copied to the target/classes/. From there it is accessible for the app and packaged into the jar.

[overheadhunter]

I just tested the .dmg from the CI build that you ran yesterday. While it works as expected and this is certainly not a regression, I'm asking myself if we could make the RTF a little more beautiful, as it currently looks like this:

Maybe make the project names clickable and hide the URLs?

[infeo]

Maybe make the project names clickable and hide the URLs?

This would only work for the EXE and DMG installer, the MSI installer does not allow clickable links afaik. Additionally, some links do not work (e.g. https://openjdk.java.net/projects/openjfx/javafx-base/). Another Idea would be to discard all links and just show the name of the project and the corresponding license.

[overheadhunter]

This would only work for the EXE and DMG installer, the MSI installer does not allow clickable links afaik.

My comment was about the .dmg file. Since we have separate templates for each use case...

Additionally, some links do not work (e.g. https://openjdk.java.net/projects/openjfx/javafx-base/). Another Idea would be to discard all links and just show the name of the project and the corresponding license.

Broken links are broken regardless of whether we use <a href="broken">displayname</a> or <a href="broken">broken</a>.

[overheadhunter]

please move or rename third-party.merges, since having this in the project root is confusing and there is no clue this is related to the license names and the Maven license plugin

[overheadhunter]

I'm really confused by the fact that some paths refer to a different base dir than others... This exceeds my review skills.

But since it works, I won't question it. 😄

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication