Refactor jpackage to separate the configuration and execution phases. At the configuration phase, jpackage parses command-line arguments and validates them. At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly. This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params". Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. **Functional changes** jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. - Minimize copying of the source app image when doing native packaging. Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. post- and pre- install PKG scripts for SimplePackageTest package before and after the change: <table> <thead> <tr> <th>Script</th> <th>New</th> <th>Old</th> </tr> </thead> <tbody> <tr> <td nowrap>preinstall</td> <td> <pre> #!/usr/bin/env sh<br> if [ ! -d "/Applications/SimplePackageTest.app" ] then mkdir -p "/Applications/SimplePackageTest.app" fi<br> exit 0 </pre> </td> <td> <pre> #!/usr/bin/env sh<br> if [ ! -d "/Applications" ] then mkdir -p "/Applications" fi<br> exit 0 </pre> </td> </tr> <tr> <td nowrap>postinstall</td> <td> <pre> #!/usr/bin/env sh<br> chown root:wheel "/Applications/SimplePackageTest.app" chmod a+rX "/Applications/SimplePackageTest.app" chmod +r "/Applications/SimplePackageTest.app/Contents/app/"*.jar<br> exit 0 </pre> </td> <td> <pre> #!/usr/bin/env sh<br> chown root:wheel "/Applications" chmod a+rX "/Applications" chmod +r "/Applications/SimplePackageTest.app/Contents/app/"*.jar<br> exit 0 </pre> </td> </tr> </tbody> </table> This change relates to the [JDK-8356047](https://bugs.openjdk.org/browse/JDK-8356047) issue. Although the scripts are different, they are functionally identical (they don't change anything in the system). - PKG bundler: no "postinstall" and "preinstall" scripts in runtime bundles. jpackage will not create post- and pre- install scripts in runtime PKGs. This doesn't make a difference as runtime bundling on macOS is currently broken, see [JDK-8351073](https://bugs.openjdk.org/browse/JDK-8351073) issue. - macOS signing. Use `java.security.cert.X509Certificate` class to parse the signing certificates data instead of "/usr/bin/openssl" invocations. To identify the certificate unambiguously, the certificate's SHA1 hash is passed as a value of the "-s" parameter for codesign instead of the certificate name. **Testing** With these significant code changes, ensuring that jpackage still produces packages with the same properties for the given input was essential. jpackage uses external tools for building packages, supplying them with the configuration files. Assuming that a packaging tool would produce the same package for the given configuration files, these configuration files created by the "old" jpackage and the "new" jpackage in every jpackage test were examined and verified for no substantial differences. ConfigFilesStasher.java and clean_stashed_files.sh tools served this purpose. Thanks to this way to test jpackage, [JDK-8356219](https://bugs.openjdk.org/browse/JDK-8356219) was uncovered. ------------- Commit messages: - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh - Merge branch 'master' into JDK-8333664 - 8333568: Test that jpackage doesn't modify R/O files/directories - 8356562: SigningAppImageTwoStepsTest test fails - Remove clean_stashed_files.sh - OSVersionCondition: bugfix; CfgFile: minor; signing: fix entitlements - Merge branch 'master' into JDK-8333664 - Merge branch 'master' into JDK-8333664 - Fix FA tests - Add missing default jlink options - ... and 497 more: https://git.openjdk.org/jdk/compare/cc3a366e...9776f496 Changes: https://git.openjdk.org/jdk/pull/19668/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333664 Stats: 23913 lines in 194 files changed: 17144 ins; 5680 del; 1089 mod Patch: https://git.openjdk.org/jdk/pull/19668.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19668/head:pull/19668 PR: https://git.openjdk.org/jdk/pull/19668
