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, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15486534363011883928/images/FastRGraalHP/.VolumeIcon.icn

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 pa

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

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

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 exp

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

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 n

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 app

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

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 im

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

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

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

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 file assocations OS X

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? >> It is not

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 w

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

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 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 EA build 8 ( jdk-14-jpackage+1-8 )

Is jdk-14 the current target release for this? I’m seeing the following in my app. Would this mean this release actually cracks down on some reflection? Is some jdk-14 bug unrelated to jpackage? Probably uncovered some other bug of mine? Who knows? java.lang.reflect.InvocationTargetException

OS X jpackage and java.class.path

I think I may out mentioned this before but maybe I didn’t fix the problems it was causing me because I just ran into it again. So I’ll mention it again. java.class.path is somewhat inconsistent in its entries. The main jar is present as absolute path… /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir

Re: OS X jpackage and java.class.path

> On Jul 1, 2019, at 3:21 PM, Andy Herrick wrote: > > can you share the command options used launching jpackage ? > > I think I would understand better if I saw the complete command. ${PACKAGER} \ --verbose \ --input ../HalfPipe12.app/Contents/Java \ --output outputdi

Re: OS X jpackage and java.class.path

> On Jul 1, 2019, at 3:21 PM, Andy Herrick wrote: > > can you share the command options used launching jpackage ? > > I think I would understand better if I saw the complete command. > > /Andy > Fwiw legacy was all absolute… java.class.path=/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/

jpackage ROOTDIR variable in a Windows bat file

