Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task jpackage fails when imageName and installerName are different #169

Open
sergey-selivanov opened this issue Jan 16, 2021 · 5 comments
Open

Comments

@sergey-selivanov
Copy link

When properties imageName and installerName has different values, task jpackage fails to build exe installer with WiX:

jlink {
...
    jpackage {
...
        imageName = 'test imageName'
        installerName = 'test installerName'

When values are identical, build is successful, and installation and installed application works OK.
OpenJDK 15.0.1, Windows 8.1, WiX 3.11.2
'org.beryx.jlink' version '2.23.1'

In the failed build output, I see following:


Running [candle.exe, -nologo, D:\git\jlink-jpackage-test\build\temp\config\main.
wxs, -ext, WixUtilExtension, -arch, x64, -out, D:\git\jlink-jpackage-test\build
temp\wixobj\main.wixobj, -dJpAppDescription=test installerName, -dJpProductCode=
b6a50dfb-efcc-3ee8-a975-1c94f173b0b7, -dJpAppName=test installerName, -dJpIsSyst
emWide=yes, -dJpAllowDowngrades=yes, -dJpIcon=D:\git\jlink-jpackage-test\build\t
emp\images\win-msi.image\ test installerName\test installerName.exe, -dJpAppVersi
on=0.0.1, -dJpInstallDirChooser=yes, -dJpAllowUpgrades=yes, -dJpProductUpgradeCo
de=1ada98a9-a326-3394-b239-76c3d35bd542, -dJpAppVendor=Sergey Selivanov, -dJpCon
figDir=D:\git\jlink-jpackage-test\build\temp\config]in D:\git\jlink-jpackage-tes
t\build\temp\images\win-msi.image\test installerName
main.wxs
Running [candle.exe, -nologo, D:\git\jlink-jpackage-test\build\temp\config\bundl
e.wxf, -ext, WixUtilExtension, -arch, x64, -out, D:\git\jlink-jpackage-test\buil
d\temp\wixobj\bundle.wixobj]in D:\git\jlink-jpackage-test\build\temp\images\win-
msi.image\test installerName
bundle.wxf
Running [light.exe, -nologo, -spdb, -ext, WixUtilExtension, -out, D:\git\jlink-j
package-test\build\temp\images\win-exe.image\test installerName-0.0.1.msi, -sice
:ICE27, -ext, WixUIExtension, -loc, D:\git\jlink-jpackage-test\build\temp\config
\MsiInstallerStrings_en.wxl, -b, D:\git\jlink-jpackage-test\build\temp\config, D
:\git\jlink-jpackage-test\build\temp\wixobj\main.wixobj, D:\git\jlink-jpackage-t
est\build\temp\wixobj\bundle.wixobj]in D:\git\jlink-jpackage-test\build\temp\ima
ges\win-msi.image\test installerName
D:\git\jlink-jpackage-test\build\temp\config\main.wxs(86) : error LGHT0103 : The
system cannot find the file
'D:\git\jlink-jpackage-test\build\temp\images\win-m
si.image\ test installerName\test installerName.exe'.
java.io.IOException: Command [light.exe, -nologo, -spdb, -ext, WixUtilExtension,


WiX expects to find 'test installerName\test installerName.exe', but actually there's 'test installerName\test imageName.exe' in that directory, from generated image.

Not sure if this is JDK jpackage issue, or jlink plugin. Logically, either imageName and installerName should allow different values (suppose one need customized installer .exe name), or one of options is redundant?

Please find complete reproduction code here: https://github.com/sergey-selivanov/jlink-jpackage-test

@sergey-selivanov
Copy link
Author

For linux installers it builds, installs and run OK with different imageName and installerName:

deb (ubuntu):
produces 'test-installername_0.0.1-1_amd64.deb'
installs as '/opt/test-installername/bin/test imageName'

rpm (oracle linux):
produces 'test-installername-0.0.1-1.x86_64.rpm'
installs as '/opt/test-installername/bin/test imageName'

(btw should final executable better be named not 'test imageName' but 'test launcher' as configured in the 'launcher' block? how it works with secondaryLauncher(s)?)

@siordache
Copy link
Member

Thanks for reporting and analyzing this issue. It seems that this is a limitation of WiX.
I just released 2.23.2, which gets rid of the error by creating a temporary copy of test imageName.exe with the name test installerName.exe.

@sergey-selivanov
Copy link
Author

Builds OK!
There's inconsistency in the names however. Wix setup wizard obtains and uses value of "installerName" where application name ("imageName" as I understand) should be used instead:
Capture
Typically such windows setups are "SkypeSetup.exe", "ccsetup575.exe", "Thunderbird Setup NNN-x64.exe" and I think "installerName" is what I should set to "MyApp-Setup-x64" to get MyApp-Setup-x64.exe installer file. WiX of course should not display "Welcome to the MyApp Setup x64 Setup Wizard".

The same with target directory, should be "imageName" I guess:
Capture2

I don't know WiX but I guess the reason could be: "-dJpAppName=test installerName," when arguments are passed to candle.exe, see above in original build output. Not sure if your plugin or JDK is responsible for that.

Also when installed, there's duplicate exe present:
Capture3
while only 'test imageName.exe' is in 'build\jpackage\test imageName' dir.

@siordache
Copy link
Member

I don't have a solution for this inconsistency, because the plugin cannot control the arguments passed to candle.exe.
In retrospect, it seems that providing distinct properties for image name and installer name was a bad idea. But I will keep them because replacing them with a single property would be a breaking change in the plugin. I will mention in the documentation that it's recommended to configure imageName and installerName with the same value.

@sergey-selivanov
Copy link
Author

Thanks!

Practical workaround then will be to rename final installer exe to desired name later in gradle build.

Mention in documentation will be great. I also been stuck with such issues as #148, when --resource-dir is required for linux icon, and flyway not seeing its migration resources in jlink-ed application. Maybe additional section for all such "tricks" or workarounds, or FAQ could be created at the doc page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants