RFR: 8325089: jpackage utility creates an "infinite", undeleteable directory tree [v4]

[Alexey Semenyuk]

On Fri, 18 Oct 2024 14:42:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Make jpackage correctly handle the output directory (`--dest`) that is:
>>  - a subdirectory of the input directory;
>>  - the same as the input directory.
>> 
>> Make jpackage correctly handle temp directory (`--temp`) that is:
>>  - a subdirectory of the input directory.
>> 
>> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
>> 
>> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
>> 
>> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
>> 
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
>> 
>> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files.isSameFile() throws exception if a file doesn't exist

For `--mac-dmg-content` I think we can just test that jpackage doesn't dive into an infinite spiral:

`jpackage --input in --dest . --mac-dmg-content in`
`jpackage --input in --dest . --mac-dmg-content .`
`jpackage --input in --dest . --mac-dmg-content in/foo`
`jpackage --input in --dest . --name Foo --mac-dmg-content Foo.app`

For `--app-content` we can do the same as for the `--mac-dmg-content`:

`jpackage --input in --dest . --app-content in`
`jpackage --input in --dest . --app-content .`
`jpackage --input in --dest . --app-content in/foo`
for linux & windows: `jpackage --input in --dest . --name Foo --app-content Foo`
for mac: `jpackage --input in --dest . --name Foo --app-content Foo.app`

I don't see a point in making jpackage handle these weird command lines predictably except not falling into an infinite copying spiral. That said the tests will not verify the contents of app images produced by these commands.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21550#issuecomment-2436241905