jpackage: support for environment variables in --java-options

[Michael Hall]

>> 
>> This is not how I’ve done it before. I did a little googling and it seemed to indicate launchctl could somehow be used for ‘global’ environment variables. It didn’t sound application specific.
> 
> Right it isn’t application specific.  If you need a separate environment for your application, that wouldn’t work.  But if you are passing parameters that are specific to the application launcher, why use environment variables at all?

See my prior examples of usage. Basically because other code requires the environment variables to be there.

> 
> 
>> The incident mentioned earlier showed a resolution of having the user provide their own custom Info.plist. 
> 
> Just use a config file that can be platform independent.  Modifying the Info.plist for each specific install smells wrong.

Because modifying the Info.plist is only way to do it. 

To the incident https://bugs.openjdk.java.net/browse/JDK-8233175 <https://bugs.openjdk.java.net/browse/JDK-8233175>
Doing some testing with plistbuddy it does seem to work following the resolution. It appears to even work without following the resolution. Possibly though that might break signed applications.

Following the resolution I took the Info.plist from a application and put it into a template/ directory.
Then doing…
cp template/Info.plist resources/Info.plist
/usr/libexec/plistbuddy -c 'Add:NSRequiresAquaSystemAppearance bool false' resources/Info.plist
And including this on the jpackage invocation…
--resource-dir resources \
We get…
/usr/libexec/plistbuddy -c print outputdir/HalfPipe.app/Contents/Info.plist
Dict {
    CFBundleName = HalfPipe
    CFBundleIdentifier = us.hall.HalfPipe
    CFBundleInfoDictionaryVersion = 6.0
    LSApplicationCategoryType = Unknown
    CFBundleVersion = 1.0
    CFBundleExecutable = HalfPipe
    CFBundleAllowMixedLocalizations = true
    NSHighResolutionCapable = true
    CFBundlePackageType = APPL
    CFBundleIconFile = HalfPipe.icns
    CFBundleSignature = ????
    NSRequiresAquaSystemAppearance = false
    LSMinimumSystemVersion = 10.9
    CFBundleDevelopmentRegion = English
    NSHumanReadableCopyright = Copyright (C) 2020
    CFBundleShortVersionString = 1.0
}

Including the incident mentioned NSRequiresAquaSystemAppearance. Setting it off appears to be about the only reason you would want to include the plist entry.

As I said this will also work by just directly working with the application Info.plist, at least as long as the application is unsigned. I don’t know if it would invalidate a signed signature. Probably best if it did, then the —resource-dir would be needed. 

For environment variables I checked my manual changes with the application where I can ‘exec env’ and they seemed set correctly. So I’m not sure yet what actual difference between shell invoked and Finder invoked is the issue. Possibly not that I have the environment variables wrong. 

So. If anyone actually wants to update the plist as part of the build plistbuddy seems a valid way to go. Doing this one time up front and assuming the plist never changes would be another. Xcode provides an editor if you only have to do a one time change and want to do that manually. 
plistbuddy almost seems a way jpackage could provide the functionality itself at some point fairly easily? It was included on my machine although I’m not sure how officially Apple supports it. Xcode native app developers do seem to use it in their builds so you would think it would not casually disappear.
You might consider it sometime.