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
<mailto: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 <mailto: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 <mailto: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
>
