RFR: 8291915: jpackage: use multiple Features in MSI installer

[Alexey Semenyuk]

On Thu, 4 Aug 2022 17:00:38 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change splits existing single Feature `DefaultFeature` into 3 different feautures:
> 
>  - `DefaultFeature_Files`: application and runtime files
>  - `DefaultFeature_Shortcuts`: application Desktop and Start Menu shortcuts
>  - `DefaultFeature_FileAssociations`: File Association components
> 
> These 3 Features are nested under the existing top-level Feature.
> 
> Currently the use of File references in Shortcuts and FileAssociations causes ICE69 MSI warnings like this one:
> 
> 
> warning LGHT1076 : ICE69: Mismatched component reference. Entry 'reg12F3244EB2A37CCDB282E815ADFD174A' of the Registry table belongs to component 'cprogid9f99d1ff794e3df6bee07ba710a5501a'. However, the formatted string in column 'Value' references file 'file9846f81ce394345095918903022c1072' which belongs to component 'cfile9846f81ce394345095918903022c1072'. Components are in the same feature.
> 
> 
> This warning seems to be completely harmless when the File, referenced from the Shortcut or Verb elements, belongs to the same Feature. Though, this warning becomes and error when the File belongs to other Feature.
> 
> To solve this problem for Shortcut and Verb - install-time `ARPMAINLAUNCHERLOCATION` is introduced, that points to the main application launcher in a form: `[INSTALLDIR]launcher.exe`. With such property no `ICE69` warnings are raised.
> 
> It appeared that such solution is not possible for the Shortcut Icon reference, that points to the icon file. Instead this icon file is additionally included into Shortcuts ComponentGroup. This way `ICE69` warning is raised (as before) instead of an error.
> 
> Added test uses `ADDLOCAL` options to test the installation of Features separately. To pass this option to installation handlers I've added it to `JPackageCommand`, this seemed to be the easiest way to pass it  without changing handler signatures.
> 
> It appeared, that default checks in `PackageTest` assume "all-or-nothing" installation scenario and contain non-trivial logic to determine which checks (files, desktop, FA) to run. I've iterated multiple times on this logic adding more flags (that can be controllable from the test itself) and ended up with helper methods in `WindowsHelper` that checks install arguments on `JPackageCommand` assuming `ADDLOCAL` and known Feature names there. This solution, while being the simplest of all attempts, is quite clunky, it may be better to introduce more fine-grained control over these checks from the test itself (such change is potentially disruptive to the test-suite).
> 
> It was also discovered, that `ADDLOCAL` option is not supported with `unpack` mode, and separate Features are not currently checked in this mode.
> 
> Testing:
> 
>  - `WinFeaturesTest` that installs and checks Features one by one
>  - `FileAssociationsTest` and `WinShortcutTest` test runs with `install` enabled

update

-------------

PR: https://git.openjdk.org/jdk/pull/9751