Migrating to install4j 8
In nearly all cases, migrating to install4j 8 just means opening and saving your project with the install4j 8 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.
- The unattended installer does not ignore file installation failures anymore but fails at the first file installation failure. To get the old behavior, start the installer with the
-nofilefailures
argument. To permanently set this mode, add-Dinstall4j.noFileFailures=true
to the “VM parameters” property of the installer. - When using the VM parameters
-Dinstall4j.alternativeLogFile=<path>
and its new alias-Dinstallj4.log=<path>
now imply-Dinstall4j.keepLog=true
, meaning that the log file is no longer deleted in case of a successful execution of the installer application. - The default file name of the error log for Windows installers has changed from
error.log
to${compiler:sys.mediaFileName}_error.log
. You can restore the old file name with the new “Log file for stderr” property of the installer. - In bean properties with an array type, installer variables with collection values are expanded as separate array elements. Previously this was only implemented if the installer variables had array values. In the API, this new behavior affects the
AbstractBean.replaceVariables(...)
methods with array parameters. If you rely on thetoString()
replacement of collections, you have to change the types of the related installer variables. - Variable names for all built-in variable systems can no longer contain the character sequence
?:
which is now used for specifying default values for missing variables. FormEnvironment.getId(...)
now returns the display ID of the form component rather than the automatic ID. If you were checking for an explicit automatic ID and also defined a custom ID for a form component, that code will now fail.- The “Read text from file” action will now fail if an error occurred. Previously it always succeeded.
- The compiler variable
sys.platform
now contains the valuewindows-x32
for 32-bit Windows media files instead ofwindows
. For 64-bit Windows media files it remainswindows-x64
. - The “Customize project defaults->Installer custom script” step of the Unix/Linux GUI installer media wizard has been removed. The custom script is now configured on the installer in the “Installer->Screens & Actions” step. The simple case where there is only one Unix/Linux GUI installer is migrated correctly. However, if you used different customizations for different Unix/Linux GUI installers, the migration will be incomplete and you have to solve it with compiler variables.
- For Linux/Unix installers, the umask is now set to 0022 to allow execution by all users. This can be changed by setting the compiler variable
sys.ext.installerUmask
to another mask value or tofalse
to prevent executing anyumask
command in the installer script.
Hi,
I have just downloaded today I trial version of install4j 8.0.1 (we are very interesting about the new features related to MacOS X).
I have created a basic launcher (one single JAR, with a single main class, the classic “Hello World” example).
The issue I am facing is with the JRE. If I select any JRE “[Packed]”, the build will fail saying:
Build failed.
Cause: com.exe4j.a.d
JRE for signed macOS single bundle archive cannot contain packed jars
Stack trace:
com.exe4j.a.d: JRE for signed macOS single bundle archive cannot contain packed jars
at com.install4j.b.d.e.a(ejt:141)
at com.install4j.a.c.a(ejt:38)
at com.install4j.b.d.a(ejt:246)
at com.install4j.b.d.a.a(ejt:105)
at com.install4j.b.d.a(ejt:157)
at com.install4j.b.d.a(ejt:59)
at com.install4j.b.r.a(ejt:499)
at com.install4j.b.r.b(ejt:163)
at com.install4j.gui.b.run(ejt:100)
If I select any other JRE “non-packed” all is fine, the DMG is correctly signed, and I can notarise the application.
What is this error about? I’m pretty super for version 6/7 I did the same test and I could use a “[Packed]” JRE as well. What I am doing wrong? I tend to think that this is a user error.
Thanks!
Please contact support@ej-technologies.com for these kinds of support requests. The message is expected because the macOS single bundle archive cannot include a packed JRE bundle.
Thanks for your answer. Next time I’ll write to the email you provide. Thanks.
Post a comment