Doesn't appear to be a way to specify different backgrounds for a Mac Disk Image and a Mac Installer Package

[swpalmer]

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)

[FibreFoX]

You are right, currently there is no way for this. Just being curious: was this possible on the plugin from Danno?

[swpalmer]

I never got to the point where I was ready to customize those images with Danno's plugin, so I don't know.

[FibreFoX]

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.

[FibreFoX]

Opening an issue on the openjdk-project might getting closed due to dropinResourcesRoot being available for this ...

[swpalmer]

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)

[FibreFoX]

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)

[FibreFoX]

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)

[swpalmer]

https://bugs.openjdk.java.net/browse/JDK-8165630

[FibreFoX]

Snap ... you were faster ;) thanks ! 🍰

[FibreFoX]

This Bug is still open for JDK 8, did not see any changes for JDK 9 either. :(

[oliverlietz]

See http://bildschirmarbeiter.de/JDK-8165630.html which describes a workaround I use e.g. for AEM Toolbox.