On Thu, 4 Aug 2022 17:00:38 GMT, Alex Kasko <[email protected]> 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
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java
line 491:
> 489: xml.writeAttribute("WorkingDirectory",
> INSTALLDIR.toString());
> 490: xml.writeAttribute("Advertise", "no");
> 491: xml.writeAttribute("Target", "[ARPMAINLAUNCHERLOCATION]");
I don't think you can replace `launcherPath` with `[ARPMAINLAUNCHERLOCATION]`.
`launcherPath` can reference any application launcher, i.e. it can be the main
or one of the additional app launchers.
-------------
PR: https://git.openjdk.org/jdk/pull/9751
