在持续交付代理上使用 jpackage 构建 windows 安装程序
Bulding windows installer using jpackage on continous delivery agent
我在 CD 代理上遇到了 运行 jpackage 任务的问题。
我收到以下错误:
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.".
我做了一些研究,基本上可以通过以下方式解决问题:
- 为代理用户添加管理员权限
- 查看环境变量的大小(对于某些人来说,大小大于 32KB 的环境变量会导致类似的错误)
- 抑制 ICE 验证
在我的案例中,每个解决方案要么不相关,要么有问题。
- 我无法使用 CD 上的管理员用户
- env 变量小于 32KB (10KB)
- 我找不到使用 jpackage 抑制 ICE 验证的方法 - 我知道可以通过将 -sval 传递给 light.exe 或在 wixproj 文件中指定 属性 来完成,但我没有关于如何将 light.exe 参数输入到 jpackage(如果可能)的想法以及传入 --resource-dir 的 wixproj 文件似乎没有做任何更改。
需要说明的是,它在我的本地环境中运行良好。
所以很可能我的问题可以归结为是否可以从 jpackage 级别抑制 ICE 验证的问题。
我正在为 gradle 使用 badass-runtime-plugin 并尝试为 javafx + spring 引导应用程序构建安装程序。这是我的 build.gradel
相关部分:
runtime {
modules = ['java.management', 'java.naming', 'java.instrument', 'java.sql', 'jdk.unsupported', 'jdk.security.jgss', 'java.desktop', 'java.logging', 'jdk.jfr', 'java.xml', 'java.scripting', 'jdk.crypto.cryptoki']
options = ['--strip-debug', '--compress', '2', '--no-header-files', '--no-man-pages']
launcher {
noConsole = false
}
jpackage {
mainClass = 'org.springframework.boot.loader.JarLauncher'
imageOptions += ['--icon', "src/main/resources/graphics/icon.ico"]
imageOptions += ['--win-console']
installerOptions += ['--resource-dir', "src/main/resources"]
installerOptions += ['--vendor', 'XYZ']
installerOptions += ['--type', 'msi']
installerOptions += ['--verbose']
installerOptions += ['--resource-dir', "src/main/resources/wix"]
installerOptions += ['--win-per-user-install', '--win-dir-chooser', '--win-menu', '--win-shortcut']
}
}
根据 badass-runtime-plugin's author,使用 jpackage 很可能无法做到这一点。
但是我设法想出了一些肮脏的技巧,以某种方式让我实现了我的目标。
我已经为 jpackage 添加了 tempDir 参数,然后在 gradle 构建失败后,我“手动”运行 light.exe 使用 -sval 开关对来自 tempDir 的文件进行处理。
我在 CD 代理上遇到了 运行 jpackage 任务的问题。 我收到以下错误:
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.".
我做了一些研究,基本上可以通过以下方式解决问题:
- 为代理用户添加管理员权限
- 查看环境变量的大小(对于某些人来说,大小大于 32KB 的环境变量会导致类似的错误)
- 抑制 ICE 验证
在我的案例中,每个解决方案要么不相关,要么有问题。
- 我无法使用 CD 上的管理员用户
- env 变量小于 32KB (10KB)
- 我找不到使用 jpackage 抑制 ICE 验证的方法 - 我知道可以通过将 -sval 传递给 light.exe 或在 wixproj 文件中指定 属性 来完成,但我没有关于如何将 light.exe 参数输入到 jpackage(如果可能)的想法以及传入 --resource-dir 的 wixproj 文件似乎没有做任何更改。
需要说明的是,它在我的本地环境中运行良好。
所以很可能我的问题可以归结为是否可以从 jpackage 级别抑制 ICE 验证的问题。
我正在为 gradle 使用 badass-runtime-plugin 并尝试为 javafx + spring 引导应用程序构建安装程序。这是我的 build.gradel
相关部分:
runtime {
modules = ['java.management', 'java.naming', 'java.instrument', 'java.sql', 'jdk.unsupported', 'jdk.security.jgss', 'java.desktop', 'java.logging', 'jdk.jfr', 'java.xml', 'java.scripting', 'jdk.crypto.cryptoki']
options = ['--strip-debug', '--compress', '2', '--no-header-files', '--no-man-pages']
launcher {
noConsole = false
}
jpackage {
mainClass = 'org.springframework.boot.loader.JarLauncher'
imageOptions += ['--icon', "src/main/resources/graphics/icon.ico"]
imageOptions += ['--win-console']
installerOptions += ['--resource-dir', "src/main/resources"]
installerOptions += ['--vendor', 'XYZ']
installerOptions += ['--type', 'msi']
installerOptions += ['--verbose']
installerOptions += ['--resource-dir', "src/main/resources/wix"]
installerOptions += ['--win-per-user-install', '--win-dir-chooser', '--win-menu', '--win-shortcut']
}
}
根据 badass-runtime-plugin's author,使用 jpackage 很可能无法做到这一点。
但是我设法想出了一些肮脏的技巧,以某种方式让我实现了我的目标。 我已经为 jpackage 添加了 tempDir 参数,然后在 gradle 构建失败后,我“手动”运行 light.exe 使用 -sval 开关对来自 tempDir 的文件进行处理。