Re: Javapackager 10 to bundle OpenJDK 11 runtime

[Alan White]

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

Re: Javapackager 10 to bundle OpenJDK 11 runtime

[Johan Vos]

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

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

Re: Javapackager 10 to bundle OpenJDK 11 runtime

[Alan White (Drum Score Editor)]

Thanks. I’ll grab the Glueon ones for now to finish the app migration to 11, ie 
get off jdk 8 before January, and start working with the EA jpackager and 
migrate when suitable. 

Alan

> On 19 Dec 2018, at 13:51, Kevin Rushforth  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
> 

Re: "javapackager" in no-mans-land?

[Johan Vos]

Auto-update and a packager are different things.
Both are needed, but at this moment, there is only a JEP for the packager.

I think it would be wise to have a standard (hence a JEP) for auto-update
as well, as the use case you describe is not unique...

- Johan

On Sun, Sep 23, 2018 at 8:40 AM Kamlesh Prajapati
 wrote:

> Hi,
>
> Thanks for your replay.
>
> I found exe build using maven with 'javafx-maven-plugin' Or Inno Setup tool
> but My project is update release every 2 week. so auto update tool for
> manage inside client system.
>
> Also i found auto update tool Like
> https://github.com/edvin/fxlauncher
> https://github.com/update4j/update4j
>
> But which is long term support with all java update.
>
>
>
>
> On Fri, Sep 21, 2018 at 2:59 AM Kevin Rushforth <
> kevin.rushfo...@oracle.com>
> wrote:
>
> > On 9/20/2018 12:05 PM, Kamlesh Prajapati wrote:
> > > Currently , I used javafx 8 with JNLP Application.
> > >
> > > Is JNLP application support in javafx11 + java11 ?
> >
> > The deployment stack, including Java Web Start and Applet support, has
> > been removed from JDK 11. You will either need to find an alternative to
> > Java Web Start or keep your application on JDK 8. Packaging your
> > application with the JDK might be an alternative to Java Web Start. If
> > so, the new jpackager tool could help you, in which case an interim
> > solution would be to use use the javapackager, either the one from JDK
> > 10 or an unbundled javapackager, as suggested by others.
> >
> > > Any idea about auto update application in win(exe),mac,linux base
> > > application ?
> >
> > Auto-update is something the application would need to provide.
> >
> > -- Kevin
> >
> >
>
> --
> Thanks With Regards,
> Kamlesh Prajapati
>

Re: "javapackager" in no-mans-land?

[Kamlesh Prajapati]

Hi,

Thanks for your replay.

I found exe build using maven with 'javafx-maven-plugin' Or Inno Setup tool
but My project is update release every 2 week. so auto update tool for
manage inside client system.

Also i found auto update tool Like
https://github.com/edvin/fxlauncher
https://github.com/update4j/update4j

But which is long term support with all java update.




On Fri, Sep 21, 2018 at 2:59 AM Kevin Rushforth 
wrote:

> On 9/20/2018 12:05 PM, Kamlesh Prajapati wrote:
> > Currently , I used javafx 8 with JNLP Application.
> >
> > Is JNLP application support in javafx11 + java11 ?
>
> The deployment stack, including Java Web Start and Applet support, has
> been removed from JDK 11. You will either need to find an alternative to
> Java Web Start or keep your application on JDK 8. Packaging your
> application with the JDK might be an alternative to Java Web Start. If
> so, the new jpackager tool could help you, in which case an interim
> solution would be to use use the javapackager, either the one from JDK
> 10 or an unbundled javapackager, as suggested by others.
>
> > Any idea about auto update application in win(exe),mac,linux base
> > application ?
>
> Auto-update is something the application would need to provide.
>
> -- Kevin
>
>

-- 
Thanks With Regards,
Kamlesh Prajapati

Re: "javapackager" in no-mans-land?

[Kevin Rushforth]

On 9/20/2018 12:05 PM, Kamlesh Prajapati wrote:

Currently , I used javafx 8 with JNLP Application.

Is JNLP application support in javafx11 + java11 ?


The deployment stack, including Java Web Start and Applet support, has 
been removed from JDK 11. You will either need to find an alternative to 
Java Web Start or keep your application on JDK 8. Packaging your 
application with the JDK might be an alternative to Java Web Start. If 
so, the new jpackager tool could help you, in which case an interim 
solution would be to use use the javapackager, either the one from JDK 
10 or an unbundled javapackager, as suggested by others.



Any idea about auto update application in win(exe),mac,linux base
application ?


Auto-update is something the application would need to provide.

-- Kevin

Re: "javapackager" in no-mans-land?

[Lennart Börjeson]

Java Webstart is gone in Java 11.

This means there are no means left to build and distribute standalone Java 
applications across multiple platforms. 

Java Webstart was deprecated since the “old model” of having a separate 
system-wide JRE capable of running Java programs from different sources, was 
supposedly outmoded by the “new model”, i.e. stand-alone apps, complete with 
their own bundled JRE. ...but then all means to create a stand-alone 
application was also deprecated and removed. 

If you need webstart or application packaging, you must wait for the proposed 
jpackager, and remain at Java 10 until then. 


/Lennart Börjeson

Electrogramma ab iPhono meo missum est

> 20 sep. 2018 kl. 21:05 skrev Kamlesh Prajapati 
> :
> 
> Hi,
> 
> Currently , I used javafx 8 with JNLP Application. 
> 
> Is JNLP application support in javafx11 + java11 ?
> 
> Any idea about auto update application in win(exe),mac,linux base application 
> ?
> 
> 
> 
> 
> 
>> On Wed, Sep 19, 2018 at 11:54 AM Lennart Börjeson  wrote:
>> It was migrated, but removed...
>> 
>> The recommended work-around is to use the javapackager in OracleJDK 10 when 
>> packing Java/OpenJfx 11 applications.
>> 
>> That may or may not be practical depending on your build setup. Also, if 
>> you’re currently using the UserJvmOptions services, these are also gone in 
>> Java/OpenJfx 11, and it would complicate the build process even further if 
>> you were required to separate the parts needing to compile with OracleJDK 
>> 10, too.
>> 
>> I’m using Gradle to build my project, and it is currently dependent on the 
>> javafx-Gradle-plugin to package. To upgrade to Java/OpenJfx 11, and still 
>> keep the javapackager, I would need to refactor:
>> 
>> 1) my code base, to separate the parts needed to compile with OracleJDK 10 
>> to get the UserJvmOptions,
>> 2) my Gradle structure, to run in three steps (compile some parts with 10, 
>> compile most parts with 11, package all with 10 while still linking most 
>> from 11).
>> 
>> It’s too much for me. I’ve decided to remain at Java 10 and wait until 
>> there’s a javapackager replacement. The javafx-Gradle-plugin has also been 
>> deprecated due to the loss of the javapackager, so I’m stuck anyway with 
>> Java 10 unless I rework my entire build structure substantially. I’m hoping 
>> for a future Gradle plugin replacement.
>> 
>> Seriously, it would be much easier to build my own JDK with OpenJfx, the 
>> javapackager and UserJvmOptions Service still bundled with it, but then I’d 
>> step up to a completely different level of support commitment...
>> 
>> /Lennart Börjeson
>> Epistula electronica a meo computatro tabulari missa est
>> 
>> > 18 sep. 2018 kl. 22:37 skrev Tom Golden :
>> > 
>> > I understand that along with JavaFX being removed from the Oracle JDK
>> > distribution in Java 11, the Oracle team will no longer release the
>> > `javapackager` tool.
>> > 
>> > I also see there is a JEP discussing an eventual replacement, JEP-343 (
>> > http://openjdk.java.net/jeps/343).
>> > 
>> > Just to confirm, the tool was NOT migrated to OpenJFX with the rest of the
>> > JavaFX code, correct? So until JEP-343 is implemented in a future release
>> > (?) there is no "official" way to package native installers for JavaFX
>> > applications?
>> > 
>> > If so, is it in theory still possible to use the Oracle javapackager tool
>> > from earlier releases? Or should we remain on Java 10 for the time being?
>> > 
>> > -- 
>> > Thanks,
>> > Tom Golden
>> > Technical Architect
>> > AndPlus, LLC
>> > 257 Turnpike Road
>> > Southborough, MA 01772
>> > 
>> > Phone 508-425-7533
>> > http://www.andplus.com
> 
> 
> -- 
> Thanks With Regards,
> Kamlesh Prajapati

Re: "javapackager" in no-mans-land?

[Kamlesh Prajapati]

Hi,

Currently , I used javafx 8 with JNLP Application.

Is JNLP application support in javafx11 + java11 ?

Any idea about auto update application in win(exe),mac,linux base
application ?





On Wed, Sep 19, 2018 at 11:54 AM Lennart Börjeson 
wrote:

> It was migrated, but removed...
>
> The recommended work-around is to use the javapackager in OracleJDK 10
> when packing Java/OpenJfx 11 applications.
>
> That may or may not be practical depending on your build setup. Also, if
> you’re currently using the UserJvmOptions services, these are also gone in
> Java/OpenJfx 11, and it would complicate the build process even further if
> you were required to separate the parts needing to compile with OracleJDK
> 10, too.
>
> I’m using Gradle to build my project, and it is currently dependent on the
> javafx-Gradle-plugin to package. To upgrade to Java/OpenJfx 11, and still
> keep the javapackager, I would need to refactor:
>
> 1) my code base, to separate the parts needed to compile with OracleJDK 10
> to get the UserJvmOptions,
> 2) my Gradle structure, to run in three steps (compile some parts with 10,
> compile most parts with 11, package all with 10 while still linking most
> from 11).
>
> It’s too much for me. I’ve decided to remain at Java 10 and wait until
> there’s a javapackager replacement. The javafx-Gradle-plugin has also been
> deprecated due to the loss of the javapackager, so I’m stuck anyway with
> Java 10 unless I rework my entire build structure substantially. I’m hoping
> for a future Gradle plugin replacement.
>
> Seriously, it would be much easier to build my own JDK with OpenJfx, the
> javapackager and UserJvmOptions Service still bundled with it, but then I’d
> step up to a completely different level of support commitment...
>
> /Lennart Börjeson
> Epistula electronica a meo computatro tabulari missa est
>
> > 18 sep. 2018 kl. 22:37 skrev Tom Golden :
> >
> > I understand that along with JavaFX being removed from the Oracle JDK
> > distribution in Java 11, the Oracle team will no longer release the
> > `javapackager` tool.
> >
> > I also see there is a JEP discussing an eventual replacement, JEP-343 (
> > http://openjdk.java.net/jeps/343).
> >
> > Just to confirm, the tool was NOT migrated to OpenJFX with the rest of
> the
> > JavaFX code, correct? So until JEP-343 is implemented in a future release
> > (?) there is no "official" way to package native installers for JavaFX
> > applications?
> >
> > If so, is it in theory still possible to use the Oracle javapackager tool
> > from earlier releases? Or should we remain on Java 10 for the time being?
> >
> > --
> > Thanks,
> > Tom Golden
> > Technical Architect
> > AndPlus, LLC
> > 257 Turnpike Road
> > Southborough, MA 01772
> >
> > Phone 508-425-7533
> > http://www.andplus.com
>


-- 
Thanks With Regards,
Kamlesh Prajapati

Re: "javapackager" in no-mans-land?

[Lennart Börjeson]

It was migrated, but removed...

The recommended work-around is to use the javapackager in OracleJDK 10 when 
packing Java/OpenJfx 11 applications.

That may or may not be practical depending on your build setup. Also, if you’re 
currently using the UserJvmOptions services, these are also gone in 
Java/OpenJfx 11, and it would complicate the build process even further if you 
were required to separate the parts needing to compile with OracleJDK 10, too.

I’m using Gradle to build my project, and it is currently dependent on the 
javafx-Gradle-plugin to package. To upgrade to Java/OpenJfx 11, and still keep 
the javapackager, I would need to refactor:

1) my code base, to separate the parts needed to compile with OracleJDK 10 to 
get the UserJvmOptions,
2) my Gradle structure, to run in three steps (compile some parts with 10, 
compile most parts with 11, package all with 10 while still linking most from 
11).

