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
installer.
>
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
This is easily reproducable by putting amperstand 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
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
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
I did not read the help output well enough where it says "used if no
command line arguments are given to the launcher".
This means we cannot set any default arguments to the application launcher
and support manually entered command line arguments by the user.
Is there a reason for this
I can't reproduce this problem.
In my manual examples as well as our related automated test cases the
arguments specified by "--arguments " are being
delivered to the application when it is invoked without command line
arguments. (Note: if there are any arguments given to the command to
I am having problem with arguments not being passed to the application.
The fix JDK-8224486 in this EA release seems to have something to do with
arguments, but it is actually just the JavaOptions.
The options in ArgOptions in the jpackage cfg does not seem to be passed to
the application
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
On 8/29/2019 11:34 AM, Kevin Rushforth wrote:
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.
Yes - I have been working out fix for JDK-8230152: No
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
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
/openjfx-dev/2018-September/022500.html
-Ursprüngliche Nachricht-
Von: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] Im Auftrag
von Andy Herrick
Gesendet: Dienstag, 27. August 2019 14:18
An: core-libs-dev@openjdk.java.net
Betreff: Re: AW: jdk-14-jpackage+1-33 on jdk.java.net
Unless you added the --win-console option, I think this is expected. Windows
has a rather silly concept of console vs. window applications. To avoid a
console window popping up when you don’t expected it, the default launcher is
in ‘window’ mode, not ‘console’ mode.
You need to know which
to address this we added the option --win-console.
I'm not sure why the comments in JDK-8211299 are marked as confidential
(so you can't see them), but using --win-console option makes running
the app more like running "java.exe" instead of "javaw.exe" (where
stderr/stdout will not show).
I
First of all: Thank you very much for JPackage. This looks very promising.
To give some feedback: I just tried JPackage on Windows 10 and I believe I ran
into this bug: https://bugs.openjdk.java.net/browse/JDK-8211299
It says the bug is fixed but I do not see anything written to either
Thanks for your feedback.
I wanted to let you know we are, or soon will be, looking these issues,
so I am responding before I have had a chance to look at them all ...
On 8/22/2019 9:42 AM, Michael Paus wrote:
Thanks for the EA version of jpackage. Great job. I wish this could
still make it
Thanks for the EA version of jpackage. Great job. I wish this could
still make it into Java 13.
Here is a little feedback according to my practical experience with it:
Add type "img", "app" or similar to --package-type.
It makes the handling in scripts easier.
DMG folder does not contain an
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
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
20 matches
Mail list logo
