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.herr...@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....@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.rushfo...@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.rushfo...@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 >>>> > >>>> >>>> >>>
