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

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

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

> On Sep 3, 2020, at 8:55 AM, Michael Hall wrote: > > > >> On Sep 3, 2020, at 7:12 AM, Scott Palmer > > wrote: >> >> >> >>> On Sep 3, 2020, at 4:26 AM, Michael Hall >> > wrote: >>> >>> >>> On Sep 2, 2020, at 10:07 PM, Scott

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

> > The incident mentioned earlier showed a resolution of having the user provide > their own custom Info.plist. While plain old edit would probably be fine for > this some sort of code to provide it without manual intervention might also > be nice. I believe I have some old code lying around

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

> On Sep 3, 2020, at 7:12 AM, Scott Palmer wrote: > > > >> On Sep 3, 2020, at 4:26 AM, Michael Hall > > wrote: >> >> >> >>> On Sep 2, 2020, at 10:07 PM, Scott Palmer >> > wrote: >>> >>> There is already a way to supply a custom

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

> On Sep 3, 2020, at 4:26 AM, Michael Hall wrote: > > > >> On Sep 2, 2020, at 10:07 PM, Scott Palmer > > wrote: >> >> There is already a way to supply a custom Info.plist. >> That can have the LSEnvironment entries you want. >> >>

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

> On Sep 2, 2020, at 10:07 PM, Scott Palmer 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 > > > I was under the

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

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 I was under the impression that we were after something that would allow different

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

> On Sep 2, 2020, at 12:14 PM, Scott Palmer wrote: > > If your app need to use environment variables to configure something for > runtime it is probably best to have your own stub launcher and launch a > sub-process. They need to be available at runtime for external native that expects

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

If your app need to use environment variables to configure something for runtime it is probably best to have your own stub launcher and launch a sub-process. It can be tricky to have a smooth user experience with that though. You would want to avoid an extra icon in the dock/start bar. You

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

Thanks, Michael! I maintain two Gradle plugins that help creating custom images and packages with jlink and jpackage (https://github.com/beryx/badass-jlink-plugin and https://github.com/beryx/badass-runtime-plugin). The request for supporting environment variables came from my users. They have

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

Not sure if it was clear from my previous messages, but what I am asking for is that the environment variables are expanded with the values they have on the user's machine (not on the machine where jpackage has been executed). Am Di., 1. Sept. 2020 um 08:37 Uhr schrieb Serban Iordache <

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

> On Sep 2, 2020, at 9:04 AM, Andy Herrick wrote: > > Yes - environment variables are not a good answer for this, not just mac, but > even on windows the env variables at run time are different if launched from > a shell (the env variables of that shell) vs. when run from a shortcut (the >

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

Yes - environment variables are not a good answer for this, not just mac, but even on windows the env variables at run time are different if launched from a shell (the env variables of that shell) vs. when run from a shortcut (the system-wide or user env variables set in Control Panel or

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

> > On macOS you need to set the variables differently, but I think it can still > work. The variables known to your shell are not the same as those known to > LaunchServices. For those use the launchctl command to set them. > I’m not that familiar with launchctl. Is this something the

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

> On Sep 1, 2020, at 5:22 PM, Michael Hall wrote: > >  >> >> >>> Is there a way to pass values from environment variables when using >>> --java-options? >>> >>> It would be nice to be able to write something like this: >>> --java-options "-DmyAppData=$HOME/.myData" >>> >>> (Instead of

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

> >> Is there a way to pass values from environment variables when using >> --java-options? >> >> It would be nice to be able to write something like this: >> --java-options "-DmyAppData=$HOME/.myData" >> >> (Instead of using the $ sign, another notation may be more appropriate, in >> order to

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

On 9/1/2020 11:54 AM, Michael Hall wrote: On Sep 1, 2020, at 10:30 AM, Andy Herrick wrote: I have been following this discussion , and feel it is worth pursuing. Currently , the values of --arguments and --java-options are pre-processed at launch time by expanding the values of $APPDIR,

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

> On Sep 1, 2020, at 10:30 AM, Andy Herrick wrote: > > I have been following this discussion , and feel it is worth pursuing. > > Currently , the values of --arguments and --java-options are pre-processed at > launch time by expanding the values of $APPDIR, $ROOTDIR, and $BINDIR to >

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

I have been following this discussion , and feel it is worth pursuing. Currently , the values of --arguments and --java-options are pre-processed at launch time by expanding the values of $APPDIR, $ROOTDIR, and $BINDIR to values determined by the native launchers. If we can do so without

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

> On Sep 1, 2020, at 9:23 AM, Michael Hall wrote: > > > >> On Sep 1, 2020, at 2:07 AM, Serban Iordache >> wrote: >> >> Not sure if it was clear from my previous messages, but what I am asking for >> is that the environment variables are expanded with the values they have on >> the

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

> On Sep 1, 2020, at 2:07 AM, Serban Iordache wrote: > > Not sure if it was clear from my previous messages, but what I am asking for > is that the environment variables are expanded with the values they have on > the user's machine (not on the machine where jpackage has been executed).

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

> On Aug 31, 2020, at 3:07 PM, Michael Hall wrote: > > > >> On Aug 29, 2020, at 3:37 AM, Serban Iordache >> wrote: >> >> Hi, >> >> Is there a way to pass values from environment variables when using >> --java-options? >> >> It would be nice to be able to write something like this: >>

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

> On Aug 29, 2020, at 3:37 AM, Serban Iordache > wrote: > > Hi, > > Is there a way to pass values from environment variables when using > --java-options? > > It would be nice to be able to write something like this: > --java-options "-DmyAppData=$HOME/.myData” For this couldn’t you just

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

Hi, Is there a way to pass values from environment variables when using --java-options? It would be nice to be able to write something like this: --java-options "-DmyAppData=$HOME/.myData" (Instead of using the $ sign, another notation may be more appropriate, in order to not conflict with