> On Sep 2, 2020, at 10:07 PM, Scott Palmer <[email protected]> wrote:
>
> There is already a way to supply a custom Info.plist.
> That can have the LSEnvironment entries you want.
>
> https://bugs.openjdk.java.net/browse/JDK-8233175
> <https://bugs.openjdk.java.net/browse/JDK-8233175>
>
> I was under the impression that we were after something that would allow
> different values to get to the application based on environment variables.
> The env var values can’t be hard-coded in the Info.plist to do that, we want
> values that are expanded based on set environment variables on the user’s
> machine. Isn’t that what this is about?
>
> Scott
Yes for Serban’s thread. Which was already shown not to work OS X on the users
machine because user environment variables aren’t passed to applications. Since
the interest there mainly seemed to be turning environment variables into jdk
option parameters for that part your stub launcher was a more valid suggestion.
The original is not the purpose of environment variables that interested me. I
think might of been a little questionable trying to use for this purpose. I had
sort of been still been discussing my own separate question on providing the
application environment variables Doing it on this thread probably wasn’t
proper. Sorry.
> https://bugs.openjdk.java.net/browse/JDK-8233175
> <https://bugs.openjdk.java.net/browse/JDK-8233175>
OK. Basically this gives a plugin method to provide your own Info.plist. As of
yet undocumented. That documentation still being as far as I know jpackage
—help. Info.plist is not normally placed into the resources directory. I assume
the issue resolution involves simply moving the Info.plist out of that
directory to where it actually should be.
--resource-dir <path>
Path to override jpackage resources
Icons, template files, and other resources of jpackage can be
over-ridden by adding replacement resources to this directory.
(absolute path or relative to the current directory)
Everything mentioned in the —help properly I think ends up in a OS X
applications resources directory. Although I just get the icns.
ls outputdir/HalfPipe.app/Contents/Resources
HalfPipe.icns
But it is not usually the spot for Info.plist. As a work-around it probably
does work.
It does make the Info.plist (plugin?) provider responsible for everything that
goes into the plist that jpackage would normally handle. Like
--mac-package-identifier. But that is fine I guess. Being able to sort of
custom plugin parts of the build might be nice. Rather than try to have
jpackage handle everything from start to finish in one pass for everything that
every application needs based solely on parameters. In this case I think maybe
though having a explicit parameter indicating this is the developers wish might
be cleaner? Something like —mac-info-plist <path>.
Maybe I’ll go back to the recent situation where a PATH environment variable
seemed to be needed and see if I can in fact come up with plugin type code that
puts together a Info.plist that works.