It’s too much for me. I’ve decided to remain at Java 10 and wait until there’s 
a javapackager replacement. The javafx-Gradle-plugin has also been deprecated 
due to the loss of the javapackager, so I’m stuck anyway with Java 10 unless I 
rework my entire build structure substantially. I’m hoping for a future Gradle 
plugin replacement.

Seriously, it would be much easier to build my own JDK with OpenJfx, the 
javapackager and UserJvmOptions Service still bundled with it, but then I’d 
step up to a completely different level of support commitment...

/Lennart Börjeson
Epistula electronica a meo computatro tabulari missa est

> 18 sep. 2018 kl. 22:37 skrev Tom Golden :
> 
> I understand that along with JavaFX being removed from the Oracle JDK
> distribution in Java 11, the Oracle team will no longer release the
> `javapackager` tool.
> 
> I also see there is a JEP discussing an eventual replacement, JEP-343 (
> http://openjdk.java.net/jeps/343).
> 
> Just to confirm, the tool was NOT migrated to OpenJFX with the rest of the
> JavaFX code, correct? So until JEP-343 is implemented in a future release
> (?) there is no "official" way to package native installers for JavaFX
> applications?
> 
> If so, is it in theory still possible to use the Oracle javapackager tool
> from earlier releases? Or should we remain on Java 10 for the time being?
> 
> -- 
> Thanks,
> Tom Golden
> Technical Architect
> AndPlus, LLC
> 257 Turnpike Road
> Southborough, MA 01772
> 
> Phone 508-425-7533
> http://www.andplus.com

Re: javapackager usage

[Kevin Rushforth]

The javapackager tool, which was delivered as part of the Oracle JDK 
releases along with JavaFX in JDK 8 through JDK 10, has been removed 
from the JDK as of JDK 11. A JEP for a new packaging tool, jpackager, is 
being proposed and discussed on core-libs-dev [1].


-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html



On 6/26/2018 6:43 AM, Buchberger, Joerg wrote:

If this is the wrong mailing list for javapackager questions, I'd appreciate 
any hints regarding where to ask instead in case you happen to know.
Thank you.


-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Buchberger, Joerg
Sent: Freitag, 22. Juni 2018 13:30
To: openjfx-dev@openjdk.java.net
Subject: javapackager usage

Hi everyone

Is this the right mailing list for all questions about javapackager?

I tried to use javapackager for my spring-boot web application on Windows. So, 
naturally, it runs headless.
Although, creating native image and running that exe was successful, there are 
some caveats I could not solve yet:

* how to prevent second such process from starting
* is that what -singleton flag is for? it gets rejected as unsupported 
option

* running it as a service
* is that what -daemon flag or WinServiceBundler is for? no idea how either 
works
* and I failed to get such exe to work with sc and nssm - each fails to 
start for different reason

* as the exe produced with javapackager immediately returns, I don't get how to 
stop my process
* only way to stop seems sending the kill to the task - is there a better 
way?

Thanks for your attention.
Cheers
Jörg


p.s. here the command and options I used with Java 9 JDK:

javapackager -deploy -nosign -native image -daemon -allpermissions -v -outdir 
build/dist -outfile vron -name vron -appclass 
org.springframework.boot.loader.JarLauncher -v -srcdir .\build\libs

RE: javapackager usage

[Buchberger, Joerg]

If this is the wrong mailing list for javapackager questions, I'd appreciate 
any hints regarding where to ask instead in case you happen to know.
Thank you.


-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Buchberger, Joerg
Sent: Freitag, 22. Juni 2018 13:30
To: openjfx-dev@openjdk.java.net
Subject: javapackager usage

Hi everyone

Is this the right mailing list for all questions about javapackager?

I tried to use javapackager for my spring-boot web application on Windows. So, 
naturally, it runs headless.
Although, creating native image and running that exe was successful, there are 
some caveats I could not solve yet:

* how to prevent second such process from starting
   * is that what -singleton flag is for? it gets rejected as unsupported option

* running it as a service
   * is that what -daemon flag or WinServiceBundler is for? no idea how either 
works
   * and I failed to get such exe to work with sc and nssm - each fails to 
start for different reason

* as the exe produced with javapackager immediately returns, I don't get how to 
stop my process
   * only way to stop seems sending the kill to the task - is there a better 
way?

Thanks for your attention.
Cheers
Jörg


p.s. here the command and options I used with Java 9 JDK:

javapackager -deploy -nosign -native image -daemon -allpermissions -v -outdir 
build/dist -outfile vron -name vron -appclass 
org.springframework.boot.loader.JarLauncher -v -srcdir .\build\libs

Re: javapackager: MacOSX: question about adding a file to the DMG outside of the app bundler

[Michael Paus]

I have not tried it myself but this post
http://crazyedy.com/tech/?p=535
claims that it is possible to add something like a readme after the DMG
file has been created by making it writable.

Am 06.12.17 um 16:58 schrieb Mani Sarkar:

Hi,

Has anyone worked out how to add a file like a README.txt into the DMG
volume such that its not bundled into the app bundler (.app file) but
placed outside it so that it is visible when the DMG volume is mounted for
installation?

It sounds like a simple action but the usage or docs don't point to it
directly - from the options so far, it seems it might not be possible. How
else can we present this to the end-user?

Any thoughts on this?

Thanks.

Cheers,
Mani

Re: javapackager feedback and questions

[Mani Sarkar]

Hi Victor,

I have raised an issue on JBS via http://bugreport.java.com/ for this (ID
given to me *9051766*):
> Looks like there is a bug when you specify systemWide=true on the MacOSX
in non-gui mode.

I don't have an account on it, so I might not be able to amend or add new
details to it. If I had to add a word or two to the subject or title of the
issue, how do I do it?

The other doc issues I'll raise as a combined documentation issue, id
*9051768*.

Let me know if you have any other questions or need anything else from me.

Thanks.

Cheers,
Mani
On Wed, 29 Nov 2017 at 23:18  wrote:

