jdk-14-jpackage+1-33 on jdk.java.net

Sverre Moe sverre.moe at gmail.com
Thu Sep 5 19:00:43 UTC 2019

Problem with running WiX through a Continuous Integration Build System.

It works perfectly fine logging into the Windows desktop with remote
desktop, open my Cygwin console and execute Gradle. Our Jenkins CI runs
into a problem at the end when WiX is running validation on the built

> WiX v3, Light automatically runs validation-- Windows Installer Internal
Consistency Evaluators (ICEs) --after every successful build.


Some has suggested to disable the validation, but that is not a good
solution in my opinion.
A workaround I attempted which works without meddling with the WiX
configuration, was to change the build user Jenkins uses to log onto the
Windows build agent. I changed its user type from Standard to
Administrator. Not sure why it would work, as I had run the jpackage+wix
using the same standard user through remote desktop. Perhaps some
permissions it didn't get while running in a headless environment.

Generating MSI:
Running [C:\Program Files (x86)\WiX Toolset v3.11\bin\light.exe, -nologo,
-ext, WixUtilExtension, -loc,
light.exe : error LGHT0217 : Error executing ICE action 'ICE01'. The most
common cause of this kind of ICE failure is an incorrectly registered
scripting engine. See http://wixtoolset.org/documentation/error217/ for
details and how to solve this problem. The following string format was not
expected by the external UI message logger: "The Windows Installer Service
could not be accessed. This can occur if the Windows Installer is not
correctly installed. Contact your support personnel for assistance.".

Windows Installer Service could not be accessed. This can occur if the
Windows Installer is not correctly installed. Contact your support
personnel for assistance.".light.exe : error LGHT0216 : An unexpected Win32
exception with error code 0x643 occurred: Action - 'ICE09' Fatal error
during installation
at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:211)
at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:181)
at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97)
at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51)

tor. 5. sep. 2019 kl. 17:12 skrev Sverre Moe <sverre.moe at gmail.com>:

