> On Sep 20, 2022, at 5:01 PM, Michael Hall <mik3h...@gmail.com> wrote:
> 
> 
> 
>>>> 
>>>> 
>>> 
>>> Alexander,
>>> 
>>> I think I figured out how to include PR’s in my build and this appears good.
>>> 
>>> codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack 
>>> Blastoff_Unsigned.app"
>>> /Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: valid 
>>> on disk
>>> /Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: 
>>> satisfies its Designated Requirement
>>> 
>>> This was new…
>>> Warning: Support for per-user configuration of the installed application 
>>> will not be supported due to missing "BlackJack 
>>> Blastoff_Unsigned.app/Contents/app/.package" in predefined signed 
>>> application image.
>>> 
>>> I’m not quite sure what it’s saying but it doesn’t seem to impact what I’m 
>>> doing.
>> 
>> This warning means that support for per-user configuration of the installed 
>> application will be disabled. We added support for per-user configuration 
>> with https://bugs.openjdk.org/browse/JDK-8250950 
>> <https://bugs.openjdk.org/browse/JDK-8250950> (Allow per-user and system 
>> wide configuration of a jpackaged app).
>> 
>> Thanks,
>> Alexander
>> 
> 
> Alexander,
> 
> I’ll take a look. It sounds like it could be a useful feature at times. The 
> last update still works for me.
> 
> Thanks again,
> Mike

Alexander, 
One thing I notice is that 
Release Note: Allow per-user and System Wide Configuration of a jpackaged app
https://bugs.openjdk.org/browse/JDK-8288249 
<https://bugs.openjdk.org/browse/JDK-8288249>
Mentions…
~/Library/Application Support/${PACKAGE_NAME} 
Which would be a per user location. But doesn’t mention
/Library
Which would be the system level location.

Since both of these locations are external to the application bundle I’m not 
understanding why they would no longer work with whatever you changed.
I may need to look closer.
Given that this does break that, one possibility might be to include parameter 
changes in the Info.plist file. Some time back Apple java applications used to 
include a java dictionary in the plist that was more or less equivalent to the 
jpackage .cfg file. Maybe a override mechanism could be added to that which 
would be up to the developer to add in post processing. 
Customizing the Info.plist file is still the main thing I am considering doing 
for this feature.
Another recent thought was that I could use this to add a hsdis dylib to the 
jdk lib directory for an application to allow printing disassembly. But then I 
noticed it doesn’t appear that hsdis is even needed in recent jdk’s? 
-XX:+PrintAssembly seems to just work. Still you could use post-processing to 
add whatever java binary executable commands you wanted. This again would mean 
changes to the embedded jdk that might have signing side effects. I haven’t 
tested.  

Mike



Reply via email to