javafx-gradle-plugin
javafx-gradle-plugin copied to clipboard
FibreFoX
Doesn't appear to be a way to specify different backgrounds for a Mac Disk Image and a Mac Installer Package
When running all of the bundlers on Mac there doesn't appear to be a way to specify different backgrounds for a Mac Disk Image and a Mac Installer Package, but they are very different contexts requiring different images.
Output from the build shows the same 'background' file is used for both bundlers.
Building with 'dmg':
Using custom package resource [dmg background] (loaded from package/macosx/Example Application-background.png)
Building with 'pkg':
Using custom package resource [pkg background image] (loaded from package/macosx/Example Application-background.png)
You are right, currently there is no way for this. Just being curious: was this possible on the plugin from Danno?
I never got to the point where I was ready to customize those images with Danno's plugin, so I don't know.
I have looked into the sources of the OpenJDK, it seems that both bundlers (MacDmgBundler and MacPkgBundler) are using the same idea to get the filename. There might be a different way for a working solution!
Sources contain these filenames:
MacDmgBundler {
/* ... */
static final String DEFAULT_BACKGROUND_IMAGE="background_dmg.png";
MacPkgBundler {
/* ... */
private static final String DEFAULT_BACKGROUND_IMAGE = "background_pkg.png";
As there is a option to provide a "DROP-IN replacement", you might be able to place your image-files into a separated folder for example called dropinResourcesRoot. To specify that drop-in folder, you have to provide that path as bundleArgument:
jfx {
// ...
bundleArguments = [
// ...
'dropinResourcesRoot': 'src/main/deploy/dropinResourcesRoot'
]
If this works, there is no need for adjustments inside this gradle-plugin, because then it is using the way provided by the JDK.
Opening an issue on the openjdk-project might getting closed due to dropinResourcesRoot being available for this ...
I tried adding two different images with the default names of "background_dmg.png" and "background_pkg.png" into the 'src/main/deploy/dropinResourcesRoot' folder and adding the bundleArgument as above. But they are not used and a default image is created. The build produces this message:
Using default package resource [pkg background image] (add package/macosx/Example Application-background.png to the class path to customize)
It looks like changing the dropinResourcesRoot changes where it looks for all of the custom files. It still appends "package/macosx" to that path and it still expects the application name prepended with a hyphen. However it does NOT use the _dmg or _pkg version of the PNG even if I give it the full name "Example Application-background_pkg.png". The message to put a file named "Example Application-background.png" in the folder to customize is still printed.
As you say, it looks like this may need to be addressed in OpenJDK (or OpenJFX where the packager code currently resides)
Indeed, I missed that "package/macosx/"-folder-structure ... my bad. As this drop-in-resource thing is used on other systems too, I will try to make it work on windows somehow and will report back. (It would be very nice to have it working without any modifications on the plugin)
I've just looked into the code inside the JDK:
private URL locateResource(String publicName, String category, String defaultName, boolean verbose, File publicRoot) throws IOException {
URL u = null;
boolean custom = false;
if (publicName != null) {
if (publicRoot != null) {
File publicResource = new File(publicRoot, publicName);
if (publicResource.exists() && publicResource.isFile()) {
u = publicResource.toURI().toURL();
}
} else {
u = baseResourceLoader.getClassLoader().getResource(publicName);
}
custom = (u != null);
}
if (u == null && defaultName != null) {
u = baseResourceLoader.getResource(defaultName);
}
// ...
}
If I'm right, this makes it impossible to override these files by providing the default-filename, as defaultName is only used when the file having "appName" as filename is not found on the drop-in folder nor the classloader itself, and the resource is not searched inside the drop-in folder by its default-name (which might be a working solution to implement on the openjfx-project).
As a workaround, you might want to run jfxNative with different "deploy"-folders for each target, as it is a JDK-bug (maybe no real BUG, but a inconvenience of the underlying javapackager). Just make separated tasks which are extending de.dynamicfiles.projects.gradle.plugins.javafx.tasks.JfxNativeTask:
// ....
task generateDMG(type: de.dynamicfiles.projects.gradle.plugins.javafx.tasks.JfxNativeTask){
jfx.deployDir = 'src/main/deployDMG'
}
task generatePKG(type: de.dynamicfiles.projects.gradle.plugins.javafx.tasks.JfxNativeTask){
jfx.deployDir = 'src/main/deployPKG'
}
task generateNativeBundles(){
}
generateNativeBundles.dependsOn generateDMG
generateNativeBundles.dependsOn generatePKG
(Sorry, I'm no groovy expert :D)
This Bug is still open for JDK 8, did not see any changes for JDK 9 either. :(
See http://bildschirmarbeiter.de/JDK-8165630.html which describes a workaround I use e.g. for AEM Toolbox.
