This documentation specifies the public API that install4j provides for scripting installers and uninstallers, developing extensions and for accessing runtime services.
Please read "Help topics->Extending install4j->Using the install4j API" in the documentation ( directory $INSTALL4J_HOME/doc or F1 in the install4j IDE) for an overview on how to use the API. Packaging your own beans as regular install4j extensions is explained under "Help topics->Extending install4j->Extensions".
To get started with writing your own screens, actions and form components, please have a look at the Custom Code example project that is located in the samples/customCode subdirectory of your install4j installation.
When developing your own classes, you have to add $INSTALL4J_HOME/resource/i4jruntime.jar to your classpath. Do not distribute this jar file with your application, install4j will handle this for you. i4jruntime.jar will be automatically available on the classpath in the installer as well as for all launchers generated by install4j.
To test and debug screens, actions and form components for your installer, you can follow this procedure:
The debug directories contain
They start the installer and the uninstaller with a plain java invocation. All exceptions are directly printed to stderr and no separate error log files are created.
The file user.jar in the debug directory contains all your custom code. For interactive development you will not want to rebuild the project after each modification of your custom code. You can set up the installer or the uninstaller in your IDE by
Note: The working directory for the executed java process must be the debug directory, otherwise both the installer as well as the uninstaller will not work.
This procedure allows for an edit-compile-debug cycle that is much faster than building the media file and running the installer. In addition, output on stderr and stdout can be captured and you can debug your screens, actions and form components this way.
install4j provides three extension points: screens, actions and form components. Please see the corresponding package overview for more information:
install4j offers custom localization files in the install4j IDE to localize your own messages. com.install4j.api.context.Context.getMessage(String key) gives access to all messages.
If you develop your own user-configurable screens, actions or form components, you can replace all custom localization keys and installer variables in property values with calls to the com.install4j.api.beans.AbstractBean.replaceVariables(...) methods. All abstract base classes for beans extend com.install4j.api.beans.AbstractBean.
The locale of the installer will always be set to the language selected by the user or configured for the media file, not the locale of the system that the installer is running on. You can query com.install4j.api.context.Context.getLanguageId() to find out what language your installer is running with.