> I have done some investigation myself.
> Found this blog post regarding ampersand in WiX:
> http://robmensching.com/blog/posts/2008/4/21/how-to-escape-the-ampersand-in-wix-and-msi-ui/
> I tried the solution suggested there. The build works, but the vendor is
> not display correctly in Windows.
> The Publisher name shows the text "&". Same goes for using "&".
> Both of these seems to work on Linux for RPM and DEB package. It does not
> pass the escaped ampersand to jpackage, but Gradle processResourcess task
> seems to replace the escape ampersand with the ampersand in my DEB control
> resource file and RPM spec resource file.
> Well, the Publisher does not display correctly on Windows, but the build
> works, the application works. So at least we can move forward, but I hope
> to find the proper solution to get this working and displaying correctly.
> /Sverre
> ons. 4. sep. 2019 kl. 21:01 skrev Andy Herrick <andy.herrick at oracle.com>:
>> This is easily reproducible by putting ampersand in --vendor value on
>> windows.
>> will investigate.
>> /Andy
>> On 9/4/2019 8:05 AM, Sverre Moe wrote:
>> Running WiX failed.
>> The problem it seems is the -dJpAppVendor. It cannot handle special
>> characters in the vendor name. Our company name uses the ampersand (&)
>> instead of "and".
>> Caused by: java.io.IOException: Exec failed with code 104 command
>> [[C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe, -nologo,
>> C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs,
>> -ext, WixUtilExtension, -out,
>> C:\cygwin64\tmp\jdk.jpackage1086156882119031648\tmp\application.wixobj,
>> -dJpAppDescription=application, -dJpAppVersion=1.1.0,
>> -dJpWixVersion36OrNewer=yes,
>> -dJpProductCode=2fa37b54-8365-437d-ad34-ceed92844d22,
>> -dJpAppName=application,
>> -dJpProductUpgradeCode=53c0f7f6-75c1-419a-86c5-bef18dda408a,
>> -dJpIsSystemWide=yes, -dJpAppVendor=Kongsberg Defence & Aerospace,
>> -dJpConfigDir=C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config] in
>> C:\cygwin64\tmp\jdk.jpackage1086156882119031648\images\win-msi.image\application
>> output:
>> application.wxsC:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs(56)
>> : error CNDL0104 : Not a valid source file; detail: An error occurred while
>> parsing EntityName. Line 9, position 68.
>> Is there anyway to allow special characters in the vendor name?
>> It would be very useful to be able to define the release, in addition to
>> the version. This is currently only possible on Linux with
>> "--linux-app-release".
>> I could have hacked this by setting "--app-version" to VERSION-RELEASE.
>> It would increase the special logic in the build script specific for
>> Windows, but it does not seem to be allowed with release in the version
>> string:  Version string is not compatible with MSI rules
>> [1.1.0-SNAPSHOT20190904133731]
>> https://docs.microsoft.com/en-us/windows/win32/msi/productversion
>> Could this potentially cause problems when installing SNAPSHOTs which
>> have the same version?
>> Anyway it does not seem WiX XML schema has any release or build
>> attributes.
>> /Sverre
>> tor. 29. aug. 2019 kl. 17:38 skrev Sverre Moe <sverre.moe at gmail.com>:
>>> No, have not installed WIX. Had InnoSetup from when we use javapackager.
>>> I will look into the WiX: https://wixtoolset.org
>>> /Sverre
>>> tor. 29. aug. 2019 kl. 17:34 skrev Kevin Rushforth <
>>> kevin.rushforth at oracle.com>:
>>>> Hi Sverre,
>>>> Do you have a WiX installed on your machine? That is a prerequisite.
>>>> Andy: Do we have a bug filed to produce a better error message in this
>>>> case? If not, we need to file one.
>>>> -- Kevin
>>>> On 8/29/2019 7:30 AM, Sverre Moe wrote:
>>>> It is not working creating native installer on Windows.
>>>> It will not take neither exe nor msi as --package-type on Windows.
>>>> jdk.jpackage.internal.PackagerException: Error: Invalid or unsupported
>>>> package type: [exe].
>>>>         at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:614)
>>>>         at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513)
>>>>         at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97)
>>>>         at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51)
>>>> The jpackage help output on Windows lists both exe and msi as valid
>>>> package types.
>>>> The JDK-8228660 is marked as resolved. I reckon it will make it into
>>>> the next build.
>>>> /Sverre
>>>> tor. 22. aug. 2019 kl. 02:03 skrev Kevin Rushforth <
>>>> kevin.rushforth at oracle.com>:
>>>>> We believe that we have addressed most of the issues, especially those
>>>>> affecting the generated Linux packages, both .deb and .rpm. There is
>>>>> one
>>>>> open issue around the naming of the Debian packages that we will
>>>>> address
>>>>> in the next EA release. See JDK-8228660 [1] for more information.
>>>>> We would love to get some feedback from Linux developers to make sure
>>>>> that we didn't miss anything else.
>>>>> Thanks.
>>>>> -- Kevin
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8228660
>>>>> On 8/21/2019 3:27 PM, Andy Herrick wrote:
>>>>> > The next EA build of JPackage is available at
>>>>> > https://jdk.java.net/jpackage/
>>>>> >
>>>>> > This build ( jdk-14-jpackage+1-33 ) (2019/8/20) is the next early
>>>>> > access release based on JDK-14
>>>>> >
>>>>> > This release contains fixes to the following issues:
>>>>> >
>>>>> > JDK-8229788     Error dialog displays with DLL issue when installing
>>>>> > WinChooserTest application
>>>>> > JDK-8225447     Revise Debian packaging
>>>>> > JDK-8213941     Debian linux problems in JavaPackager
>>>>> > JDK-8229334     jpackage .exe packages cannot be executed due to
>>>>> > missing DLL
>>>>> > JDK-8227058     Regressions related to no longer setting user.dir
>>>>> > JDK-8226599     use code coverage results to remove dead code
>>>>> > JDK-8226191     jpackager --license-file option broken on windows
>>>>> for
>>>>> > jdk installers.
>>>>> > JDK-8215381     Investigate if current implementation of
>>>>> > --license-file is correct for Debian packages
>>>>> > JDK-8229138     Add --linux-app-release option for DEB and RPM
>>>>> packages
>>>>> > JDK-8229791     Code clean up regressions
>>>>> > JDK-8229786     No output after WinShortcutTest.exe is launched
>>>>> > JDK-8229750     Fix bad merge of JDK-8215447 patch
>>>>> > JDK-8215446     JPackageCreateInstallerInstallDirTest fails on OLE7
>>>>> > JDK-8215447     Investigate if current implementation of
>>>>> > --license-file is correct for RPM packages
>>>>> > JDK-8227172     revert JDK-8225569 on windows
>>>>> > JDK-8224788     jpackage fails on OS X when using --runtime-image
>>>>> > JDK-8229252     Add descriptions to Windows jtreg tests
>>>>> > JDK-8228744     file associations broken on linux.
>>>>> > JDK-8227312     Remove pkg bundle from DMG image.
>>>>> > JDK-8228722     jpackage RPM tests fail on some versions of rpmbuild
>>>>> > JDK-8222778     Packaging Tool (JEP 343) on Linux/AArch64
>>>>> > JDK-8224627     Creating installer with --runtime-image on OS X fails
>>>>> > JDK-8226904     current working directory wrong running jpackage app
>>>>> > JDK-8224486     Arguments from jpackager cfg file not processed
>>>>> correctly
>>>>> > JDK-8226835     Command window pops up building exe package
>>>>> > JDK-8225092     Several jpackage tests failed when run with jcov
>>>>> enabled
>>>>> >
>>>>> > /Andy
>>>>> >

More information about the core-libs-dev mailing list