>>
>> 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.
