Mac OS Default JVM options make script fail on Linux and Windows

Old Forum Archive Bugs
1

When creating a distribution zip via gradle distZip task of the application plugin on a Mac OS then the Mac OS specific default JVM options Xdock:name and Xdock:icon are added to the scripts in the bin folder of the created zip.

When this Linux / Mac OS script is run on Linux the following error is thrown:

Unrecognized option: -Xdock:name=ApplicationName
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

And the Windows script (bat file) does not work on Windows either then.

@Andres_Almiray stated this behaviour also in an old post in the Old Forum half a year ago: Can't define platform specific DEFAULT_JVM_OPTS with application plugin

Has this problem been fixed yet ?

Thanks in advance.

2

With Gradle 2.4 you can provide your own OS-specific start script template. Please see the Javadocs of the task CreateStartScripts for more information.

startScripts {
    unixStartScriptGenerator.template = resources.text.fromFile('customUnixStartScript.txt')
    windowsStartScriptGenerator.template = resources.text.fromFile('customWindowsStartScript.txt')
}
3

Thanks for the hint. I’ll try this.

4

Great to know. I wish the variants feature (as hinted at Handling multiplatform concerns) was already available so that instead of specific task properties we could write something like

variants {
    unix {
        startScripts {
            generator.template = ...
        }
    }
    windows {
        startScripts {
            generator.template = ...
        }
    }
}

Looking forward to Gradle 2.6 and more :slight_smile:

5

By default the task CreateStartScripts tries to generate start scripts for Windows and Unix. It’s baked in so having variants won’t help in this case.

6

Indeed. How would you further differentiate unix flavors, e.g, MacOSX? How would you generate generate multiple distros per platform? Right now I think the alternative would be do declare multiple tasks of the appropriate type :’(

7

That’s something the task doesn’t provide at the moment. For that purpose I’d probably just write my own task implementation or we’d need to extend the existing custom task to make it more flexible. If you don’t shy away from using internal classes, the package org.gradle.api.internal.plugins now has a bunch of helpful classes that you could reuse for writing your own implementation.

8

I’m no stranger to using private APIs nor creating custom tasks :wink: however this case requires a more robust option, as all Griffon projects require the same setup to generate all kinds of platform specific distributions (which they don’t right now for obvious reasons).

Is there a public document on the variants API roadmap? I wouldn’t want to create my own DSL and then find out that’s completely opposite to what the official variants API will be. IOW, making our own distro tasks (based on the ones delivered by the application plugin) should be as similar are the official ones once variants are supported; to smooth migration, wouldn’t you agree?