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

[Alex Kasko]

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

Alexey, thanks for your comments! I think the point on multiple launchers is a serious issue, for some reason I've assumed that these references are only done for the main launcher. I will experiment with multiple launchers and will update the patch.

A number of more general questions on multiple Features support:

1. Would the following logic be acceptable:

 - "Files" feature is expected to be installed always (should have `Absent="disallow"`)
 - all other features ("Shortcuts", "FileAssociations", prospective "RegistryEntries") are independent of each other, but expected to be installed only when "Files" is installed too
 - while `Absent="disallow"` will enforce "Files" selection in prospective FeatureTree GUI, it won't enforce it in CLI - any set of Features can be selected for installation with `ADDLOCAL`; can we assume, that situation when "Files" is not installed is considered "unsupported" and doesn't need to be taken into consideration in the impl or covered with tests?

2. Currently "Files" feature is nested under top-level feature. Would it be more appropriate to move "Files" contents into top-level feature?

3. Besides actual FS files, currently "Files" feature contains a "crm_rf" (`util:RemoveFolderEx`) component. Should this component be part of "Files" or moved to a separate feature ("Uninstall Actions" or something like this)?

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

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