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

[Michael Hall]

> On Sep 2, 2020, at 10:07 PM, Scott Palmer <swpalmer at gmail.com> 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.