Apologies for the spam. This was my issue, I got confused renewing my certs, as to which one did what. Apple have not changed the prefix, and despite warnings about notarising, it seems to all work. Just wish there weren’t so many cert types flying around to sign an app!
Meantime, crisis over and patch distributed, I’ll work to migrate to jpackage. Thanks Alan > On 9 Jul 2019, at 18:51, Alan White <a...@whiteware.org> wrote: > > Hi Johan > > Been using the gluon packager successfully on windows and macOS, awaiting the > release of the JEP343 (I think) one - thank you (from me and my user base)! > > I just had to renew my Apple developer cert that’s used for signing and > discover that Apple have changed the CN in the developer cert from “Developer > ID Application:” to “Mac Developer:”. Checking > https://github.com/johanvos/openjdk-mobile11/blob/packager/src/jdk.packager/macosx/classes/jdk/packager/internal/mac/MacAppBundler.java > > <https://github.com/johanvos/openjdk-mobile11/blob/packager/src/jdk.packager/macosx/classes/jdk/packager/internal/mac/MacAppBundler.java> > I see the CN prefix is hard-coded, so my options appear to be fork, edit > rebuild. > > Anyone aware of any other options, or is now the time to switch to the early > access jpackage plse? > > Thanks > Alan > >> On 19 Dec 2018, at 18:10, Johan Vos <johan....@gluonhq.com >> <mailto:johan....@gluonhq.com>> wrote: >> >> The packager that works with Java 11 and JavaFX 11 is at >> >> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-osx.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip >> >> <http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-osx.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip> >> >> (see >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html >> ). >> >> However, I highly recommend testing the early access version of jpackage. >> That is the way forward for the packager. >> >> - Johan >> >> >> On Wed, Dec 19, 2018 at 6:36 PM Kevin Rushforth <kevin.rushfo...@oracle.com> >> wrote: >> >>> I doubt that will work. >>> >>> We are developing a replacement tool, jpackage [1], which will be part >>> of OpenJDK. It is planned for JDK 13, and will support JDK 11 or later >>> as a Java runtime. You can download an early access of this tool on >>> jdk.java.net [2]. Discussion on jpackage is happening on the >>> core-libs-dev mailing list [3]. Alternatively, Gluon has a standalone >>> version of javapackager that will work with JDK 11. Johan Vos can >>> provide a pointer. >>> >>> -- Kevin >>> >>> [1] https://openjdk.java.net/jeps/343 >>> [2] http://jdk.java.net/jpackage/ >>> [3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev >>> >>> On 12/19/2018 5:28 AM, Alan White (Drum Score Editor) wrote: >>>> I understand the guidance for apps created with OpenJDK 11, is to use >>> the javapackager from jdk 10. >>>> >>>> The old basedir parameter that could be used to direct the packager to >>> use a specific runtime is no longer present. >>>> >>>> Is there any mechanism I’ve missed in order to have the packager from >>> jdk10 bundle the 11 runtime plse? >>>> >>>> Thanks >>> >>> >
