jpackage bugs
Michael Hall
mik3hall at gmail.com
Sat Apr 17 00:57:14 UTC 2021
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 resource is missing or invalid
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156>
The command to reproduce was provided. The error appears to be in files included in the embedded JDK not being signed. So apparently not having to do with anything of mine. (Mentioned I now see in the comments).
As I indicate this is not a serious error for me since I am not submitting the app to the Mac App Store but I believe this would get the app Apple rejected for anyone who is attempting that. A show stopper for a major use case. It seems too bad to simply close it because I missed an email asking for a reproduce.
With a reference application I could demonstrate the error against would eliminate the need to provide a separate reproducible test case. Quite sized for the application in question. Such an application is actually mentioned in the bug report comments. Could such a application be made available for download or user reproducing - the jpackage command and arguments?
I have looked a little bit at if to see if I can figure out how to sign the embedded jdk files. So far only accomplishing that I can no longer simply use my name for signing but have to use my fully qualified security identity.
The question now seems to be what is in fact the difference between mine and the, unavailable to me, reference application as to these files verifying as correctly signed.
A second bug
JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect
I thought a fix for this was all set to go in and was pulled. It was apparently determined that the problem only applies if the —install-dir parameter is used for DMG’s. Where it really makes no sense. My use apparently held over from when I was just creating the app.I thought this had somehow also in some way regressed to not reproducible. I still think a fairly simple change to the AppleScript as was originally planned would resolve the issue independently of parameters. The default DMG build I would think should _always_ indicate installation to the Applications folder.
With —install-dir this remains a reproducible bug for me at 17-ea.
If a reference build was provided somewhere I might have picked up on the parameter difference sooner.
More information about the core-libs-dev
mailing list