Sverre,
exe installers generated by jpackage are just wrappers for msi installers.
Moving workaround you have in Gradle into jpackage will not solve the
problem, but will hide it. This doesn't look appealing.
We need a better solution. I created
https://bugs.openjdk.java.net/browse/JDK-8283707
Hi,
I was hoping something could be done to allow 4 fields in the version on
Windows when using jpackage.
Even though Windows will ignore the fourth component when installing, that
is ok, but if we could build just build an EXE with 4 fields version. If by
some configuration with jpackage, or the
On 25/03/2022 5:14 am, Alexey Semenyuk wrote:
Hi Sverre,
Oh, I misunderstood the problem. I though the issue was with parsing WiX
version string, but the problem is that jpackage doesn't like the value
of --version cli parameter.
On windows this value should satisfy constrains of MSI ProductVe
Hi Sverre,
Oh, I misunderstood the problem. I though the issue was with parsing WiX
version string, but the problem is that jpackage doesn't like the value
of --version cli parameter.
On windows this value should satisfy constrains of MSI ProductVersion
property [1]:
The format of the string
Hi,
This has been attempted on Java 15, Java 16 and the latest Java 17.
This is the output from Java 17
14:46:49
C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat
--no-daemon --version
14:46:51
14:46:51 --
Hi Sverre,
The output comes from quite old jpackage (jdk15, I guess). Please try
jpackage from the newer jdk (the latest one would be the best option).
They don't have this issue.
- Alexey
On 3/23/2022 10:01 AM, Sverre Moe wrote:
Could jpackage instruct WiX when building a native applicatio
Could jpackage instruct WiX when building a native application on Windows,
to support 4 digits in the version?
14:41:18 Detected [light.exe] version [3.11.2.4516].
14:41:18 Detected [candle.exe] version [3.11.2.4516].
14:41:18 WiX 3.11.2.4516 detected. Enabling advanced cleanup action.
14:41:18
