Currently, jpackage ignores the value of the `--install-dir` option in DMG packaging. This behavior was implemented to fix an issue reported in JDK-8263154.
The issue is that if the path specified in `--install-dir` option doesn't exist on the machine where jpackage is executed, jpackage fails.
The suggested workaround of always using the default installation location ("/Applications") made sense while jpackage didn't support runtime packaging. This is not the case any longer.
For Java runtime packages, the default install location is "/Library/Java/JavaVirtualMachines" which may not exist where jpackage runs.
The suggested solution is to respect the value of the `--install-dir` option. If the installation directory doesn't exist, jpackage should try to create and delete it right after the DMG package is created. If it can't create the directory (likely due to the lack of permissions), it should report an error.
It should also gracefully handle the case when the path referenced in the `--install-dir` option exists but is not a directory.
The issue is that if the path specified in `--install-dir` option doesn't exist on the machine where jpackage is executed, jpackage fails.
The suggested workaround of always using the default installation location ("/Applications") made sense while jpackage didn't support runtime packaging. This is not the case any longer.
For Java runtime packages, the default install location is "/Library/Java/JavaVirtualMachines" which may not exist where jpackage runs.
The suggested solution is to respect the value of the `--install-dir` option. If the installation directory doesn't exist, jpackage should try to create and delete it right after the DMG package is created. If it can't create the directory (likely due to the lack of permissions), it should report an error.
It should also gracefully handle the case when the path referenced in the `--install-dir` option exists but is not a directory.
- relates to
-
JDK-8263154 [macos] DMG builds have finder errors
-
- Closed
-