> Hi, Mani.
>
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as
> you proposed(there is an arg named jvmOptions but that's not mentioned
> in the table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX
> in non-gui mode. Can you provide more details about that (like full cmd
> line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements
> for deploy/packager, as it's not always clear what users expect.
>
> By the way, what kind of apps you distribute using javapackager? Is that
> a UI app or services?
>
> --Victor
>
>
> --

@theNeomatrix369   |  Blog
  |  @adoptopenjdk | Dev communities

Meet-a-Project - MutabilityDetector 
 |  Github   | Slideshare
  | LinkedIn


Come to Devoxx UK 2018: http://www.devoxx.co.uk/

Don't chase success, rather aim for "Excellence", and success will come
chasing after you!

Re: javapackager feedback and questions

[Sverre Moe]

We are using the javapackager through the gradle/maven javafx plugin, to create:
* Executable JAR: When we went from Swing to JavaFX the maven jar
plugin could not create an executable JAR capable to start the JavaFX
Application.
* Native executable bundle: RPM (Linux), EXE (Windows), PKG (Mac)
* Java Web Start bundle

/Sverre

> Date: Thu, 30 Nov 2017 16:16:19 -0800
> From: Kevin Rushforth <kevin.rushfo...@oracle.com>
> To: Michael Hall <mik3h...@gmail.com>
> Cc: "jdk9-...@openjdk.java.net" <jdk9-...@openjdk.java.net>,
> "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net>, Mani
>     Sarkar <sadhak...@gmail.com>
> Subject: Re: javapackager feedback and questions
> Message-ID: <5a209f53.6080...@oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Michael,
>
> We realized that the javapackger CLI JEP wasn't quite ready, and was out
> of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP
> later.
>
> Related to this, we are soliciting input as to how people are using the
> javapackager (see Victor's question below).
>
> So we'd love to hear how you and others are using it, and for what kind
> of applications.
>
> -- Kevin
>
>
> Michael Hall wrote:
> >> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
> >>
> >> Hi, Mani.
> >>
> >> Thanks for providing the feedback!
> >> We will consider adding more examples and more details in the docs as you 
> >> proposed(there is an arg named jvmOptions but that's not mentioned in the 
> >> table).
> >> Looks like there is a bug when you specify systemWide=true on the MacOSX 
> >> in non-gui mode. Can you provide more details about that (like full cmd 
> >> line)?
> >> Actually, if you want you can clone the repo:
> >> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> >> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> >> and help to improve javapackager. Or you can just create Enhancements for 
> >> deploy/packager, as it's not always clear what users expect.
> >>
> >>
> >
> > Why was JEP 311 [1] Closed/Withdrawn?
> >
> > [1] http://openjdk.java.net/jeps/311
> >
> >

Re: javapackager feedback and questions

[Scott Palmer]

I’m using javapackager to generate native installers for several services and 
GUI applications. I would be using it for some command line tools as well, but 
it doesn’t yet support “console” applications on Windows. I.e. you can’t make 
javapackager with javapackager. I’ve filed an issue for that already (it was 
closed as won’t fix, but thankfully it was reopened)

Javapackager is one of the most useful tools in the JDK, but it is mostly 
undocumented and has many usability issues.
IMO, it tried to do way too much. The only thing it ever needed to do was the 
-deploy option.

I run javapackager two ways, always from Gradle scripts, either via the javaFX 
Gradle plugin, or as an Exec task.

The ability to have secondary launchers is great.

The customization options for installers needs some work. I’ve filed several 
issues (and I could file more). E.g. background images for macOS .dmg must be 
different from background images used in macOS .pkg as they are serving 
entirely different purposes. Including custom resources in subdirectories is 
difficult and/or broken depending on the version of javapackager used (v9 is 
broken).
On Windows .msi component rules are not followed making upgrades problematic. 
Install folders should be customizable by supplying custom wix files, etc.

On Linux services should be handled with systemd or sysctl. (I can’t remember 
which is preferred at the moment, but I know it didn’t use what I needed.)

I really like that we have javapackager and feel it is a very important 
addition to the JDK.  

I too would love if it could build for multiple platforms from a single 
platform, but I honestly don’t see that happening. It isn’t worth the trouble 
or effort - things like making a HFS+ .dmg for macOS from Windows isn’t 
realistic. We do NOT want some custom non-native installer (Though a .zip of an 
app bundle might work.)  You would also need the native bits of the JRE for 
each platform anyway. It would be possible to have those files available on any 
platform, but the tools to build .deb, .rpm, .dmg, .msi, etc. are just never 
going to be available everywhere.

Scott

> On Nov 30, 2017, at 7:16 PM, Kevin Rushforth  
> wrote:
> 
> Hi Michael,
> 
> We realized that the javapackger CLI JEP wasn't quite ready, and was out of 
> scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later.
> 
> Related to this, we are soliciting input as to how people are using the 
> javapackager (see Victor's question below).
> 
> So we'd love to hear how you and others are using it, and for what kind of 
> applications.
> 
> -- Kevin
> 
> 
> Michael Hall wrote:
>>> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
>>> 
>>> Hi, Mani.
>>> 
>>> Thanks for providing the feedback!
>>> We will consider adding more examples and more details in the docs as you 
>>> proposed(there is an arg named jvmOptions but that's not mentioned in the 
>>> table).
>>> Looks like there is a bug when you specify systemWide=true on the MacOSX in 
>>> non-gui mode. Can you provide more details about that (like full cmd line)?
>>> Actually, if you want you can clone the repo:
>>> http://hg.openjdk.java.net/openjfx/10-dev/rt/
>>> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
>>> and help to improve javapackager. Or you can just create Enhancements for 
>>> deploy/packager, as it's not always clear what users expect.
>>> 
>>>
>> 
>> Why was JEP 311 [1] Closed/Withdrawn?
>> 
>> [1] http://openjdk.java.net/jeps/311
>> 
>>  

Re: javapackager feedback and questions

[Mani Sarkar]

Hi Victor,

To answer your query about how javapackager can be made better, packr (
https://github.com/libgdx/packr) and FPM (
https://github.com/jordansissel/fpm) are two great examples in this space.
If we can pool together some of the features from both, it would certainly
draw attention of  developers building installers and distributable
packages. javapackager does already have many of them already. Packr does
allow compressing jre packed into the app although jlink already helps in
this area. Another example would be to be able to --dry-run your
executions, bundle respective apps as a service (systemd, etc...), see
usage of FPM at https://github.com/jordansissel/fpm/wiki#usage.

Your queries about how people use it or like to use it, one thing FPM and
packr do very well, is to allow creation of packages/installer on a single
platform, their cross-platform functionality is a boon, although building
on native environments have their own merits. Just now one would need to
run javapackager in the specific environments to get a working
installer/package created for that environment. Many would like to run
Jenkins (Linux env) and build all three types of packages/installers on one
box rather than spin off the individual slave variants of different
platforms (Linux, MacOSX and Windows.

I can help draw some enhancement points off this list and share it with you
to avoid noise here, and you can choose to bring them to this list - the
ones you would make part of the packager.

Others might differ in the above and want something else.

I hope this helps.

Cheers,
Mani

On Thu, 30 Nov 2017 at 18:57 Martijn Verburg 
wrote:

> Hi Victor,
>
> I can answer the last Q.  It's for two products, one is Censum our GC Log
> analyser (Java swing desktop app, yes they still exist! ;p) and the second
> is a stand alone Java 'daemon' for our APM SaaS tool (illuminate).
>
> jlink and javapackager is a powerful combination for us, so thanks for
> these tools!
>
> Cheers,
> Martijn
>
> On 29 November 2017 at 23:18,  wrote:
>
>> Hi, Mani.
>>
>> Thanks for providing the feedback!
>> We will consider adding more examples and more details in the docs as you
>> proposed(there is an arg named jvmOptions but that's not mentioned in the
>> table).
>> Looks like there is a bug when you specify systemWide=true on the MacOSX
>> in non-gui mode. Can you provide more details about that (like full cmd
>> line)?
>> Actually, if you want you can clone the repo:
>> http://hg.openjdk.java.net/openjfx/10-dev/rt/
>> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
>> and help to improve javapackager. Or you can just create Enhancements for
>> deploy/packager, as it's not always clear what users expect.
>>
>> By the way, what kind of apps you distribute using javapackager? Is that
>> a UI app or services?
>>
>> --Victor
>>
>>
>>
>> On 11/29/17 3:48 AM, Mani Sarkar wrote:
>>
>>> Hi all,
>>>
>>> First I hope I'm writing to the correct mailing list, if not please
>>> suggest
>>> where to write instead. Also if it is worth writing back as separate
>>> messages per issue or item, please do let me know.
>>>
>>> Some of my observations and feedback when using *javapackager*:
>>>
>>> *Positives*
>>> - .dmg and .msi packaging work very well out of the box, easy to put
>>> together configuration settings
>>> - .rpm packages build very quickly
>>> - a number of features from FPM (docs
>>>  | GitHub
>>> ) available but some more for the
>>> individual types of packages would certainly help (for e.g. exposing some
>>> more of the CLI flags for DEB and RPM packaging)
>>>
>>> *Improvements*
>>> - [doc and example required]: Additional documentation and examples
>>> around
>>> how to add a license when building a package would be helpful. After a
>>> bit
>>> of searching on google and experimenting with couple of combinations of
>>> CLI
>>> options I was able to figure it out.
>>> - [doc correction]: jvmUserArg is referred to in the documentation with
>>> examples, while in the usage documentation jvmOptions is used
>>> (discrepancy
>>> between the names of flags), see
>>>
>>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
>>>   and
>>>
>>> https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585
>>> - [doc correction]: same goes for mac.signing-key-user-name while there
>>> is
>>> no mention of it in the javapackager usage documentation, it takes the
>>> full
>>> name of the user i.e. *Jane Doe*
>>> *- *[doc and example required]: just adding
>>> mac.signing-key-developer-id-app=x isn't enough, needs the other
>>> code-sign related flags as well, possibly key should be in the Mac
>>> KeyStore
>>> when building it (check if id provided is the correct one, additional
>>> examples would definitely help to reduce or eliminate experimentation and
>>> assumptions)
>>> 

Re: javapackager feedback and questions

[Michael Hall]

> On Nov 30, 2017, at 6:16 PM, Kevin Rushforth  
> wrote:
> 
> Hi Michael,
> 
> We realized that the javapackger CLI JEP wasn't quite ready, and was out of 
> scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later.
> 
> Related to this, we are soliciting input as to how people are using the 
> javapackager (see Victor's question below).
> 
> So we'd love to hear how you and others are using it, and for what kind of 
> applications.
> 
> — Kevin

I was sort of waiting to see what came out of the JEP. 
It had some issues on OS X the last time I tried it. I might have used it for a 
starter application that I’ve been manually updating since. 
Now I use jlink, copy in the results… That sort of thing. 
I may look at it some more as-is if it doesn’t have a significant update 
currently in the works.

Thanks.

Re: javapackager feedback and questions

[Kevin Rushforth]

Hi Michael,

We realized that the javapackger CLI JEP wasn't quite ready, and was out 
of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP 
later.


Related to this, we are soliciting input as to how people are using the 
javapackager (see Victor's question below).


So we'd love to hear how you and others are using it, and for what kind 
of applications.


-- Kevin


Michael Hall wrote:

On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:

Hi, Mani.

Thanks for providing the feedback!
We will consider adding more examples and more details in the docs as you 
proposed(there is an arg named jvmOptions but that's not mentioned in the 
table).
Looks like there is a bug when you specify systemWide=true on the MacOSX in 
non-gui mode. Can you provide more details about that (like full cmd line)?
Actually, if you want you can clone the repo:
http://hg.openjdk.java.net/openjfx/10-dev/rt/
(hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
and help to improve javapackager. Or you can just create Enhancements for 
deploy/packager, as it's not always clear what users expect.




Why was JEP 311 [1] Closed/Withdrawn?

[1] http://openjdk.java.net/jeps/311

  

Re: javapackager feedback and questions

[Martijn Verburg]

Hi Victor,

I can answer the last Q.  It's for two products, one is Censum our GC Log
analyser (Java swing desktop app, yes they still exist! ;p) and the second
is a stand alone Java 'daemon' for our APM SaaS tool (illuminate).

jlink and javapackager is a powerful combination for us, so thanks for
these tools!

Cheers,
Martijn

On 29 November 2017 at 23:18,  wrote:

> Hi, Mani.
>
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as you
> proposed(there is an arg named jvmOptions but that's not mentioned in the
> table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX
> in non-gui mode. Can you provide more details about that (like full cmd
> line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements for
> deploy/packager, as it's not always clear what users expect.
>
> By the way, what kind of apps you distribute using javapackager? Is that a
> UI app or services?
>
> --Victor
>
>
>
> On 11/29/17 3:48 AM, Mani Sarkar wrote:
>
>> Hi all,
>>
>> First I hope I'm writing to the correct mailing list, if not please
>> suggest
>> where to write instead. Also if it is worth writing back as separate
>> messages per issue or item, please do let me know.
>>
>> Some of my observations and feedback when using *javapackager*:
>>
>> *Positives*
>> - .dmg and .msi packaging work very well out of the box, easy to put
>> together configuration settings
>> - .rpm packages build very quickly
>> - a number of features from FPM (docs
>>  | GitHub
>> ) available but some more for the
>> individual types of packages would certainly help (for e.g. exposing some
>> more of the CLI flags for DEB and RPM packaging)
>>
>> *Improvements*
>> - [doc and example required]: Additional documentation and examples around
>> how to add a license when building a package would be helpful. After a bit
>> of searching on google and experimenting with couple of combinations of
>> CLI
>> options I was able to figure it out.
>> - [doc correction]: jvmUserArg is referred to in the documentation with
>> examples, while in the usage documentation jvmOptions is used (discrepancy
>> between the names of flags), see
>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/
>> javapackager.html
>>   and
>> https://docs.oracle.com/javase/9/deploy/self-contained-
>> application-packaging.htm#JSDPG585
>> - [doc correction]: same goes for mac.signing-key-user-name while there is
>> no mention of it in the javapackager usage documentation, it takes the
>> full
>> name of the user i.e. *Jane Doe*
>> *- *[doc and example required]: just adding
>> mac.signing-key-developer-id-app=x isn't enough, needs the other
>> code-sign related flags as well, possibly key should be in the Mac
>> KeyStore
>> when building it (check if id provided is the correct one, additional
>> examples would definitely help to reduce or eliminate experimentation and
>> assumptions)
>> - [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
>> building on the MacOSX in non-gui mode, can be overridden by using the
>> -Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
>> creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
>> systemWide=true does not help, still ends up building a .dmg package with
>> just the app in it (no icon, no background)
>> - code signing examples for Windows and MacOSX will certainly help quite a
>> bit
>> - [doc and example required] .deb packages take a long time to build, some
>> additional flags that can help. Some findings along the lines on how to
>> speed up dpkg-build:
>>
>> export CCACHE_DIR=/home/$USER/.ccache
>>
>> export CCACHE_HASHDIR=$CCACHE_DIR
>>
>> export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS}
>> --preserve-envvar=CCACHE_DIR
>> --prepend-path=/usr/lib/ccache parallel=jobs"
>>
>> echo "Debian build options: ${DEB_BUILD_OPTIONS}"
>>
>> ---
>>
>> A response with answers for the above will be highly appreciated.
>>
>> Thanks.
>>
>> Cheers,
>> Mani
>>
>
>

Re: javapackager feedback and questions

[Mani Sarkar]

Thanks Victor for you response and invite. I'll get back with details for
your query.

Just for your info, I was referring to javapackager in the context of Java
9 built artifacts.

On Thu, 30 Nov 2017 09:28 Michael Hall,  wrote:

>
> > On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
> >
> > Hi, Mani.
> >
> > Thanks for providing the feedback!
> > We will consider adding more examples and more details in the docs as
> you proposed(there is an arg named jvmOptions but that's not mentioned in
> the table).
> > Looks like there is a bug when you specify systemWide=true on the MacOSX
> in non-gui mode. Can you provide more details about that (like full cmd
> line)?
> > Actually, if you want you can clone the repo:
> > http://hg.openjdk.java.net/openjfx/10-dev/rt/
> > (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> > and help to improve javapackager. Or you can just create Enhancements
> for deploy/packager, as it's not always clear what users expect.
> >
>
> Why was JEP 311 [1] Closed/Withdrawn?
>
> [1] http://openjdk.java.net/jeps/311
>
> --

@theNeomatrix369   |  Blog
  |  @adoptopenjdk | Dev communities

Meet-a-Project - MutabilityDetector 
 |  Github   | Slideshare
  | LinkedIn


Come to Devoxx UK 2018: http://www.devoxx.co.uk/

Don't chase success, rather aim for "Excellence", and success will come
chasing after you!

Re: javapackager feedback and questions

[Michael Hall]

> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
> 
> Hi, Mani.
> 
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as you 
> proposed(there is an arg named jvmOptions but that's not mentioned in the 
> table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX in 
> non-gui mode. Can you provide more details about that (like full cmd line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements for 
> deploy/packager, as it's not always clear what users expect.
> 

Why was JEP 311 [1] Closed/Withdrawn?

[1] http://openjdk.java.net/jeps/311

Re: javapackager feedback and questions

[Michael Paus]

Hi,
I am wondering why you can say that ".dmg and .msi packaging work very well"
because there is this still open bug 
https://bugs.openjdk.java.net/browse/JDK-8179033
which keeps me from building DMG files on Java 9. Are you still using 
Java 8?

Michael

Am 29.11.17 um 12:48 schrieb Mani Sarkar:

Hi all,

First I hope I'm writing to the correct mailing list, if not please suggest
where to write instead. Also if it is worth writing back as separate
messages per issue or item, please do let me know.

Some of my observations and feedback when using *javapackager*:

*Positives*
- .dmg and .msi packaging work very well out of the box, easy to put
together configuration settings
- .rpm packages build very quickly
- a number of features from FPM (docs
 | GitHub
) available but some more for the
individual types of packages would certainly help (for e.g. exposing some
more of the CLI flags for DEB and RPM packaging)

*Improvements*
- [doc and example required]: Additional documentation and examples around
how to add a license when building a package would be helpful. After a bit
of searching on google and experimenting with couple of combinations of CLI
options I was able to figure it out.
- [doc correction]: jvmUserArg is referred to in the documentation with
examples, while in the usage documentation jvmOptions is used (discrepancy
between the names of flags), see
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
  and
https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585
- [doc correction]: same goes for mac.signing-key-user-name while there is
no mention of it in the javapackager usage documentation, it takes the full
name of the user i.e. *Jane Doe*
*- *[doc and example required]: just adding
mac.signing-key-developer-id-app=x isn't enough, needs the other
code-sign related flags as well, possibly key should be in the Mac KeyStore
when building it (check if id provided is the correct one, additional
examples would definitely help to reduce or eliminate experimentation and
assumptions)
- [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
building on the MacOSX in non-gui mode, can be overridden by using the
-Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
systemWide=true does not help, still ends up building a .dmg package with
just the app in it (no icon, no background)
- code signing examples for Windows and MacOSX will certainly help quite a
bit
- [doc and example required] .deb packages take a long time to build, some
additional flags that can help. Some findings along the lines on how to
speed up dpkg-build:

export CCACHE_DIR=/home/$USER/.ccache

export CCACHE_HASHDIR=$CCACHE_DIR

export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS} --preserve-envvar=CCACHE_DIR
--prepend-path=/usr/lib/ccache parallel=jobs"

echo "Debian build options: ${DEB_BUILD_OPTIONS}"

---

A response with answers for the above will be highly appreciated.

Thanks.

Cheers,
Mani

Re: javapackager feedback and questions

[victor . drozdov]

Hi, Mani.

Thanks for providing the feedback!
We will consider adding more examples and more details in the docs as 
you proposed(there is an arg named jvmOptions but that's not mentioned 
in the table).
Looks like there is a bug when you specify systemWide=true on the MacOSX 
in non-gui mode. Can you provide more details about that (like full cmd 
line)?

Actually, if you want you can clone the repo:
http://hg.openjdk.java.net/openjfx/10-dev/rt/
(hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
and help to improve javapackager. Or you can just create Enhancements 
for deploy/packager, as it's not always clear what users expect.


By the way, what kind of apps you distribute using javapackager? Is that 
a UI app or services?


--Victor


On 11/29/17 3:48 AM, Mani Sarkar wrote:

Hi all,

First I hope I'm writing to the correct mailing list, if not please suggest
where to write instead. Also if it is worth writing back as separate
messages per issue or item, please do let me know.

Some of my observations and feedback when using *javapackager*:

*Positives*
- .dmg and .msi packaging work very well out of the box, easy to put
together configuration settings
- .rpm packages build very quickly
- a number of features from FPM (docs
 | GitHub
) available but some more for the
individual types of packages would certainly help (for e.g. exposing some
more of the CLI flags for DEB and RPM packaging)

*Improvements*
- [doc and example required]: Additional documentation and examples around
how to add a license when building a package would be helpful. After a bit
of searching on google and experimenting with couple of combinations of CLI
options I was able to figure it out.
- [doc correction]: jvmUserArg is referred to in the documentation with
examples, while in the usage documentation jvmOptions is used (discrepancy
between the names of flags), see
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
  and
https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585
- [doc correction]: same goes for mac.signing-key-user-name while there is
no mention of it in the javapackager usage documentation, it takes the full
name of the user i.e. *Jane Doe*
*- *[doc and example required]: just adding
mac.signing-key-developer-id-app=x isn't enough, needs the other
code-sign related flags as well, possibly key should be in the Mac KeyStore
when building it (check if id provided is the correct one, additional
examples would definitely help to reduce or eliminate experimentation and
assumptions)
- [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
building on the MacOSX in non-gui mode, can be overridden by using the
-Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
systemWide=true does not help, still ends up building a .dmg package with
just the app in it (no icon, no background)
- code signing examples for Windows and MacOSX will certainly help quite a
bit
- [doc and example required] .deb packages take a long time to build, some
additional flags that can help. Some findings along the lines on how to
speed up dpkg-build:

export CCACHE_DIR=/home/$USER/.ccache

export CCACHE_HASHDIR=$CCACHE_DIR

export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS} --preserve-envvar=CCACHE_DIR
--prepend-path=/usr/lib/ccache parallel=jobs"

echo "Debian build options: ${DEB_BUILD_OPTIONS}"

---

A response with answers for the above will be highly appreciated.

Thanks.

Cheers,
Mani

Re: javapackager - partially self-contained apps in JDK 9

[Chris Bensen]

The code that I included below will do what you want with modular JARs. I hope 
to get this as a feature of the Java Packager which would be called Pugins, but 
there’s only so much time, which is why I provided you with a portion of my 
prototype code.

Chris


> On Apr 25, 2017, at 12:11 PM, Alan Snyder  wrote:
> 
> The whole point is not to include the connector JAR in the bundled app, so 
> that it can upgraded independently.
> 
> I tried setting -classpath using fx:jvmuserarg, the app crashed (exit 1) on 
> startup.
> 
> I really wonder why this case is not handled in some convenient way.
> 
> 
> 
> 
>> On Apr 25, 2017, at 11:32 AM, Chris Bensen  wrote:
>> 
>> 
>>> On Apr 11, 2017, at 10:43 AM, Alan Snyder  wrote:
>>> 
>>> I have run into a problem in moving my macOS apps from JDK 8 to 9. The 
>>> issue relates to using MySQL via JDBC.
>>> The connector class name is fixed. The class is loaded using 
>>> Class.forName(). However, there can be different versions
>>> of the connector in different JAR files, and the proper version might need 
>>> to be synced with the currently installed version
>>> of MySQL.
>>> 
>>> In JDK 8, I used the extension mechanism to load the MySQL connector JAR 
>>> rather than building this JAR into the bundled app.
>>> My thinking was that the connector might need to be updated in sync with 
>>> the database and I should not have to rebuild apps to do that.
>>> 
>>> In JDK 9, the extension mechanism is gone. I have not found any way to 
>>> achieve the equivalent effect. It seems that javapackager
>>> controls the setting of the CLASSPATH. I have not found an option that 
>>> would allow me to extend the CLASSPATH with a directory
>>> where the connector JAR could be found. Is there a way to do this?
>>> 
>>> Alan
>>> 
>> 
>> 
>> Are you including the connector JAR in the app image?
>> 
>> I think you could set the classpath if you us ant-javafx.jar:
>> 
>> 
>> 
>> but honestly I’ve never tried it with JDK 9.
>> 
>> A JDK 9 way of dynamically loading this would be to create a Layer. Here’s 
>> some semi working code you could use:
>> 
>> 
>>   public Plugin loadPlugin(String module, String classname) {
>>   Plugin result = null;
>>   Configuration cf = 
>> resolve(file.getAbsoluteFile().getParentFile().toPath(), name);
>>   ClassLoader scl = ClassLoader.getSystemClassLoader();
>>   Layer layer = Layer.boot().defineModulesWithOneLoader(cf, scl);
>>   ClassLoader cl = layer.findLoader(name);
>> 
>>   try {
>>   result = createPlugin(layer, name, classname);
>>   result.load();
>>   plugins.add(result);
>>   }
>>   catch (Exception e) {
>>   System.out.println("oh no!" + e.toString());
>>   }
>> 
>>   return result;
>>   }
>> 
>>   private static Configuration resolve(Path modulepath, String... roots) {
>>   ModuleFinder finder = ModuleFinder.of(modulepath);
>>   return Layer.boot()
>>   .configuration()
>>   .resolve(finder, ModuleFinder.of(), Set.of(roots));
>>   }
>> 
>>   private static Plugin createPlugin(Layer layer, String mn, String mc) 
>> throws Exception {
>>   ClassLoader loader = layer.findLoader(mn);
>>   Class c = loader.loadClass(mc);
>>   Plugin p = (Plugin)c.getConstructor().newInstance();
>>   return p;
>>   }
>> 
>> Chris
> 

Re: javapackager - partially self-contained apps in JDK 9

[Chris Bensen]

> On Apr 11, 2017, at 10:43 AM, Alan Snyder  wrote:
> 
> I have run into a problem in moving my macOS apps from JDK 8 to 9. The issue 
> relates to using MySQL via JDBC.
> The connector class name is fixed. The class is loaded using Class.forName(). 
> However, there can be different versions
> of the connector in different JAR files, and the proper version might need to 
> be synced with the currently installed version
> of MySQL.
> 
> In JDK 8, I used the extension mechanism to load the MySQL connector JAR 
> rather than building this JAR into the bundled app.
> My thinking was that the connector might need to be updated in sync with the 
> database and I should not have to rebuild apps to do that.
> 
> In JDK 9, the extension mechanism is gone. I have not found any way to 
> achieve the equivalent effect. It seems that javapackager
> controls the setting of the CLASSPATH. I have not found an option that would 
> allow me to extend the CLASSPATH with a directory
> where the connector JAR could be found. Is there a way to do this?
> 
>  Alan
> 


Are you including the connector JAR in the app image?

I think you could set the classpath if you us ant-javafx.jar:



but honestly I’ve never tried it with JDK 9.

A JDK 9 way of dynamically loading this would be to create a Layer. Here’s some 
semi working code you could use:


public Plugin loadPlugin(String module, String classname) {
Plugin result = null;
Configuration cf = 
resolve(file.getAbsoluteFile().getParentFile().toPath(), name);
ClassLoader scl = ClassLoader.getSystemClassLoader();
Layer layer = Layer.boot().defineModulesWithOneLoader(cf, scl);
ClassLoader cl = layer.findLoader(name);

try {
result = createPlugin(layer, name, classname);
result.load();
plugins.add(result);
}
catch (Exception e) {
System.out.println("oh no!" + e.toString());
}

return result;
}

private static Configuration resolve(Path modulepath, String... roots) {
ModuleFinder finder = ModuleFinder.of(modulepath);
return Layer.boot()
.configuration()
.resolve(finder, ModuleFinder.of(), Set.of(roots));
}

private static Plugin createPlugin(Layer layer, String mn, String mc) 
throws Exception {
ClassLoader loader = layer.findLoader(mn);
Class c = loader.loadClass(mc);
Plugin p = (Plugin)c.getConstructor().newInstance();
return p;
}

Chris

Re: javapackager - partially self-contained apps in JDK 9

[Scott Palmer]

> On Apr 11, 2017, at 1:43 PM, Alan Snyder  wrote:
> 
> I have run into a problem in moving my macOS apps from JDK 8 to 9. The issue 
> relates to using MySQL via JDBC.
> The connector class name is fixed. The class is loaded using Class.forName(). 
> However, there can be different versions
> of the connector in different JAR files, and the proper version might need to 
> be synced with the currently installed version
> of MySQL.
> 
> In JDK 8, I used the extension mechanism to load the MySQL connector JAR 
> rather than building this JAR into the bundled app.
> My thinking was that the connector might need to be updated in sync with the 
> database and I should not have to rebuild apps to do that.
> 
> In JDK 9, the extension mechanism is gone. I have not found any way to 
> achieve the equivalent effect. It seems that javapackager
> controls the setting of the CLASSPATH. I have not found an option that would 
> allow me to extend the CLASSPATH with a directory
> where the connector JAR could be found. Is there a way to do this?

My application ran into classpath issues because it tried to dynamically add 
plugins to the classpath and that broke on Java 9.  To work around it I created 
an agent so I could get access to the java.lang.Instrumentation interface to 
add to the classpath.  You might try that approach.  It’s ugly, but better than 
reflectively accessing private fields of URLClassLoader, which doesn’t work for 
Java 9 :-)

Scott

Re: javapackager

[Scott Palmer]

I noticed that the JDK on my Linux VM was 8u40,  I updated to 8u72 and then
got the following:

Bundler RPM Bundle skipped because of a configuration problem: Specified
license file is missing.
Advice to fix: Make sure that "EULA.rtf" references a file in the app
resources, and that it is relative file reference.

I wasn't able to do anything to convince it that the license file was
there. I just omitted it for now.

Updating to 8u72 did not solve my .rpm dependency issues.

Scott

On Wed, Feb 3, 2016 at 4:08 PM, Scott Palmer  wrote:

>
> > On Feb 3, 2016, at 11:40 AM, Chris Bensen 
> wrote:
> >
> > On Feb 2, 2016, at 7:27 PM, Scott Palmer  wrote:
> >>
> >> Note that this is a RPM-based system, apt-get is not available, yum is.
> >>
> >> yum install libX11
> >
> > What is the Linux system you are running?
>
> It is a version of CentOS.  (Created within my company with minor tweaks
> for branding purposes.)
>
>
> >>
> >> It seems to be that javapackager has made a mistake and is claiming to
> depend on the 32-bit packages even though it really requires the 64-bit
> packages.
> >
> > That’s what it’s sounding like to me. Looking at the code for the RPM
> bundler there isn’t anything I can find offhand that would suggest this.
> Bundling with 32/64-bit is triggered off the JDK used. Note that you have
> to bundle the same bitness JRE as the JDK. It should fail if it isn’t but
> that isn’t the case yet and that isn’t your problem. It appears the RPM
> generated is 32-bit. Unless you are bundling a 32-bit JRE and the RPM
> bundler keys off the native libraries used. Can you check the launcher
> executable? I think it’d be:
> >
> > $ file myserver-1.0-1.x86_64/app/myserver
>
> I had to extract the launcher from the .rpm.  There is no version of it
> that is sitting around in the output folder.
>
> myserver: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked (uses shared libs), for GNU/Linux 2.6.15,
> BuildID[sha1]=0x7e6522a86eca91b45cfb4dfa5defbddac0b1294a, not stripped
>
>
> So the 64-bit launcher is bundled.
>
>
> >
> > Can you file a minimum test case along with the Linux system used so we
> can prioritize with other bugs and find a solution?
>
> I’ll try to put something together.  I’m still eager to find a workaround
> that I can implement with 8u72.
>
>
> Scott
>
>
> >
> > Chris
> >
> >
> >> Scott
> >>
> >>
> >>> On Feb 2, 2016, at 7:03 PM, Chris Bensen 
> wrote:
> >>>
> >>> This list or the Deployment blog (
> https://blogs.oracle.com/talkingjavadeployment/) are the best places to
> get help with the javapackager.
> >>>
> >>> Is your app built with the 64-bit or 32-bit packager? I noticed
> “x86_64” appended to the name. If it’s 32-bit you could try running:
> >>>
> >>> sudo apt-get install libx11-6:i386
> >>>
> >>> Chris
> >>>
> >>>
>  On Feb 2, 2016, at 1:49 PM, Scott Palmer  wrote:
> 
>  What's the best place to go to get help with using the javapackager ?
> 
>  I've read the docs, but things aren't working smoothly and it would be
>  helpful if there were some known working examples to base things on.
> I'm
>  not finding any examples that use the -daemon or -BserviceHint=true
>  options, for example.
> 
>  I attempted to make a .rpm that installs a service/daemon but when I
> try to
>  install it, it fails claiming the following dependencies cannot be
> met:
> 
>  libX11.so.6 is needed by myserver-1.0-1.x86_64
>  libXext.so.6 is needed by myserver-1.0-1.x86_64
>  libXi.so.6 is needed by myserver-1.0-1.x86_64
>  libXrender.so.1 is needed by myserver-1.0-1.x86_64
>  libXtst.so.6 is needed by myserver-1.0-1.x86_64
>  libasound.so.2 is needed by myserver-1.0-1.x86_64
> 
>  Considering the app already runs fine on this same system, I'm a bit
>  confused that it is complaining of missing dependencies.
> 
>  Scott
>
>

Re: javapackager

[Chris Bensen]

> On Feb 3, 2016, at 1:08 PM, Scott Palmer  wrote:
> 
> 
>> On Feb 3, 2016, at 11:40 AM, Chris Bensen  wrote:
>> 
>> On Feb 2, 2016, at 7:27 PM, Scott Palmer  wrote:
>>> 
>>> Note that this is a RPM-based system, apt-get is not available, yum is.
>>> 
>>> yum install libX11
>> 
>> What is the Linux system you are running?
> 
> It is a version of CentOS.  (Created within my company with minor tweaks for 
> branding purposes.)

When submitting a bug, make sure the test case works on Oracle Linux or Ubuntu 
since those are the only “supported” version of Linux.

> 
> 
>>> 
>>> It seems to be that javapackager has made a mistake and is claiming to 
>>> depend on the 32-bit packages even though it really requires the 64-bit 
>>> packages.
>> 
>> That’s what it’s sounding like to me. Looking at the code for the RPM 
>> bundler there isn’t anything I can find offhand that would suggest this. 
>> Bundling with 32/64-bit is triggered off the JDK used. Note that you have to 
>> bundle the same bitness JRE as the JDK. It should fail if it isn’t but that 
>> isn’t the case yet and that isn’t your problem. It appears the RPM generated 
>> is 32-bit. Unless you are bundling a 32-bit JRE and the RPM bundler keys off 
>> the native libraries used. Can you check the launcher executable? I think 
>> it’d be:
>> 
>> $ file myserver-1.0-1.x86_64/app/myserver
> 
> I had to extract the launcher from the .rpm.  There is no version of it that 
> is sitting around in the output folder.
> 
> myserver: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
> linked (uses shared libs), for GNU/Linux 2.6.15, 
> BuildID[sha1]=0x7e6522a86eca91b45cfb4dfa5defbddac0b1294a, not stripped
> 
> 
> So the 64-bit launcher is bundled.
> 
> 
>> 
>> Can you file a minimum test case along with the Linux system used so we can 
>> prioritize with other bugs and find a solution?
> 
> I’ll try to put something together.  I’m still eager to find a workaround 
> that I can implement with 8u72.
> 
> 
> Scott
> 
> 
>> 
>> Chris
>> 
>> 
>>> Scott 
>>> 
>>> 
 On Feb 2, 2016, at 7:03 PM, Chris Bensen  wrote:
 
 This list or the Deployment blog 
 (https://blogs.oracle.com/talkingjavadeployment/) are the best places to 
 get help with the javapackager.
 
 Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
 appended to the name. If it’s 32-bit you could try running:
 
 sudo apt-get install libx11-6:i386
 
 Chris
 
 
> On Feb 2, 2016, at 1:49 PM, Scott Palmer  wrote:
> 
> What's the best place to go to get help with using the javapackager ?
> 
> I've read the docs, but things aren't working smoothly and it would be
> helpful if there were some known working examples to base things on.  I'm
> not finding any examples that use the -daemon or -BserviceHint=true
> options, for example.
> 
> I attempted to make a .rpm that installs a service/daemon but when I try 
> to
> install it, it fails claiming the following dependencies cannot be met:
> 
>libX11.so.6 is needed by myserver-1.0-1.x86_64
>libXext.so.6 is needed by myserver-1.0-1.x86_64
>libXi.so.6 is needed by myserver-1.0-1.x86_64
>libXrender.so.1 is needed by myserver-1.0-1.x86_64
>libXtst.so.6 is needed by myserver-1.0-1.x86_64
>libasound.so.2 is needed by myserver-1.0-1.x86_64
> 
> Considering the app already runs fine on this same system, I'm a bit
> confused that it is complaining of missing dependencies.
> 
> Scott
> 

Re: javapackager

[Chris Bensen]

There weren’t any noticeable changes for Linux. Besides maybe this one, which 
if you could file a bug with steps to reproduce that’d be great.

Chris


> On Feb 4, 2016, at 7:12 AM, Scott Palmer  wrote:
> 
> I noticed that the JDK on my Linux VM was 8u40,  I updated to 8u72 and then 
> got the following:
> 
> Bundler RPM Bundle skipped because of a configuration problem: Specified 
> license file is missing.  
> Advice to fix: Make sure that "EULA.rtf" references a file in the app 
> resources, and that it is relative file reference.
> 
> I wasn't able to do anything to convince it that the license file was there. 
> I just omitted it for now.
> 
> Updating to 8u72 did not solve my .rpm dependency issues.
> 
> Scott
> 
> On Wed, Feb 3, 2016 at 4:08 PM, Scott Palmer  > wrote:
> 
> > On Feb 3, 2016, at 11:40 AM, Chris Bensen  > > wrote:
> >
> > On Feb 2, 2016, at 7:27 PM, Scott Palmer  > > wrote:
> >>
> >> Note that this is a RPM-based system, apt-get is not available, yum is.
> >>
> >> yum install libX11
> >
> > What is the Linux system you are running?
> 
> It is a version of CentOS.  (Created within my company with minor tweaks for 
> branding purposes.)
> 
> 
> >>
> >> It seems to be that javapackager has made a mistake and is claiming to 
> >> depend on the 32-bit packages even though it really requires the 64-bit 
> >> packages.
> >
> > That’s what it’s sounding like to me. Looking at the code for the RPM 
> > bundler there isn’t anything I can find offhand that would suggest this. 
> > Bundling with 32/64-bit is triggered off the JDK used. Note that you have 
> > to bundle the same bitness JRE as the JDK. It should fail if it isn’t but 
> > that isn’t the case yet and that isn’t your problem. It appears the RPM 
> > generated is 32-bit. Unless you are bundling a 32-bit JRE and the RPM 
> > bundler keys off the native libraries used. Can you check the launcher 
> > executable? I think it’d be:
> >
> > $ file myserver-1.0-1.x86_64/app/myserver
> 
> I had to extract the launcher from the .rpm.  There is no version of it that 
> is sitting around in the output folder.
> 
> myserver: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
> linked (uses shared libs), for GNU/Linux 2.6.15, 
> BuildID[sha1]=0x7e6522a86eca91b45cfb4dfa5defbddac0b1294a, not stripped
> 
> 
> So the 64-bit launcher is bundled.
> 
> 
> >
> > Can you file a minimum test case along with the Linux system used so we can 
> > prioritize with other bugs and find a solution?
> 
> I’ll try to put something together.  I’m still eager to find a workaround 
> that I can implement with 8u72.
> 
> 
> Scott
> 
> 
> >
> > Chris
> >
> >
> >> Scott
> >>
> >>
> >>> On Feb 2, 2016, at 7:03 PM, Chris Bensen  >>> > wrote:
> >>>
> >>> This list or the Deployment blog 
> >>> (https://blogs.oracle.com/talkingjavadeployment/ 
> >>> ) are the best places to 
> >>> get help with the javapackager.
> >>>
> >>> Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
> >>> appended to the name. If it’s 32-bit you could try running:
> >>>
> >>> sudo apt-get install libx11-6:i386
> >>>
> >>> Chris
> >>>
> >>>
>  On Feb 2, 2016, at 1:49 PM, Scott Palmer   > wrote:
> 
>  What's the best place to go to get help with using the javapackager ?
> 
>  I've read the docs, but things aren't working smoothly and it would be
>  helpful if there were some known working examples to base things on.  I'm
>  not finding any examples that use the -daemon or -BserviceHint=true
>  options, for example.
> 
>  I attempted to make a .rpm that installs a service/daemon but when I try 
>  to
>  install it, it fails claiming the following dependencies cannot be met:
> 
>  libX11.so.6 is needed by myserver-1.0-1.x86_64
>  libXext.so.6 is needed by myserver-1.0-1.x86_64
>  libXi.so.6 is needed by myserver-1.0-1.x86_64
>  libXrender.so.1 is needed by myserver-1.0-1.x86_64
>  libXtst.so.6 is needed by myserver-1.0-1.x86_64
>  libasound.so.2 is needed by myserver-1.0-1.x86_64
> 
>  Considering the app already runs fine on this same system, I'm a bit
>  confused that it is complaining of missing dependencies.
> 
>  Scott
> 
> 

Re: javapackager

[Scott Palmer]

> On Feb 3, 2016, at 11:40 AM, Chris Bensen  wrote:
> 
> On Feb 2, 2016, at 7:27 PM, Scott Palmer  wrote:
>> 
>> Note that this is a RPM-based system, apt-get is not available, yum is.
>> 
>> yum install libX11
> 
> What is the Linux system you are running?

It is a version of CentOS.  (Created within my company with minor tweaks for 
branding purposes.)


>> 
>> It seems to be that javapackager has made a mistake and is claiming to 
>> depend on the 32-bit packages even though it really requires the 64-bit 
>> packages.
> 
> That’s what it’s sounding like to me. Looking at the code for the RPM bundler 
> there isn’t anything I can find offhand that would suggest this. Bundling 
> with 32/64-bit is triggered off the JDK used. Note that you have to bundle 
> the same bitness JRE as the JDK. It should fail if it isn’t but that isn’t 
> the case yet and that isn’t your problem. It appears the RPM generated is 
> 32-bit. Unless you are bundling a 32-bit JRE and the RPM bundler keys off the 
> native libraries used. Can you check the launcher executable? I think it’d be:
> 
> $ file myserver-1.0-1.x86_64/app/myserver

I had to extract the launcher from the .rpm.  There is no version of it that is 
sitting around in the output folder.

myserver: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
linked (uses shared libs), for GNU/Linux 2.6.15, 
BuildID[sha1]=0x7e6522a86eca91b45cfb4dfa5defbddac0b1294a, not stripped


So the 64-bit launcher is bundled.


> 
> Can you file a minimum test case along with the Linux system used so we can 
> prioritize with other bugs and find a solution?

I’ll try to put something together.  I’m still eager to find a workaround that 
I can implement with 8u72.


Scott


> 
> Chris
> 
> 
>> Scott 
>> 
>> 
>>> On Feb 2, 2016, at 7:03 PM, Chris Bensen  wrote:
>>> 
>>> This list or the Deployment blog 
>>> (https://blogs.oracle.com/talkingjavadeployment/) are the best places to 
>>> get help with the javapackager.
>>> 
>>> Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
>>> appended to the name. If it’s 32-bit you could try running:
>>> 
>>> sudo apt-get install libx11-6:i386
>>> 
>>> Chris
>>> 
>>> 
 On Feb 2, 2016, at 1:49 PM, Scott Palmer  wrote:
 
 What's the best place to go to get help with using the javapackager ?
 
 I've read the docs, but things aren't working smoothly and it would be
 helpful if there were some known working examples to base things on.  I'm
 not finding any examples that use the -daemon or -BserviceHint=true
 options, for example.
 
 I attempted to make a .rpm that installs a service/daemon but when I try to
 install it, it fails claiming the following dependencies cannot be met:
 
 libX11.so.6 is needed by myserver-1.0-1.x86_64
 libXext.so.6 is needed by myserver-1.0-1.x86_64
 libXi.so.6 is needed by myserver-1.0-1.x86_64
 libXrender.so.1 is needed by myserver-1.0-1.x86_64
 libXtst.so.6 is needed by myserver-1.0-1.x86_64
 libasound.so.2 is needed by myserver-1.0-1.x86_64
 
 Considering the app already runs fine on this same system, I'm a bit
 confused that it is complaining of missing dependencies.
 
 Scott

Re: javapackager

[Chris Bensen]

On Feb 2, 2016, at 7:27 PM, Scott Palmer  wrote:
> 
> Note that this is a RPM-based system, apt-get is not available, yum is.
> 
> yum install libX11

What is the Linux system you are running?

> …
> Package libX11-1.6.0-2.1.el7.x86_64 already installed and latest version
> 
> I get a similar message for the other dependencies.
> 
> Examining the .rpm file I can see that the bundled runtime contains a 
> lib/amd64 folder, so I’m pretty sure everything it did was 64-bit.
> 
> If I run:
> 
> yum install libX11.so.6
> 
> it wants to install the i686 architecture.  
> 
> So I went ahead an used yum to install the dependencies that way, but it 
> failed on the last one (of course):
> $ sudo yum install libasound.so.2
> Resolving Dependencies
> --> Running transaction check
> ---> Package alsa-lib.i686 0:1.0.28-2.el7 will be installed
> --> Finished Dependency Resolution
> Error:  Multilib version problems found.
> …
>   ...you can also use --setopt=protected_multilib=false to remove
>   this checking, however this is almost never the correct thing to
>   do as something else is very likely to go wrong (often causing
>   much more problems).
> 
>   Protected multilib versions: alsa-lib-1.0.28-2.el7.i686 != 
> alsa-lib-1.0.27.2-3.el7.x86_64
> 
> 
> It seems to be that javapackager has made a mistake and is claiming to depend 
> on the 32-bit packages even though it really requires the 64-bit packages.

That’s what it’s sounding like to me. Looking at the code for the RPM bundler 
there isn’t anything I can find offhand that would suggest this. Bundling with 
32/64-bit is triggered off the JDK used. Note that you have to bundle the same 
bitness JRE as the JDK. It should fail if it isn’t but that isn’t the case yet 
and that isn’t your problem. It appears the RPM generated is 32-bit. Unless you 
are bundling a 32-bit JRE and the RPM bundler keys off the native libraries 
used. Can you check the launcher executable? I think it’d be:

$ file myserver-1.0-1.x86_64/app/myserver

Can you file a minimum test case along with the Linux system used so we can 
prioritize with other bugs and find a solution?

Chris


> Scott 
> 
> 
>> On Feb 2, 2016, at 7:03 PM, Chris Bensen  wrote:
>> 
>> This list or the Deployment blog 
>> (https://blogs.oracle.com/talkingjavadeployment/) are the best places to get 
>> help with the javapackager.
>> 
>> Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
>> appended to the name. If it’s 32-bit you could try running:
>> 
>> sudo apt-get install libx11-6:i386
>> 
>> Chris
>> 
>> 
>>> On Feb 2, 2016, at 1:49 PM, Scott Palmer  wrote:
>>> 
>>> What's the best place to go to get help with using the javapackager ?
>>> 
>>> I've read the docs, but things aren't working smoothly and it would be
>>> helpful if there were some known working examples to base things on.  I'm
>>> not finding any examples that use the -daemon or -BserviceHint=true
>>> options, for example.
>>> 
>>> I attempted to make a .rpm that installs a service/daemon but when I try to
>>> install it, it fails claiming the following dependencies cannot be met:
>>> 
>>>  libX11.so.6 is needed by myserver-1.0-1.x86_64
>>>  libXext.so.6 is needed by myserver-1.0-1.x86_64
>>>  libXi.so.6 is needed by myserver-1.0-1.x86_64
>>>  libXrender.so.1 is needed by myserver-1.0-1.x86_64
>>>  libXtst.so.6 is needed by myserver-1.0-1.x86_64
>>>  libasound.so.2 is needed by myserver-1.0-1.x86_64
>>> 
>>> Considering the app already runs fine on this same system, I'm a bit
>>> confused that it is complaining of missing dependencies.
>>> 
>>> Scott
>> 
> 

Re: javapackager

[Chris Bensen]

This list or the Deployment blog 
(https://blogs.oracle.com/talkingjavadeployment/) are the best places to get 
help with the javapackager.

Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
appended to the name. If it’s 32-bit you could try running:

sudo apt-get install libx11-6:i386

Chris


> On Feb 2, 2016, at 1:49 PM, Scott Palmer  wrote:
> 
> What's the best place to go to get help with using the javapackager ?
> 
> I've read the docs, but things aren't working smoothly and it would be
> helpful if there were some known working examples to base things on.  I'm
> not finding any examples that use the -daemon or -BserviceHint=true
> options, for example.
> 
> I attempted to make a .rpm that installs a service/daemon but when I try to
> install it, it fails claiming the following dependencies cannot be met:
> 
>libX11.so.6 is needed by myserver-1.0-1.x86_64
>libXext.so.6 is needed by myserver-1.0-1.x86_64
>libXi.so.6 is needed by myserver-1.0-1.x86_64
>libXrender.so.1 is needed by myserver-1.0-1.x86_64
>libXtst.so.6 is needed by myserver-1.0-1.x86_64
>libasound.so.2 is needed by myserver-1.0-1.x86_64
> 
> Considering the app already runs fine on this same system, I'm a bit
> confused that it is complaining of missing dependencies.
> 
> Scott

Re: javapackager

[Scott Palmer]

The “-1.x86-64” is something that javapackager automatically appends.

I just confirmed that $JAVA_HOME/bin/java -version indicates the 64-bit VM.

I’m invoking javapackager via an Exec task in my Gradle build script.  
(I’m not using the JavaFX plugin because it has even less documentation, it 
does strange things like explicitly adding jfxrt.jar to the classpath even on 
Java 8, and it’s basically unmaintained now :-( .)

Here is what my invocation looks like:

def bundleVersion = project.version.split('-')[0] // remove -snapshot

task javapackager(type: Exec, dependsOn: [checkRpmOrDebBased, 
prepareDistribution]) {
executable "${System.getenv('JAVA_HOME')}/bin/javapackager"
doFirst {
args = [
'-deploy',
'-native', project.packageType, // use deb or rpm for linux
'-daemon',
'-title', 'My Server',
'-vendor', 'My Company',
'-srcdir', "${buildDir}/extracted-dist",
'-outdir', "${buildDir}",
'-outfile', 'MyServer',
'-name', 'MyServer',
'-appclass', 'com.something.server.MyServerMain',
//"-BappResources=${buildDir}/extracted-dist", // conflicts 
with -srcdir ?
'-BuserJvmOptions=-Xmx=512m',

'-BjvmProperties=java.util.logging.config.file=conf/logging.properties',
"-BappVersion=${bundleVersion}",
'-BmainJar=MyServer.jar',
'-BlicenseFile=EULA.rtf',
'-BsystemWide=true',
//'-BserviceHint=true', // conflicts with -daemon ?
'-BrunAtStartup=true',
'-BstartOnInstall=true',
'-BstopOnUninstall=true'
]
}
}


${buildDir}/extracted-dist  contains a full layout of the application image.


Scott


> On Feb 2, 2016, at 7:03 PM, Chris Bensen  wrote:
> 
> This list or the Deployment blog 
> (https://blogs.oracle.com/talkingjavadeployment/) are the best places to get 
> help with the javapackager.
> 
> Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
> appended to the name. If it’s 32-bit you could try running:
> 
> sudo apt-get install libx11-6:i386
> 
> Chris
> 
> 
>> On Feb 2, 2016, at 1:49 PM, Scott Palmer  wrote:
>> 
>> What's the best place to go to get help with using the javapackager ?
>> 
>> I've read the docs, but things aren't working smoothly and it would be
>> helpful if there were some known working examples to base things on.  I'm
>> not finding any examples that use the -daemon or -BserviceHint=true
>> options, for example.
>> 
>> I attempted to make a .rpm that installs a service/daemon but when I try to
>> install it, it fails claiming the following dependencies cannot be met:
>> 
>>   libX11.so.6 is needed by myserver-1.0-1.x86_64
>>   libXext.so.6 is needed by myserver-1.0-1.x86_64
>>   libXi.so.6 is needed by myserver-1.0-1.x86_64
>>   libXrender.so.1 is needed by myserver-1.0-1.x86_64
>>   libXtst.so.6 is needed by myserver-1.0-1.x86_64
>>   libasound.so.2 is needed by myserver-1.0-1.x86_64
>> 
>> Considering the app already runs fine on this same system, I'm a bit
>> confused that it is complaining of missing dependencies.
>> 
>> Scott
> 

Re: javapackager

[Scott Palmer]

Note that this is a RPM-based system, apt-get is not available, yum is.

yum install libX11
…
Package libX11-1.6.0-2.1.el7.x86_64 already installed and latest version

I get a similar message for the other dependencies.

Examining the .rpm file I can see that the bundled runtime contains a lib/amd64 
folder, so I’m pretty sure everything it did was 64-bit.

If I run:

yum install libX11.so.6

it wants to install the i686 architecture.  

So I went ahead an used yum to install the dependencies that way, but it failed 
on the last one (of course):
$ sudo yum install libasound.so.2
Resolving Dependencies
--> Running transaction check
---> Package alsa-lib.i686 0:1.0.28-2.el7 will be installed
--> Finished Dependency Resolution
Error:  Multilib version problems found.
…
   ...you can also use --setopt=protected_multilib=false to remove
   this checking, however this is almost never the correct thing to
   do as something else is very likely to go wrong (often causing
   much more problems).

   Protected multilib versions: alsa-lib-1.0.28-2.el7.i686 != 
alsa-lib-1.0.27.2-3.el7.x86_64


It seems to be that javapackager has made a mistake and is claiming to depend 
on the 32-bit packages even though it really requires the 64-bit packages.

Scott 


> On Feb 2, 2016, at 7:03 PM, Chris Bensen  wrote:
> 
> This list or the Deployment blog 
> (https://blogs.oracle.com/talkingjavadeployment/) are the best places to get 
> help with the javapackager.
> 
> Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
> appended to the name. If it’s 32-bit you could try running:
> 
> sudo apt-get install libx11-6:i386
> 
> Chris
> 
> 
>> On Feb 2, 2016, at 1:49 PM, Scott Palmer  wrote:
>> 
>> What's the best place to go to get help with using the javapackager ?
>> 
>> I've read the docs, but things aren't working smoothly and it would be
>> helpful if there were some known working examples to base things on.  I'm
>> not finding any examples that use the -daemon or -BserviceHint=true
>> options, for example.
>> 
>> I attempted to make a .rpm that installs a service/daemon but when I try to
>> install it, it fails claiming the following dependencies cannot be met:
>> 
>>   libX11.so.6 is needed by myserver-1.0-1.x86_64
>>   libXext.so.6 is needed by myserver-1.0-1.x86_64
>>   libXi.so.6 is needed by myserver-1.0-1.x86_64
>>   libXrender.so.1 is needed by myserver-1.0-1.x86_64
>>   libXtst.so.6 is needed by myserver-1.0-1.x86_64
>>   libasound.so.2 is needed by myserver-1.0-1.x86_64
>> 
>> Considering the app already runs fine on this same system, I'm a bit
>> confused that it is complaining of missing dependencies.
>> 
>> Scott
> 

Re: javapackager native windows bundle non empty app.classpath (package.cfg)

[Danno Ferrin]

This looks to be a bug.  Can you post what version of the jdk you are using?  
Also, can you post a JIRA for this at javafx-jira.kenai.com?


On Oct 6, 2014, at 2:13 PM, Stefan Kreutter openjfx-...@kreutter.de wrote:

 Hoping to address my question to the appropriate list...
 
 Is it possible to use the javapackager (ant-tasks) to create a Windows exe 
 and having the app.classpath property of package.cfg populated? I use 
 something like this:
 
 fx:deploy nativeBundles=all outdir=${basedir}/${dist.dir} 
 outfile=${application.title} verbose=true width=600 height=400
fx:application name=${application.name} 
 mainClass=${javafx.main.class}/
fx:resources
!-- include dependencies copied by the maven-dependency-plugin --
fx:fileset dir=target/dependency includes=*.jar type=jar/
/fx:resources
fx:info title=${application.title} category=${application.group} 
 vendor=${application.vendor} copyright=${application.copyright}
fx:icon href=${application.icon}/
/fx:info
 /fx:deploy
 
 The directory target/dependency contains several jar files (which by the way 
 end up properly in the generated JNLP file) but only the jar file of the main 
 class is references in the package.cfg inside 
 native/bundles/${application.title}/app/package.cfg:
 
 app.mainjar=app-1.0-SNAPSHOT.jar
 app.version=1.0
 app.id=org.example.demo.app
 app.preferences.id=org/example/demo/app
 app.mainclass= org/example/demo/app/DemoApp
 app.classpath=
 
 In the source code of 
 java/com/sun/javafx/tools/packager/bundlers/WinAppBundler.java I found the 
 following comment:
 
 private void writePkgInfo(MapString, ? super Object params, File 
 pkgInfoFile) throws FileNotFoundException {
   [...]
  //This will be emtry string for correctly packaged JavaFX apps
  out.println(app.classpath= + MAIN_JAR_CLASSPATH.fetchFrom(params));
   [...]
 }
 
 So it seems that having a classpath with fx:deploy besides the main JAR is 
 not possible/wanted.
 
 Thanks in advance,
 Stefan
 

Re: Javapackager not calling MyApp-post-image.sh on MacOSX

[Kevin Rushforth]

This is the proper place to discuss the javapackager (at least for the 
near term). Bugs are still tracked through the JavaFX JIRA. The source 
code lives in the JavaFX repo and it is built and delivered into the JDK 
as part of the JavaFX build.


-- Kevin


Jeff Martin wrote:

I’m glad to see that javafxpackager is now javapackager. So my question should 
be - what is the proper forum to post a javapackger question, or who at Oracle 
could create a new dedicated forum for it?

In the meantime, does anyone have a suggestion to diagnose why my custom 
package/macosx/MyApp-post-image.sh isn’t getting called? Javapackager is 
picking up my custom icons fine, and the windows post-image.wsf is getting 
picked up fine. Just not getting called on MacOSX.

jeff

Re: Javapackager not calling MyApp-post-image.sh on MacOSX

[Jeff Martin]

Actually, for the moment I’m just generating “image”, though I tried pkg and it 
also didn’t call the post-image script.

I love all the customization tips when verbose is turned on. I was hoping it 
would say, “No post-image script found at package/macosx/SnapCode-post-image.sh 
- add one here for customization”.

jeff


On Sep 3, 2014, at 2:46 PM, Danno Ferrin danno.fer...@oracle.com wrote:

 What mac package format?  DMG or PKG?
 
 
 On Sep 3, 2014, at 12:38 PM, Jeff Martin j...@reportmill.com wrote:
 
 I’m glad to see that javafxpackager is now javapackager. So my question 
 should be - what is the proper forum to post a javapackger question, or who 
 at Oracle could create a new dedicated forum for it?
 
 In the meantime, does anyone have a suggestion to diagnose why my custom 
 package/macosx/MyApp-post-image.sh isn’t getting called? Javapackager is 
 picking up my custom icons fine, and the windows post-image.wsf is getting 
 picked up fine. Just not getting called on MacOSX.
 
 jeff
 

Re: Javapackager not calling MyApp-post-image.sh on MacOSX

[Danno Ferrin]

A quick code inspection shows that the post image script is only called for DMG 
packaging.  Looks to be a PKG oversight.  Could you post a bug to 
javafx-jira.kenai.com?

On Sep 3, 2014, at 2:31 PM, Jeff Martin j...@reportmill.com wrote:

 Actually, for the moment I’m just generating “image”, though I tried pkg and 
 it also didn’t call the post-image script.
 
 I love all the customization tips when verbose is turned on. I was hoping it 
 would say, “No post-image script found at 
 package/macosx/SnapCode-post-image.sh - add one here for customization”.
 
 jeff
 
 
 On Sep 3, 2014, at 2:46 PM, Danno Ferrin danno.fer...@oracle.com wrote:
 
 What mac package format?  DMG or PKG?
 
 
 On Sep 3, 2014, at 12:38 PM, Jeff Martin j...@reportmill.com wrote:
 
 I’m glad to see that javafxpackager is now javapackager. So my question 
 should be - what is the proper forum to post a javapackger question, or who 
 at Oracle could create a new dedicated forum for it?
 
 In the meantime, does anyone have a suggestion to diagnose why my custom 
 package/macosx/MyApp-post-image.sh isn’t getting called? Javapackager is 
 picking up my custom icons fine, and the windows post-image.wsf is getting 
 picked up fine. Just not getting called on MacOSX.
 
 jeff
 
 

Re: Javapackager not calling MyApp-post-image.sh on MacOSX

[Jeff Martin]

Done: RT-38521 - Javapackager not calling post-image script on MacOSX for PKG 
and IMAGE

jeff


On Sep 3, 2014, at 4:15 PM, Danno Ferrin danno.fer...@oracle.com wrote:

 A quick code inspection shows that the post image script is only called for 
 DMG packaging.  Looks to be a PKG oversight.  Could you post a bug to 
 javafx-jira.kenai.com?
 
 On Sep 3, 2014, at 2:31 PM, Jeff Martin j...@reportmill.com wrote:
 
 Actually, for the moment I’m just generating “image”, though I tried pkg and 
 it also didn’t call the post-image script.
 
 I love all the customization tips when verbose is turned on. I was hoping it 
 would say, “No post-image script found at 
 package/macosx/SnapCode-post-image.sh - add one here for customization”.
 
 jeff
 
 
 On Sep 3, 2014, at 2:46 PM, Danno Ferrin danno.fer...@oracle.com wrote:
 
 What mac package format?  DMG or PKG?
 
 
 On Sep 3, 2014, at 12:38 PM, Jeff Martin j...@reportmill.com wrote:
 
 I’m glad to see that javafxpackager is now javapackager. So my question 
 should be - what is the proper forum to post a javapackger question, or 
 who at Oracle could create a new dedicated forum for it?
 
 In the meantime, does anyone have a suggestion to diagnose why my custom 
 package/macosx/MyApp-post-image.sh isn’t getting called? Javapackager is 
 picking up my custom icons fine, and the windows post-image.wsf is getting 
 picked up fine. Just not getting called on MacOSX.
 
 jeff
 
 
 

Re: Javapackager not calling MyApp-post-image.sh on MacOSX

[Jeff Martin]

I just tested with DMG and my script does get called. However, it seems like I 
can’t use it to add and remove JDK files without invalidating the codesign 
work. Is it possible for javapackager to build the image, call the post-image 
script, then codesign?

jeff


On Sep 3, 2014, at 4:33 PM, Jeff Martin j...@reportmill.com wrote:

 Done: RT-38521 - Javapackager not calling post-image script on MacOSX for PKG 
 and IMAGE
 
 jeff
 
 
 On Sep 3, 2014, at 4:15 PM, Danno Ferrin danno.fer...@oracle.com wrote:
 
 A quick code inspection shows that the post image script is only called for 
 DMG packaging.  Looks to be a PKG oversight.  Could you post a bug to 
 javafx-jira.kenai.com?
 
 On Sep 3, 2014, at 2:31 PM, Jeff Martin j...@reportmill.com wrote:
 
 Actually, for the moment I’m just generating “image”, though I tried pkg 
 and it also didn’t call the post-image script.
 
 I love all the customization tips when verbose is turned on. I was hoping 
 it would say, “No post-image script found at 
 package/macosx/SnapCode-post-image.sh - add one here for customization”.
 
 jeff
 
 
 On Sep 3, 2014, at 2:46 PM, Danno Ferrin danno.fer...@oracle.com wrote:
 
 What mac package format?  DMG or PKG?
 
 
 On Sep 3, 2014, at 12:38 PM, Jeff Martin j...@reportmill.com wrote:
 
 I’m glad to see that javafxpackager is now javapackager. So my question 
 should be - what is the proper forum to post a javapackger question, or 
 who at Oracle could create a new dedicated forum for it?
 
 In the meantime, does anyone have a suggestion to diagnose why my custom 
 package/macosx/MyApp-post-image.sh isn’t getting called? Javapackager is 
 picking up my custom icons fine, and the windows post-image.wsf is 
 getting picked up fine. Just not getting called on MacOSX.
 
 jeff

Re: Javapackager not calling MyApp-post-image.sh on MacOSX

[Danno Ferrin]

Excellent point.  I'll move the script to before the codesign.

I've also got some bugs requesting an easy flag to turn off auto-codesign.  
I'll do that as part of the 8u40 work.

In the mean time, you can disable codesign with a bundler argument in ant by 
adding this to the fx:deploy element

fx:bundleargument arg='mac.signing-key-user-name' value='Nonexistent User'/ 

(for cli it is -Bmac.signing-key-user-name=Nonexistent User)

Then in your post image script you can hand wire the signing.

On Sep 3, 2014, at 3:43 PM, Jeff Martin j...@reportmill.com wrote:

 I just tested with DMG and my script does get called. However, it seems like 
 I can’t use it to add and remove JDK files without invalidating the codesign 
 work. Is it possible for javapackager to build the image, call the post-image 
 script, then codesign?
 
 jeff
 
 
 On Sep 3, 2014, at 4:33 PM, Jeff Martin j...@reportmill.com wrote:
 
 Done: RT-38521 - Javapackager not calling post-image script on MacOSX for 
 PKG and IMAGE
 
 jeff
 
 
 On Sep 3, 2014, at 4:15 PM, Danno Ferrin danno.fer...@oracle.com wrote:
 
 A quick code inspection shows that the post image script is only called for 
 DMG packaging.  Looks to be a PKG oversight.  Could you post a bug to 
 javafx-jira.kenai.com?
 
 On Sep 3, 2014, at 2:31 PM, Jeff Martin j...@reportmill.com wrote:
 
 Actually, for the moment I’m just generating “image”, though I tried pkg 
 and it also didn’t call the post-image script.
 
 I love all the customization tips when verbose is turned on. I was hoping 
 it would say, “No post-image script found at 
 package/macosx/SnapCode-post-image.sh - add one here for customization”.
 
 jeff
 
 
 On Sep 3, 2014, at 2:46 PM, Danno Ferrin danno.fer...@oracle.com wrote:
 
 What mac package format?  DMG or PKG?
 
 
 On Sep 3, 2014, at 12:38 PM, Jeff Martin j...@reportmill.com wrote:
 
 I’m glad to see that javafxpackager is now javapackager. So my question 
 should be - what is the proper forum to post a javapackger question, or 
 who at Oracle could create a new dedicated forum for it?
 
 In the meantime, does anyone have a suggestion to diagnose why my custom 
 package/macosx/MyApp-post-image.sh isn’t getting called? Javapackager is 
 picking up my custom icons fine, and the windows post-image.wsf is 
 getting picked up fine. Just not getting called on MacOSX.
 
 jeff