On Mon, 16 Nov 2020 19:01:49 GMT, Alexey Semenyuk <asemen...@openjdk.org> wrote:

>> … fix linux DTI
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 
> 484:
> 
>> 482:         return TKit.getCurrentDefaultAppName();
>> 483:     }
>> 484: 
> 
> I don't like the idea of introducing this method. Two reasons:
> - it adds confusion because we already have name()
> - name() is not returning app name any more for the case of two phase 
> jpackage usage as app name is now supposed to be returned by 
> getApplicationName()
> - TKit.getCurrentDefaultAppName() should be used only to set the default app 
> name when jpackage default command line is configured by the test.
> 
> I suggest instead update name() method. Test is "--app-image" is on the 
> command line, if it is, extract app name of xml file with app image info. 
> This will eliminate need for another method in JPackageCommand interface and 
> make name() method return accurate result without relying on the current 
> usage scenarios of "--app-image" parameter in tests.

I can easily agree that changing to actually extract name from AppImageFile is 
a better way to go, but just changing name() to return the main app name, 
ignores other cases where name is referring to the installer name.
Actually, the problem is that on linux and Windows (doesn't matter on mac) the 
default install directory is based on the installer name , not the app name so 
that on windows with app name "hello" and installer name "helloSetup" we will 
be default install to "C:\Program Files\helloSetup\hello.exe", and similar  
(the param WINDOWS_INSTALL_DIR defaults to APP_NAME)
Similar problem on linux where it uses PACKAGE_NAME which is derived from 
APP_NAME
If we fix that we can just fix name() as you suggest.

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

PR: https://git.openjdk.java.net/jdk/pull/1229

Reply via email to