Currently, jpackage can run in verbose or quiet mode, controlled by the "--verbose" option.

In quiet mode, it produces no output and will only print an error message if it fails.

In verbose mode, it produces output as it progresses through different phases of packaging. It prints out command lines and the output of external commands it invokes. Overall, the verbose mode provides enough information to understand what jpackage is doing. However, some aspects of jpackage execution are not covered even in verbose mode. They are:
 - What files does jpackage unsign (macOS specific) before signing
 - Some files jpackage signes (macOS specific)
 - WiX toolkit lookup
 - Detect DEB or RPM packaging availability

Adding these details to the verbose output will clutter it. Quiet mode should remain quiet. As a solution, we can direct these details to a log through java.lang.System.Logger API.

It would be handy if jpackage outputs a summary of the bundle it will produce. It already does in verbose mode, but these details are scattered throughout the output rather than grouped at the beginning.

E.g.: MSI packaging output:
---
[05:21:36.126] Detected [candle.exe] version [3.11.1.2318].
[05:21:36.126] Detected [light.exe] version [3.11.1.2318].
[05:21:36.133] WiX 3.11.1.2318 detected. Enabling advanced cleanup action.
[05:21:36.148] Running jlink
[05:21:39.362] Command:
    jlink ... --strip-native-commands --strip-debug --no-man-pages --no-header-files
[05:21:39.363] Output:
    WARNING: Using incubator modules: jdk.incubator.vector
[05:21:39.364] Returned: 0

[05:21:39.382] Using default package resource JavaApp.ico [icon] (add SimplePackageTest.ico to the resource-dir to customize).
[05:21:39.386] Using default package resource WinLauncher.template [Template for creating executable properties file] (add SimplePackageTest.properties to the resource-dir to customize).
[05:21:39.614] Using default package resource os-condition.wxf (add os-condition.wxf to the resource-dir to customize).
[05:21:39.617] Preparing MSI config: test\output\SimplePackageTest-1.0.msi.
[05:21:39.617] MSI ProductCode: 3d260fd2-5648-30a9-90fc-0ae56cbd77bf.
[05:21:39.617] MSI UpgradeCode: 4d6f28ae-2685-36b0-9f72-59d937886037.
[05:21:40.017] Using default package resource main.wxs [Main WiX project file] (add main.wxs to the resource-dir to customize).
[05:21:40.018] Using default package resource MsiInstallerStrings_de.wxl [WiX localization file] (add MsiInstallerStrings_de.wxl to the resource-dir to customize).
[05:21:40.019] Using default package resource MsiInstallerStrings_en.wxl [WiX localization file] (add MsiInstallerStrings_en.wxl to the resource-dir to customize).
[05:21:40.020] Using default package resource MsiInstallerStrings_ja.wxl [WiX localization file] (add MsiInstallerStrings_ja.wxl to the resource-dir to customize).
[05:21:40.020] Using default package resource MsiInstallerStrings_zh_CN.wxl [WiX localization file] (add MsiInstallerStrings_zh_CN.wxl to the resource-dir to customize).
[05:21:40.021] Using default package resource overrides.wxi [Overrides WiX project file] (add overrides.wxi to the resource-dir to customize).
[05:21:40.070] No default package resource [script to run after application image is populated] (add SimplePackageTest-post-image.wsf to the resource-dir to customize).
[05:21:40.070] Generating MSI: test\output\SimplePackageTest-1.0.msi.
[05:21:40.073] Running candle.exe
[05:21:40.246] Command [PID: 58440]:
    candle.exe -nologo ...
[05:21:40.246] Output:
    main.wxs
[05:21:40.246] Returned: 0
---

MSI Product and Update Codes are important properties and should be easy to access, but they are buried in the output and hard to find. Besides, they are not available in quiet mode.

RPM packaging output:
---
[04:43:04.802] Running dpkg
[04:43:04.805] Running rpm
[04:43:04.821] Command [PID: 359047]:
    rpm -q rpm
[04:43:04.821] Output:
    rpm-4.16.1.3-37.el9.x86_64
[04:43:04.822] Returned: 0

[04:43:04.825] Running rpmbuild
[04:43:04.834] Command [PID: 359052]:
    rpmbuild --eval=%{_target_cpu}
[04:43:04.834] Output:
    x86_64
[04:43:04.834] Returned: 0

[04:43:05.595] Running jlink
[04:43:09.284] Command:
    jlink --output ...
[04:43:09.285] Output:
    WARNING: Using incubator modules: jdk.incubator.vector
[04:43:09.285] Returned: 0

== A few KB of output ==

[04:44:01.051] Package (.rpm) saved to: test/output.
[04:44:01.052] Running rpm
[04:44:01.061] Command [PID: 359466]:
    rpm -qp --queryformat %{Name}\n%{Version}\n%{Release}\n%{Arch} test/output/simplepackagetest-1.0-1.x86_64.rpm
[04:44:01.061] Output:
    simplepackagetest
    1.0
    1
    x86_64
[04:44:01.061] Returned: 0
---

The package name is printed at the very end of the output and not explicitly marked. Though it is known in the configuration phase.

Also, it would be handy if jpackage adds to the summary properties it derives from the input data, not from the command-line, e.g., the application/package version if the "--app-version" option is not specified and jpackage uses module/jar version.

jpackage may optionally output the summary in quiet mode. To configure this, we may add a value to the "--verbose" option to configure the type of output jpackage produces.

jpackage may have two separate output channels:
1. console output. The purpose is to present the user with the details about the bundle jpackage will produce.
2. logging. The purpose is to provide details about jpackage execution sufficient for jpackage debugging. E.g., jpackage uses one WiX toolset but is expected to use another in the environment with multiple WiX toolsets. The log should provide sufficient information on why the jpackage used the specific WiX toolset. The same with signing keys on macOS. If it uses one key but is supposed to use another, the log should provide sufficient details explaining the jpackage choice.

The current verbose console output is cluttered with the output of the commands jpackage invokes. This information may be handy, but it doesn't serve the original purpose of the verbose output defined in JDK-8230652. It is supposed to help users customize installers and should include details on which resources jpackage uses (default or from the resource directory) and the command lines of the tools it invokes. The tools' output should be a part of the logging.

Logging should be configurable such that it would be possible to redirect it to a console. This is needed to include a trace of jpackage execution in test logs.