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
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
