Re: [External] : Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

> On Jun 7, 2022, at 9:21 PM, Alexander Matveev > wrote: > > Hi Michael, > > Yes, this is correct. It is a three step process as you outlined it below. > Alexander, Could you post an example of the three invocations, without needing to include any post-processing, to 1) create app-image

Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

Alexander, I had an existing local GitHub repo for the jdk I updated that appeared to accept the parameters you indicated. It generated a jdk 19. If you are saying I’m not getting the main branch or the update for some reason has dependencies I’m not getting I would have to determine how to

Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

> > ./build/*/images/jdk/bin/jpackage --app-image > ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign > --mac-signing-key-user-name "Developer ID Application: Michael Hall > (5X6BXQB3Q7)" > Bundler Mac DMG Package skipped because of a configuration proble

Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

> On Jun 5, 2022, at 8:56 AM, Michael Hall wrote: > > > Fwiw, I was going to take a look at this but my build failed. > > === Output from failing command(s) repeated here === > * For target support_native_java.desktop_liblcms_cmstypes.o: > /Users/mjh/Documents/Git

Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

Fwiw, I was going to take a look at this but my build failed. === Output from failing command(s) repeated here === * For target support_native_java.desktop_liblcms_cmstypes.o: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter

Re: RFR: 8286850: [macos] Add support for signing user provided app image

Thank you.

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

> On May 19, 2022, at 7:14 PM, Michael Hall wrote: > > > >> >> Alexander >> >>> >>> I think it will be a problem to implement this for native launchers. >> > > Basically you are telling the developer in

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

> > Alexander > >> >> I think it will be a problem to implement this for native launchers. > Basically you are telling the developer in https://bugs.openjdk.java.net/browse/JDK-8286122 that it isn’t currently possible for their

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

> On May 19, 2022, at 5:38 PM, Alexander Matveev > wrote: > > Hi Michael, Alexander > > I think it will be a problem to implement this for native launchers. Each of the native commands is it’s own app launcher? I didn’t know this. I don’t think it was ever really indicated in the

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

> On May 11, 2022, at 4:39 PM, Alexander Matveev > wrote: > > - It is not possible to support native JDK commands such as "java" inside Mac > App Store bundles due to embedded info.plist. Workarounds suggested in > JDK-8286122 does not seems to be visible. I was just thinking about this.

Re: [External] : Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

> On May 17, 2022, at 12:15 AM, Alexander Matveev > wrote: > > Hi Michael, > > I filed following enhancement for signing user provided app image and yes it > will be two step process. Invoke jpackage to generate image, then user can > modified it and then invoke jpackage again to sign it.

Re: [External] : Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

> On May 16, 2022, at 7:09 PM, Alexander Matveev > wrote: > > Hi Michael, > >> I’m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]

> On May 12, 2022, at 3:13 PM, Magnus Ihse Bursie wrote: > > On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev > wrote: > >>> - It is not possible to support native JDK commands such as "java" inside >>> Mac App Store bundles due to embedded info.plist. Workarounds suggested in >>>

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

> > My primary suggestion would to be to use an UUID for the unique ID. They are > of fixed length, are for all intents and purposes unique and you can conjure > them up from your hat. (An alternative is that the user needs to specify a > unique ID, but that is probably a less ideal

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

> On May 12, 2022, at 4:42 AM, Magnus Ihse Bursie > wrote: > >> Some further spelunking reveals the issue. Consider this: >> >> % otool -s __TEXT __info_plist -v >> APP_NAME.app/Contents/runtime/Contents/Home/bin/java >> … >> >> CFBundleIdentifier >> net.java.openjdk.java >> … >>

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

Alexander > On May 11, 2022, at 11:38 PM, Alexander Matveev > wrote: > > Hi Michael, > >> On May 11, 2022, at 3:17 PM, Michael Hall wrote: >> >> Is this restricted somehow to Mac App Store applications? > Yes, helper tools (in our case JDK native comman

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

> On May 11, 2022, at 5:17 PM, Michael Hall wrote: > > I’m not real familiar with the build process. But would it be possible for > the user to build their own jdk that substitutes something else for the > colliding identifier that gets embedded? Or just change it in the c

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

Is this restricted somehow to Mac App Store applications? Is a warning issued as stripping native commands may break application functionality? Is it not possible for the user to provide their own Info.plist with a different bundle identifier that doesn’t collide? I’m not real familiar with

Re: RFR: JDK-8277375: jdeps errors on a class path with a file path with no permission

> On Nov 29, 2021, at 1:14 PM, Mandy Chung wrote: > > On Wed, 24 Nov 2021 12:32:32 GMT, Michael Hall wrote: > >> Would there be any need to scan class path at all? That would mean a module >> would have a class path dependency wouldn't it? > > One rea

Re: RFR: JDK-8277375: jdeps errors on a class path with a file path with no permission

> On Nov 24, 2021, at 5:51 AM, Michael Hall wrote: > > > >> On Nov 24, 2021, at 2:55 AM, Alan Bateman wrote: >> >> On Wed, 24 Nov 2021 01:12:01 GMT, Mandy Chung wrote: >> >>> This changes jdeps -cp to ignore files/directories with no p

Re: RFR: JDK-8277375: jdeps errors on a class path with a file path with no permission

> On Nov 24, 2021, at 2:55 AM, Alan Bateman wrote: > > On Wed, 24 Nov 2021 01:12:01 GMT, Mandy Chung wrote: > >> This changes jdeps -cp to ignore files/directories with no permission to >> access. This is consistent with the runtime behavior. > >

Re: RFR: JDK-8277375: jdeps errors on a class path with a file path with no permission

> On Nov 23, 2021, at 7:19 PM, Mandy Chung wrote: > > This changes jdeps -cp to ignore files/directories with no permission to > access. This is consistent with the runtime behavior. > > - > > Commit messages: > - JDK-8277375: jdeps errors on a class path with a file path with

Re: [External] : Re: jpackage - notarizing

> On Nov 22, 2021, at 9:01 PM, Kevin Rushforth > wrote: > > By way of clarification, JNF was never part of the JDK. What we removed was > the JDK's *usage* of JNF. And we did so because Apple deprecated it and never > even provide a JNF framework for aarch64. > > Applications either need

Re: jpackage - notarizing

> On Nov 22, 2021, at 12:39 PM, Alan Snyder wrote: > > >> On Nov 22, 2021, at 10:12 AM, Kevin Rushforth >> wrote: >> >> JNF was removed from the JDK if that's what you are asking. > > > > Indeed, that is why there is an issue. > > The JDK may not be using JNF, but library developers

Re: jpackage - notarizing

> On Nov 22, 2021, at 11:59 AM, Alan Snyder wrote: > > I’m talking about the Xcode project for JNF. > I thought I was too. Unless it’s changed since I cloned or the one I’m looking at is somehow different. The URL I saved was https://github.com/apple/openjdk/

Re: jpackage - notarizing

> On Nov 22, 2021, at 11:44 AM, Alan Snyder wrote: > > JNF is just an Objective-C library that uses jni.h. Otherwise, it is not > dependent on the JDK. > >> On Nov 22, 2021, at 9:23 AM, Michael Hall wrote: >> >> >> >>> On Nov 22, 2021, at

Re: jpackage - notarizing

> On Nov 22, 2021, at 10:40 AM, Alan Snyder wrote: > > I’m still hoping someone will step up to provide a home for the compiled > JavaNativeFoundation framework. > > In any case, the sources are available and you can build it yourself. > > https://github.com/apple/openjdk.git

jpackage - notarizing

While I was looking at —mac-dmg-content I thought I would also look at notarization. I had downloaded my app on an older machine while my new was being serviced and got uninviting messages about Apple being unable to determine it was full of malware. Notarization I found out was supposed to be

Re: jpackage --mac-dmg-content

Nit, if you open the dmg the additional content doesn’t quite fit in the bottom of the window. My thought had been smaller icons for the additional. This doesn’t seem possible?

jpackage --mac-dmg-content

[08:26:41.669] jdk.jpackage.internal.PackagerException: Error: Option [--mac-dmg-content] is not valid with type [default] dmg is the default type? Why should this be an error?

Re: RFR: JDK-8263155: Allow additional contents for DMG

> On Oct 14, 2021, at 5:12 PM, Andy Herrick wrote: > > On Tue, 12 Oct 2021 16:47:04 GMT, Andy Herrick wrote: > >> JDK-8263155: Allow additional contents for DMG > > This enhancement adds a command line option "--mac-dmg-content" that can be > used to add any other content to a dmg image.

Re: JPackage and ask for microphone permissions broken on OSX...

> On Aug 25, 2021, at 8:40 AM, Alan Snyder wrote: > > > >> On Aug 24, 2021, at 6:52 AM, Andy Herrick wrote: >> >> One final thing to note, MacOS keeps track of what you have ever previously >> granted microphone permission to (and will never ask again) based on the mac >> package

Re: [External] : Re: jpackage OS/X JDK-8263157 fix regressed out

> On Jul 22, 2021, at 1:46 PM, Alexey Semenyuk > wrote: > > Oh, inconsistent path separators indeed. Good catch! This is the reason it > doesn't work as it should. > Filed https://bugs.openjdk.java.net/browse/JDK-8271155 to track it. > > - Alexey > > Thank you.

Re: jpackage OS/X JDK-8263157 fix regressed out

> On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk > wrote: > > The fix for JDK-8263157 cleared the default value of `java.library.path` > system property and resulted in JDK-8267598 regression. So the fix for > JDK-8263157 was reworked: jpackage doesn't set `java.library.path` system >

jpackage OS/X JDK-8263157 fix regressed out

JDK-8263157 [macos]: java.library.path is being set incorrectly The fix for this seems to be gone in both current jdk17 and jdk18 releases. There is no ‘app’ directory included in java.library.path.

Re: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found

> On Jul 21, 2021, at 3:57 PM, Andy Herrick wrote: > > Looks like an instance of: JDK-8260335 > : [macos] Running app > using relative path causes problems (fixed in jdk17 build b09) > > you can try builds from https://jdk.java.net/17/ to

Re: jpackage GraalVM on Windows 10

> On May 20, 2021, at 6:45 PM, Michael Hall wrote: > > Has anyone done this who can indicate how it should be done? > It seems to be the non-standard JDK name. I renamed it to jdk-11 and it worked. Letting it default still set it to the current jdk-16 even though that was l

jpackage GraalVM on Windows 10

Has anyone done this who can indicate how it should be done? I recently set this up for my app on OS/X and thought I’d have cross platform versions. I have tried it both with —runtime-image and making Graal the installed JVM. Both ways I seem to get an application with directory structure

Re: jpackage java commands

> On May 19, 2021, at 9:40 AM, Andy Herrick wrote: > > I don't think jlink will ever include the jdk development tools in a custom > runtime (using jlink on windows or mac without --strip-native-commands only > gives me java and keytool), Mac gave me the 9 commands shown earlier. Something

jpackage java commands

I added --jlink-options '--strip-debug --no-man-pages --no-header-files’ to my invocation, avoiding --strip-native-commands, so that the native java commands are not stripped. I believe currently recommended jpackage way to do this. I get the following commands in my embedded JDK java

Re: Jpackage Mac entitlements

> On Apr 22, 2021, at 7:41 AM, Andy Herrick wrote: > > > On 4/21/2021 6:15 PM, Michael Hall wrote: >> Reverted to Jdk 16 and temporarily couldn’t figure out why AppleScript >> wasn’t working again. >> >> I needed to provide an entitlement. A

Jpackage Mac entitlements

Reverted to Jdk 16 and temporarily couldn’t figure out why AppleScript wasn’t working again. I needed to provide an entitlement. At jpackage 16 I found I needed to do this differently with a .entitlements file in the resources directory, as I noticed in the verbose command output. I had

Re: jpackage bugs

> On Apr 17, 2021, at 9:37 AM, Michael Hall wrote: > > So apparently ‘cp’ is not a good idea on a signed application. At least not > on a signed java one. Fyi for anyone who wants to copy a Mac signed java app from a script or maybe from java Runtime. Instead of… cp -r /Volu

Re: jpackage bugs

> On Apr 17, 2021, at 9:14 AM, Michael Hall wrote: > >> only executables and libraries are signed - this tool running across the >> whole app will find unsigned files, that would be expected. > > Hmm. ok. Is the jdk separately signed? Would something in cop

Re: jpackage bugs

> On Apr 17, 2021, at 9:14 AM, Michael Hall wrote: > >>>> >>>> With —install-dir this remains a reproducible bug for me at 17-ea. >> yes - but what is value of "--install-dir" - can you insure it is a fully >> qualified directory path that

Re: jpackage bugs

> On Apr 17, 2021, at 8:57 AM, Andy Herrick wrote: > > > On 4/17/2021 1:14 AM, David Holmes wrote: >> Hi Michael, >> >> On 17/04/2021 10:57 am, Michael Hall wrote: >>> Is there anyway to get a simple/test reference type application available >>

Re: jpackage bugs

> On Apr 17, 2021, at 12:14 AM, David Holmes wrote: > >> > > Note the bug referenced is closed as "incomplete" - that is a temporary state > while awaiting additional information (usually from the submitter). If we > never hear back from the submitter then it will be closed with a

jpackage bugs

Is there anyway to get a simple/test reference type application available that could be used in reproducing bugs? I had two I think potentially serious bugs that were basically not addressed for problems in reproducing. JDK-8263156 : [macos]: OS X application signing concerns - a sealed

Re: jpackage ea-17 --mac-entitlements

> On Apr 9, 2021, at 9:27 PM, Michael Hall wrote: > >> >> OK, probable user error. I eliminated my entitlement changes and it worked. >> > Related to the same functionality that I am trying to add, I should, or have > to, make changes to my Info.p

Re: jpackage ea-17 --mac-entitlements

> On Apr 9, 2021, at 9:27 PM, Michael Hall wrote: > > Although I believe > codesign -v --verbose=4 outputdir/HalfPipe.app > This verify would be sufficient to reproduce that error for any(?) jpackage > Developer signed application. An additional thought on this migh

Re: jpackage ea-17 --mac-entitlements

> > OK, probable user error. I eliminated my entitlement changes and it worked. > Related to the same functionality that I am trying to add, I should, or have to, make changes to my Info.plist This being the addition of NSAppleEventsUsageDescription. If I remember correctly in prior discussion

Re: jpackage ea-17 --mac-entitlements

> On Apr 9, 2021, at 6:59 PM, Michael Hall wrote: > > Should bug reports be written against this yet? > > I codesign generated a entitlements file and then tried adding… > >com.apple.private.tcc.allow-prompting > > > I added this to my invoc

jpackage ea-17 --mac-entitlements

Should bug reports be written against this yet? I codesign generated a entitlements file and then tried adding… com.apple.private.tcc.allow-prompting I added this to my invocation… --mac-entitlements “entitlements.xml" And the app crashed… System Integrity Protection: enabled

Re: RFR: JDK-8263154: [macos] DMG builds have finder errors

Thanks > On Mar 13, 2021, at 8:45 AM, Andy Herrick wrote: > > JDK-8263154: [macos] DMG builds have finder errors > > - > > Commit messages: > - JDK-8263154: [macos] DMG builds have finder errors > > Changes: https://git.openjdk.java.net/jdk/pull/2987/files > Webrev:

Jpackage GraalVM OS X

This appears to no longer work at all as a included JRE With… --runtime-image /Library/Java/JavaVirtualMachines/graalvm-ce-java11-21.0.0/Contents/Home \ It fails to launch. Launch CLI outFastR/FastRGraalHP.app/Contents/MacOS/FastRGraalHP Failed to find JVM in

Re: jpackage problem submitting to Apple Store

> On Feb 1, 2021, at 9:02 AM, Andy Herrick wrote: > > This step is required to post app on web where it can be downloaded and run > on other machines running MacOS Catalina or later. This is probably all I’d be looking at for now. I’m looking at an app I wrote a year or two back with

Re: bug jpackage in JDK 15

> On Jan 29, 2021, at 7:37 PM, Michael Hall wrote: > > > >> On Jan 26, 2021, at 7:16 PM, Michael Hall > <mailto:mik3h...@gmail.com>> wrote: >> >>> >>> >>> When I open the built dmg there is an application icon, a drag to &

Re: bug jpackage in JDK 15

> On Jan 26, 2021, at 7:16 PM, Michael Hall wrote: > >> >> >> When I open the built dmg there is an application icon, a drag to indicating >> arrow, but no application folder icon as the drag target. >> >> Possibly related… >

Re: bug jpackage in JDK 15

> > When I open the built dmg there is an application icon, a drag to indicating > arrow, but no application folder icon as the drag target. > > Possibly related… > > Running [osascript, >

Re: jpackage problem submitting to Apple Store

> On Jan 25, 2021, at 6:36 AM, John Crowley wrote: > > As an alternate, a link to Google Drive - > https://drive.google.com/drive/folders/1SgLhlovuH2x18gRh-ffhZCHVeXt1AOXo?usp=sharing > > > The

Re: jpackage problem submitting to Apple Store

> On Jan 24, 2021, at 8:28 AM, John Crowley wrote: > > Hi All, > > Have been having a problem trying to use jpackage to sign an app and submit > it to the Apple Store. > > Attached are the following: No attachments that I’m seeing.

Re: bug jpackage in JDK 15

> On Jan 24, 2021, at 7:37 AM, Michael Hall wrote: > > > --name 'VARS Annotation’ > > You are using a name with an embedded blank but that didn’t seem to cause me > any problems. > > I didn’t recreate, maybe if I get a chance I’ll try to see if anything else

Re: bug jpackage in JDK 15

--name 'VARS Annotation’ You are using a name with an embedded blank but that didn’t seem to cause me any problems. I didn’t recreate, maybe if I get a chance I’ll try to see if anything else in your invocation seems to trigger what you’re seeing.

Re: bug jpackage in JDK 15

> On Jan 23, 2021, at 7:07 PM, Michael Hall wrote: > > Also it seems... > --add-modules java.desktop,java.prefs,java.se <http://java.se/> \ > > Is no longer an option? > —help doesn’t show it and I end up with… > java-options=--module-path > &g

Re: bug jpackage in JDK 15

> On Jan 23, 2021, at 7:07 PM, Michael Hall wrote: > > > >> On Jan 23, 2021, at 6:02 AM, Michael Hall wrote: >> >> >>> >>> "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" # >>> JDK15 >&

Re: bug jpackage in JDK 15

> On Jan 23, 2021, at 6:02 AM, Michael Hall wrote: > > >> >> "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" # >> JDK15 >> "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14 >> > > An

Re: bug jpackage in JDK 15

> > "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" # > JDK15 > "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14 > Any chance the embedded blank in the app name is throwing something off?

Re: jpackage OS X codesign IOException

> On Sep 26, 2020, at 6:57 AM, Michael Hall wrote: > > java.io.IOException: Command [codesign, -s, Developer ID Application: X > (X), -, > /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage16414030388823297270/images/image-18070619850311

Re: jpackage OS X codesign IOException

> On Sep 26, 2020, at 7:13 AM, Michael Hall wrote: > > > >> On Sep 26, 2020, at 7:09 AM, Bernd Eckenfels wrote: >> >> Looks like the codesign command is not in your PATH >> > > which codesign > /usr/bin/codesign > PATH= … /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin ...

Re: jpackage OS X codesign IOException

> On Sep 26, 2020, at 7:09 AM, Bernd Eckenfels wrote: > > Looks like the codesign command is not in your PATH > which codesign /usr/bin/codesign

jpackage OS X codesign IOException

java.io.IOException: Command [codesign, -s, Developer ID Application: X (X), -, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage16414030388823297270/images/image-1807061985031173/HalfPipe.app] exited with 1 code X values changed by me

Re: Jpackage file assocations OS X

> On Sep 22, 2020, at 7:35 PM, alexander.matv...@oracle.com wrote: > > Hi Michael, > > For file association you will need to create property file and pass it to > jpackage via --file-associations. Thanks for the detailed reply. I will look closer at it later. I had found the test class. I

Re: Jpackage file assocations OS X

path to the associated file is not passed as an argument (as it > is on Linux and Windows). > > /Andy > > On 9/20/2020 8:40 PM, Michael Hall wrote: >> Are there any examples or further information on how the file association >> property file should work? &

Jpackage file assocations OS X

Are there any examples or further information on how the file association property file should work? It is not entirely clear to me from the command help.

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

> > 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 > <mailto:mik3h...@gmail.com>> wrote: >> >> >> >>> On Sep 2, 2020, at 10:07 PM, Scott Palmer >> <mailto:swpal...@gma

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

> 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

> 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

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

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

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

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

jpackage environment variables - OS X

Is there a way on OS X to set these in the Info.plist?

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

OS X jpackage exception FYI

Doesn’t appear to be causing any problems to the application build? WARNING: Using incubator modules: jdk.incubator.jpackage 14.0.2 Running [/usr/bin/SetFile, -c, icnC,

Re: jpackage and alternate JRE's - OS X

> On Mar 17, 2020, at 3:28 PM, Andy Herrick wrote: > > But the executables in the jdk itself are signed, including those packaged as > a resource like jpackageapplauncher itself. Not that there isn’t good reason to do this but it appears to be the issue for GraalVM. I set up a shell script

Re: jpackage and alternate JRE's - OS X

itself. > > The app executable itself, in your case > FastRGraalHP.app/Contents/MacOS/FastRGraalHP, is a copy of jpackageapplauncher > > /Andy > > On 3/17/2020 4:04 PM, Michael Hall wrote: >> >>> >>> codesign -dv outFastR/FastRGraalHP.app >>

Re: jpackage and alternate JRE's - OS X

> > > codesign -dv outFastR/FastRGraalHP.app > Executable=/Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/MacOS/FastRGraalHP > Identifier=jpackageapplauncher > … > > It does appear that jpackage is doing some default code signing. > Running verbose I see no indication,

jpackage and alternate JRE's - OS X

I was looking at GraalVM in order to try out FastR, a jre based R language implementation. It seemed to me if it was actually a standalone JRE I should be able to use jpackage to turn it into an application. Or use my usual application for trying things out but just replace the runtime. It

Re: jpackage current status

> On Feb 24, 2020, at 4:07 PM, Andy Herrick wrote: > > > > > then in app you can find any of the tools by using > System.getProperty("java.home") and looking in "bin" subdir. > > So in the app you can refer to any of the tools by their full path. > Not to keep dragging this on. But I

Re: jpackage current status

> > now you can build runtime that has the tools like I do here: > >> $JDK_HOME/bin/jlink --bind-services --output mods.runtime --add-modules >> me.mymodule --module-path '../input-mods/mods' > (../input-mods/mods has my app in me.mymodule) > > then in app you can find any of the tools by

Re: jpackage current status

> On Feb 24, 2020, at 2:59 PM, Kevin Rushforth > wrote: > > > > On 2/24/2020 12:31 PM, Michael Hall wrote: >> >>> On Feb 24, 2020, at 1:48 PM, Michael Hall wrote: >>> >>> >>> >>>> On Feb 24, 2020, at 1:15 PM

Re: jpackage current status

> On Feb 24, 2020, at 1:48 PM, Michael Hall wrote: > > > >> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth >> wrote: >> >> Since your ToolProvider-based program doesn't explicitly require >> jdk.incubator.jpackage, it won't be in the module

Re: jpackage current status

> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth > wrote: > > Since your ToolProvider-based program doesn't explicitly require > jdk.incubator.jpackage, it won't be in the module graph. It should work fine > if you run with: > > $ java --add-modules jdk.incubator.jpackage ... > I’m not

Re: jpackage current status

> On Feb 24, 2020, at 11:16 AM, Michael Hall wrote: > > > >> On Feb 24, 2020, at 11:12 AM, Andy Herrick > <mailto:andy.herr...@oracle.com>> wrote: >> >> We have no problem invoking jpackage through the tool provider interface in >> all

Re: jpackage current status

> On Feb 24, 2020, at 11:12 AM, Andy Herrick wrote: > > We have no problem invoking jpackage through the tool provider interface in > all of our test cases. > > In previous emails you described using a hybrid jdk13/jdk14 jdk. Can you > explain what exactly you are using ? > > /Andy I was

  1   2   >