On Thu, 4 Aug 2022 17:00:38 GMT, Alex Kasko <aka...@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 FYI: AddLShortcutTest test covers additional launchers with optional shortcuts. ------------- PR: https://git.openjdk.org/jdk/pull/9751