I am trying to come up with a simple Windows bat file execution of jpackage. I would like to use the builtin ROOTDIR variable. How should this be done? Not very familiar with Windows. This -Djava.security.policy=$ROOTDIR\app\all.policy Gets Error: Invalid Option: [-Djava.security.policy=$ROOTDIR

Re: jpackage ROOTDIR variable in a Windows bat file

> On Nov 23, 2019, at 10:51 AM, Kevin Rushforth > wrote: > > $ROOTDIR is not a supported interface. You should use "$APPDIR" instead. > Having said that, the real problem is likely your use of backslashes. I > recommend using forward slashes and also enclosing it in single quotes, like > t

Re: jpackage ROOTDIR variable in a Windows bat file

> > With forward slashes > > Error: Invalid Option: [-Djava.security.policy=$ROOTDIR/app/all.policy] Sorry that should of been APPDIR. manually cutting and pasting with edit since I can’t currently cut and paste directly between Windows VirtualBox and OS X.

Re: jpackage ROOTDIR variable in a Windows bat file

> On Nov 23, 2019, at 11:22 AM, Kevin Rushforth > wrote: > > I just tried this and it worked fine for me: > > jpackage --java-options '-Djava.security.policy=$APPDIR/all.policy' ... > > (note that there should not be an extra "/app" since $APPDIR points to the > app directory). > > It gen

Re: jpackage ROOTDIR variable in a Windows bat file

> On Nov 23, 2019, at 11:45 AM, Michael Hall wrote: > > > >> On Nov 23, 2019, at 11:22 AM, Kevin Rushforth >> wrote: >> >> I just tried this and it worked fine for me: >> >> jpackage --java-options '-Djava.security.policy=$APPDIR/all

Re: jpackage ROOTDIR variable in a Windows bat file

>> >> > > 1.) - you might learn more by running with --verbose ('jpackage @jpkg.txt > --verbose') if you can sift thry the excess output. > > 2.) in my test app I need to escape the '$' in front of APPDIR because > command is being processed first by shell, for example I have: ( > --java

Re: jpackage ROOTDIR variable in a Windows bat file

>>> --install-dir ./outputdir > Are you sure you want your app to be installed in %ProgramFiles%\outputdir > directory? I need to look at your detailed discussion of this. > >>> >>> --name HalfPipe >>> --runtime-image "c:/Program Files/Java/jdk-14" > --runtime-image and --add-modules paramet

Re: jpackage ROOTDIR variable in a Windows bat file

> On Nov 25, 2019, at 11:47 AM, Alexey Semenyuk > wrote: > >>> >>> --name HalfPipe >>> --runtime-image "c:/Program Files/Java/jdk-14" > --runtime-image and --add-modules parameters should not be used together. > If Java run-time image is specified with --runtime-image parameter, jpackage >

Re: jpackage ROOTDIR variable in a Windows bat file

> On Nov 26, 2019, at 2:41 PM, Alexey Semenyuk > wrote: > > > > On 11/26/2019 9:48 AM, Michael Hall wrote: >> >> >>> On Nov 25, 2019, at 11:47 AM, Alexey Semenyuk >> <mailto:alexey.semen...@oracle.com>> wrote: >>> >>&g

jpackage runtime binaries

I was wondering if there is any way to include java executable binaries like bin/java. They do not appear to be default included. Looking at help I am not seeing a specific parameter for that purpose. I do see… --runtime-image Path of the predefined runtime image that will be copie

Re: jpackage runtime binaries

> On Feb 18, 2020, at 12:53 PM, Andy Herrick wrote: > > > With the current options, the only solution for this is to run jlink > separately and used --runtime-image option. > > I had proposed the enhancement JDK-8219536 > to add an option

Re: jpackage runtime binaries

> On Feb 18, 2020, at 12:53 PM, Andy Herrick wrote: > > this could also make --bind-services option obsolete, and allow arbitrary > jlink option to replace the default set we currently use. Curious. I have a java shell application that makes limited use of saving some default settings or ot

jpackage current status

If I look at the jpackage page… The jpackage tool has been integrated into the JDK, and is now included in JDK 14 early access builds. The normal early access page now indicates release candidate and the download no longer includes -ea However, the included jpackage still shows… jpackage --h

Re: jpackage current status

> On Feb 21, 2020, at 9:27 AM, Scott Palmer wrote: > > It's included as a preview feature, so it's still incubating. > OK, I’ll include the module. Remove it later. Thanks

Re: jpackage current status

> On Feb 21, 2020, at 9:36 AM, Alan Bateman wrote: > > > > On 21/02/2020 15:23, Michael Hall wrote: >> If I look at the jpackage page… >> >> The jpackage tool has been integrated into the JDK, and is now included in >> JDK 14 early access builds.

Re: jpackage current status

> On Feb 21, 2020, at 9:39 AM, Philip Race wrote: > > Hi, > > I don't understand what you are doing here. > It is like you are copying around an application > which has dependent libraries but not copying those libraries. > > Copying bits out of the JDK to some other location isn't something

Re: jpackage current status

> On Feb 21, 2020, at 9:41 AM, Michael Hall wrote: > > > >> On Feb 21, 2020, at 9:39 AM, Philip Race wrote: >> >> Hi, >> >> I don't understand what you are doing here. >> It is like you are copying around an application >> wh

Re: jpackage current status

> On Feb 21, 2020, at 9:39 AM, Michael Hall wrote: > >> You can't copy launchers in this way as it requires the module to be in the >> run-time image. > > If I add modules it into the build runtime I think I’m ok but haven’t tried > it yet. jpackage seems t

Re: jpackage current status

> On Feb 21, 2020, at 11:12 AM, Kevin Rushforth > wrote: > > I doubt this has anything to do with jpackage being in incubator or not. > Fundamentally, just copying binary launchers into another JDK image like you > are doing is only going to work by accident, if it works at all. If you need

Re: jpackage current status

> On Feb 21, 2020, at 11:18 AM, Michael Hall wrote: > > > >> On Feb 21, 2020, at 11:12 AM, Kevin Rushforth >> wrote: >> >> I doubt this has anything to do with jpackage being in incubator or not. >> Fundamentally, just copying binary launche

Re: jpackage current status

> On Feb 22, 2020, at 10:14 AM, Tom Schindl wrote: > > At Eclipse it is tracked as > https://bugs.eclipse.org/bugs/show_bug.cgi?id=559482 > Thanks. Not quite sure what would of triggered it yesterday.

Re: jpackage current status

> On Feb 22, 2020, at 11:10 AM, Michael Hall wrote: > > > >> On Feb 22, 2020, at 10:14 AM, Tom Schindl > <mailto:tom.schi...@bestsolution.at>> wrote: >> >> At Eclipse it is tracked as >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559482

Re: jpackage current status

> On Feb 22, 2020, at 12:04 PM, Michael Hall wrote: > > > >> On Feb 22, 2020, at 11:10 AM, Michael Hall > <mailto:mik3h...@gmail.com>> wrote: >> >> >> >>> On Feb 22, 2020, at 10:14 AM, Tom Schindl >> <mailto:tom.sch

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

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

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 m

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

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

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 di

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 see

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,

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

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

> 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 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 > > In the .c

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

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

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, > /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/Blac

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

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

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 "/Users/mjh/HalfPipe/Half

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: https://webrev

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 Crashe

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

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

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

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 resourc

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 differe

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

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

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 previo

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

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

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

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 c

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. outputdir/HalfPipe.app/Contents/runtime/Conte

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

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

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.

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

  1   2   >