Re: Comments on jpackage (JEP 343)

[Sverre Moe]

ons. 2. okt. 2019 kl. 19:14 skrev Alexey Semenyuk <
alexey.semen...@oracle.com>:

>
>
> On 10/2/2019 12:33 PM, Sverre Moe wrote:
>
> ons. 2. okt. 2019 kl. 16:07 skrev Alexey Semenyuk <
> alexey.semen...@oracle.com>:
>
>> Hi Sverre,
>>
>> Thank you for doing this research. I don't think we should complicate
>> jpackage by adding signing steps in it.
>> However we can add a call to custom script after msi is constructed but
>> before it get embedded in exe installer.
>> This script can sign msi.
>
> We already support call of custom script from resource dir before
>> building msi. Just need to add another call.
>>
>> - Alexey
>>
>
> I can certainly use the custom application-post-image.wsf to sign the
> application image executable. However I don't think it would be easy
> considering that this executable is left read-only by jpackage.
>
> I didn't mean to sign application image executable. This opportunity is
> already available.
>

Maybe I have missed something, but I cannot see this is available for
jpackage to sign the application image executable.


> I meant we can add to jpackage functionality to call custom script after
> msi is created but before it get embedded in exe installer.
> Exe installer produced by jpackage is just a container for msi installer.
> Before msi will be put in the container there will be an opportunity to
> modify (sign) the msi.
> Currently the steps to create exe installer are:
> 1.1 Create app image
> 1.2 Call application-post-image.wsf if available
> 2. Create msi from app image
> 3. Create exe from msi
>
> It will be changed to:
> 1.1 Create app image
> 1.2 Call application-post-image.wsf if available
> 2.1 Create msi from app image
> 2.2 Call application-post-msi.wsf if available
> 3. Create exe from msi
>
> - Alexey
>
> Thanks for making it much clearer.

/Sverre

Re: Comments on jpackage (JEP 343)

[Alexey Semenyuk]

On 10/2/2019 12:33 PM, Sverre Moe wrote:
ons. 2. okt. 2019 kl. 16:07 skrev Alexey Semenyuk 
mailto:alexey.semen...@oracle.com>>:


Hi Sverre,

Thank you for doing this research. I don't think we should complicate
jpackage by adding signing steps in it.
However we can add a call to custom script after msi is
constructed but
before it get embedded in exe installer.
This script can sign msi.

We already support call of custom script from resource dir before
building msi. Just need to add another call.

- Alexey

I can certainly use the custom application-post-image.wsf to sign the 
application image executable. However I don't think it would be easy 
considering that this executable is left read-only by jpackage.
I didn't mean to sign application image executable. This opportunity is 
already available.
I meant we can add to jpackage functionality to call custom script after 
msi is created but before it get embedded in exe installer.
Exe installer produced by jpackage is just a container for msi 
installer. Before msi will be put in the container there will be an 
opportunity to modify (sign) the msi.

Currently the steps to create exe installer are:
1.1 Create app image
1.2 Call application-post-image.wsf if available
2. Create msi from app image
3. Create exe from msi

It will be changed to:
1.1 Create app image
1.2 Call application-post-image.wsf if available
2.1 Create msi from app image
2.2 Call application-post-msi.wsf if available
3. Create exe from msi

- Alexey



When it comes to signing the MSI and EXE installers, that can be done 
after running jpackage with a Gradle Exec task.


/Sverre

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

ons. 2. okt. 2019 kl. 16:07 skrev Alexey Semenyuk <
alexey.semen...@oracle.com>:

> Hi Sverre,
>
> Thank you for doing this research. I don't think we should complicate
> jpackage by adding signing steps in it.
> However we can add a call to custom script after msi is constructed but
> before it get embedded in exe installer.
> This script can sign msi.

We already support call of custom script from resource dir before
> building msi. Just need to add another call.
>
> - Alexey
>

I can certainly use the custom application-post-image.wsf to sign the
application image executable. However I don't think it would be easy
considering that this executable is left read-only by jpackage.

When it comes to signing the MSI and EXE installers, that can be done after
running jpackage with a Gradle Exec task.

/Sverre

Re: Comments on jpackage (JEP 343)

[Alexey Semenyuk]

Hi Sverre,

Thank you for doing this research. I don't think we should complicate 
jpackage by adding signing steps in it.
However we can add a call to custom script after msi is constructed but 
before it get embedded in exe installer.

This script can sign msi.
We already support call of custom script from resource dir before 
building msi. Just need to add another call.


- Alexey

On 10/2/2019 9:41 AM, Sverre Moe wrote:

ons. 25. sep. 2019 kl. 15:45 skrev Sverre Moe :


I have some new comments regarding the Windows build of jpackage.

1)
Is there any way to build an trusted application installer using WiX?
I want to avoid "Unknown Publisher" when installing the application.
Also having problems with Windows Defender SmartScreen, depending on what
settings the user has (Block, Warn, Off).
If Block, the user cannot install the application. If Warn, the user can
click "More info", then "Run anyway".




I have looked into this. It can be done with using tools like insignia [1]
and signtool [2].

It can be done after the MSI has been built by jpackage using the tool
SignTool from the Microsoft SDK.
I successfully managed to sign the MSI and EXE built by jpackage:

$ /cygdrive/c/Program\ Files\ \(x86\)/Windows\

Kits/10/bin/10.0.18362.0/x64/signtool.exe sign /v /a /d "Application
Installer" /f "cert.pfx" /p certpass /fd SHA256 /t
http://timestamp.digicert.com build/native/application-1.1.0.msi

It could also be beneficial to sign the application executable in the
application image prior to creating the application installer package.
Since the native application executable does not have write access after
being constructed by jpackage, then in order to use signtool on it I had to
modify the file permissions.

I have yet to find out how to do it with WiX.

[1] https://wixtoolset.org/documentation/manual/v3/overview/insignia.html
[2] https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool

/Sverre

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

ons. 25. sep. 2019 kl. 15:45 skrev Sverre Moe :

> I have some new comments regarding the Windows build of jpackage.
>
> 1)
> Is there any way to build an trusted application installer using WiX?
> I want to avoid "Unknown Publisher" when installing the application.
> Also having problems with Windows Defender SmartScreen, depending on what
> settings the user has (Block, Warn, Off).
> If Block, the user cannot install the application. If Warn, the user can
> click "More info", then "Run anyway".
>
>>
>>
I have looked into this. It can be done with using tools like insignia [1]
and signtool [2].

It can be done after the MSI has been built by jpackage using the tool
SignTool from the Microsoft SDK.
I successfully managed to sign the MSI and EXE built by jpackage:
> $ /cygdrive/c/Program\ Files\ \(x86\)/Windows\
Kits/10/bin/10.0.18362.0/x64/signtool.exe sign /v /a /d "Application
Installer" /f "cert.pfx" /p certpass /fd SHA256 /t
http://timestamp.digicert.com build/native/application-1.1.0.msi

It could also be beneficial to sign the application executable in the
application image prior to creating the application installer package.
Since the native application executable does not have write access after
being constructed by jpackage, then in order to use signtool on it I had to
modify the file permissions.

I have yet to find out how to do it with WiX.

[1] https://wixtoolset.org/documentation/manual/v3/overview/insignia.html
[2] https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool

/Sverre

Re: Comments on jpackage (JEP 343)

[Alexey Semenyuk]

Sverre,

Thank you for your feedback. I've captured it in 
https://bugs.openjdk.java.net/browse/JDK-8230668.


- Alexey

On 9/25/2019 9:45 AM, Sverre Moe wrote:

I have some new comments regarding the Windows build of jpackage.

1)
Is there any way to build an trusted application installer using WiX?
I want to avoid "Unknown Publisher" when installing the application.
Also having problems with Windows Defender SmartScreen, depending on what
settings the user has (Block, Warn, Off).
If Block, the user cannot install the application. If Warn, the user can
click "More info", then "Run anyway".

2)
The EXE installer details has no information about the actual application
it will install.
File version: 14.0.0
Product Name OpenJDK Platform 14
Product version: 14
This is not quite right, since the application was built with Java 11, only
packaged with jpackage from Java 14.
Should it not use the name and app version supplied to jpackage on these
properties.

Original filename: msiwrapper.msi.
It should be the name supplied to jpackage used here at least >
applicationName.msi

Building an MSI has much better detail properties, but a couple of the
description properties says nothing about the actual application.
Title: Installation Database
Comments: This installer database contains the logic and data required to
install applicationName.
Any way to change the title and comments?

3)
The icon for the installer file is not using the one from the resource
directory. If supplied the --icon argument is not used.
Both Explorer and List of installed application shows a generic application
icon.

4)
MSI installer has a Category detail property. Perhaps jpackage should have
an --windows-category argument.

5)
Help text for --icon argument should mention that it needs to be an ICO
when packaging on Windows.

Currently there is no way to supply a custom WXS file to WiX in the
resource directory. Perhaps this could help further customization.

/Sverre



tor. 19. sep. 2019 kl. 20:29 skrev Kevin Rushforth <
kevin.rushfo...@oracle.com>:


OK, that makes sense. Andy has already implemented this change (pushed
it to the sandbox), so it will be in the next EA build.

-- Kevin

On 9/19/2019 10:25 AM, mark.reinh...@oracle.com wrote:

jlink’s -o/--output option names exactly the thing being output,
rather than a container for the thing being output.

The jpackage option we’re discussing here names a container for the
thing being output, much like the -d option of javac and javadoc.

Using -d/--dest for jpackage is consistent with the JDK’s other
command-line tools.

- Mark

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

I have some new comments regarding the Windows build of jpackage.

1)
Is there any way to build an trusted application installer using WiX?
I want to avoid "Unknown Publisher" when installing the application.
Also having problems with Windows Defender SmartScreen, depending on what
settings the user has (Block, Warn, Off).
If Block, the user cannot install the application. If Warn, the user can
click "More info", then "Run anyway".

2)
The EXE installer details has no information about the actual application
it will install.
File version: 14.0.0
Product Name OpenJDK Platform 14
Product version: 14
This is not quite right, since the application was built with Java 11, only
packaged with jpackage from Java 14.
Should it not use the name and app version supplied to jpackage on these
properties.

Original filename: msiwrapper.msi.
It should be the name supplied to jpackage used here at least >
applicationName.msi

Building an MSI has much better detail properties, but a couple of the
description properties says nothing about the actual application.
Title: Installation Database
Comments: This installer database contains the logic and data required to
install applicationName.
Any way to change the title and comments?

3)
The icon for the installer file is not using the one from the resource
directory. If supplied the --icon argument is not used.
Both Explorer and List of installed application shows a generic application
icon.

4)
MSI installer has a Category detail property. Perhaps jpackage should have
an --windows-category argument.

5)
Help text for --icon argument should mention that it needs to be an ICO
when packaging on Windows.

Currently there is no way to supply a custom WXS file to WiX in the
resource directory. Perhaps this could help further customization.

/Sverre



tor. 19. sep. 2019 kl. 20:29 skrev Kevin Rushforth <
kevin.rushfo...@oracle.com>:

> OK, that makes sense. Andy has already implemented this change (pushed
> it to the sandbox), so it will be in the next EA build.
>
> -- Kevin
>
> On 9/19/2019 10:25 AM, mark.reinh...@oracle.com wrote:
> > jlink’s -o/--output option names exactly the thing being output,
> > rather than a container for the thing being output.
> >
> > The jpackage option we’re discussing here names a container for the
> > thing being output, much like the -d option of javac and javadoc.
> >
> > Using -d/--dest for jpackage is consistent with the JDK’s other
> > command-line tools.
> >
> > - Mark
>
>

Re: Comments on jpackage (JEP 343)

[Kevin Rushforth]

OK, that makes sense. Andy has already implemented this change (pushed 
it to the sandbox), so it will be in the next EA build.


-- Kevin

On 9/19/2019 10:25 AM, mark.reinh...@oracle.com wrote:

jlink’s -o/--output option names exactly the thing being output,
rather than a container for the thing being output.

The jpackage option we’re discussing here names a container for the
thing being output, much like the -d option of javac and javadoc.

Using -d/--dest for jpackage is consistent with the JDK’s other
command-line tools.

- Mark

Re: Comments on jpackage (JEP 343)

[mark . reinhold]

jlink’s -o/--output option names exactly the thing being output,
rather than a container for the thing being output.

The jpackage option we’re discussing here names a container for the
thing being output, much like the -d option of javac and javadoc.

Using -d/--dest for jpackage is consistent with the JDK’s other
command-line tools.

- Mark

Re: Comments on jpackage (JEP 343)

[Philip Race]

I also think the list of dependencies is too much.
It is probably being derived in an automatic manner that really isn't 
adequate.


For example these (at least) are standard libraries included in the JDK 
run time you are verifying

libawt.so()(64bit)
libawt_xawt.so()(64bit)
libjava.so()(64bit)
libjli.so()(64bit)
libjvm.so()(64bit)
libjvm.so(SUNWprivate_1.1)(64bit)
libverify.so()(64bit)

and this ..
libcairo.so.2()(64bit)
... I am not aware that either FX or AWT/2D has any direct dependency on 
Cairo.
So this is perhaps being dragged in by some other lib (gdk) and if so, 
it is a bit presumptuous

to assume that gdk necessarily implies Cairo ..


and don't all rpms depend on rpm :-)
Seems unnecessary for it to be here :

rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

-phil




On 9/19/19, 8:13 AM, Sverre Moe wrote:

It seems jpackage should not need to add these Requires to the RPM package.
If adding the JavaFX modules to the runtime image, these so-files are
bundled within the lib directory.
Thus no need for them to be required for installing the RPM.
They should perhaps only be necessary as required if the JavaFX modules are
not in the runtime image, but only present as dependencies to the
application.

tor. 19. sep. 2019 kl. 15:14 skrev Kevin Rushforth<
kevin.rushfo...@oracle.com>:


As to why it has this Requires, perhaps I need to address it at the

JavaFX

mailinglist.

Yes, that would be best, as this is no longer related to jpackage.

-- Kevin


On 9/19/2019 12:43 AM, Sverre Moe wrote:

Yes it would seem so.

I am still perplexed to why it has an RPM Requires

libavcodec-ffmpeg.so.56.

That one does not exist as far as I can find anywhere. It is not provided
with the ffmpeg package.
I thought perhaps it was the same library as libavcodec.so.56 only named
differently, but considering that also is listed among the Requires it

is a

distinct package.
As to why it has this Requires, perhaps I need to address it at the

JavaFX

mailinglist.

How does jpackage accumulate its RPM Requires list? I thought it had it

in

a default RPM spec file, but I don't see how that can be, we use our own
custom spec file, and jpackage adds many additional Requires not used in
our own. Only when javafx-web is within the built runtime image used with
jpackage, is these extra Requires used.
The RPM spec template file does not have any hard coded Requires, only
those from PACKAGE_DEPENDENCIES. I looked around in the source code, and
could only see this was set from the command line arguments for
dependencies. Does it scan the runtime image to produce its additional
Requires list? I have the javafx as dependencies in my project, but those
are not "scanned" for linux package dependencies.


https://hg.openjdk.java.net/jdk/sandbox/file/bf06a1d3aef6/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/

Trying with the --linux-package-deps none of those dependencies ended up

in

the built RPM package. Only those from jpackage and those from our custom
spec file.

/Sverre


tor. 19. sep. 2019 kl. 01:09 skrev Michael Paus:


If you don't use audio or video, you will probably not need it.

Have a look here: https://ffmpeg.org/


Message: 2
Date: Wed, 18 Sep 2019 23:44:19 +0200
From: Sverre Moe
To: Philip Race
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Comments on jpackage (JEP 343)
Message-ID:

qakvdetirxlfcny0cvh4poezg...@mail.gmail.com>

Content-Type: text/plain; charset="UTF-8"

It is actually the javafx-web module that requires these.

Anyone know what part of the Web module that needs the libavcodec and
libavcoded-ffmpeg?

We are using a small part of the web module, just WebView for Tooltip

with

HTML. No Video or Audio.

/Sverre

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

It seems jpackage should not need to add these Requires to the RPM package.
If adding the JavaFX modules to the runtime image, these so-files are
bundled within the lib directory.
Thus no need for them to be required for installing the RPM.
They should perhaps only be necessary as required if the JavaFX modules are
not in the runtime image, but only present as dependencies to the
application.

tor. 19. sep. 2019 kl. 15:14 skrev Kevin Rushforth <
kevin.rushfo...@oracle.com>:

>
> > As to why it has this Requires, perhaps I need to address it at the
> JavaFX
> > mailinglist.
>
> Yes, that would be best, as this is no longer related to jpackage.
>
> -- Kevin
>
>
> On 9/19/2019 12:43 AM, Sverre Moe wrote:
> > Yes it would seem so.
> >
> > I am still perplexed to why it has an RPM Requires
> libavcodec-ffmpeg.so.56.
> > That one does not exist as far as I can find anywhere. It is not provided
> > with the ffmpeg package.
> > I thought perhaps it was the same library as libavcodec.so.56 only named
> > differently, but considering that also is listed among the Requires it
> is a
> > distinct package.
> > As to why it has this Requires, perhaps I need to address it at the
> JavaFX
> > mailinglist.
> >
> > How does jpackage accumulate its RPM Requires list? I thought it had it
> in
> > a default RPM spec file, but I don't see how that can be, we use our own
> > custom spec file, and jpackage adds many additional Requires not used in
> > our own. Only when javafx-web is within the built runtime image used with
> > jpackage, is these extra Requires used.
> > The RPM spec template file does not have any hard coded Requires, only
> > those from PACKAGE_DEPENDENCIES. I looked around in the source code, and
> > could only see this was set from the command line arguments for
> > dependencies. Does it scan the runtime image to produce its additional
> > Requires list? I have the javafx as dependencies in my project, but those
> > are not "scanned" for linux package dependencies.
> >
> https://hg.openjdk.java.net/jdk/sandbox/file/bf06a1d3aef6/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/
> >
> > Trying with the --linux-package-deps none of those dependencies ended up
> in
> > the built RPM package. Only those from jpackage and those from our custom
> > spec file.
> >
> > /Sverre
> >
> >
> > tor. 19. sep. 2019 kl. 01:09 skrev Michael Paus :
> >
> >> If you don't use audio or video, you will probably not need it.
> >>
> >> Have a look here: https://ffmpeg.org/
> >>
> >>> Message: 2
> >>> Date: Wed, 18 Sep 2019 23:44:19 +0200
> >>> From: Sverre Moe 
> >>> To: Philip Race 
> >>> Cc: core-libs-dev@openjdk.java.net
> >>> Subject: Re: Comments on jpackage (JEP 343)
> >>> Message-ID:
> >>> >> qakvdetirxlfcny0cvh4poezg...@mail.gmail.com>
> >>> Content-Type: text/plain; charset="UTF-8"
> >>>
> >>> It is actually the javafx-web module that requires these.
> >>>
> >>> Anyone know what part of the Web module that needs the libavcodec and
> >>> libavcoded-ffmpeg?
> >>>
> >>> We are using a small part of the web module, just WebView for Tooltip
> >> with
> >>> HTML. No Video or Audio.
> >>>
> >>> /Sverre
> >>
>
>

Re: Comments on jpackage (JEP 343)

[Kevin Rushforth]

As to why it has this Requires, perhaps I need to address it at the JavaFX
mailinglist.


Yes, that would be best, as this is no longer related to jpackage.

-- Kevin


On 9/19/2019 12:43 AM, Sverre Moe wrote:

Yes it would seem so.

I am still perplexed to why it has an RPM Requires libavcodec-ffmpeg.so.56.
That one does not exist as far as I can find anywhere. It is not provided
with the ffmpeg package.
I thought perhaps it was the same library as libavcodec.so.56 only named
differently, but considering that also is listed among the Requires it is a
distinct package.
As to why it has this Requires, perhaps I need to address it at the JavaFX
mailinglist.

How does jpackage accumulate its RPM Requires list? I thought it had it in
a default RPM spec file, but I don't see how that can be, we use our own
custom spec file, and jpackage adds many additional Requires not used in
our own. Only when javafx-web is within the built runtime image used with
jpackage, is these extra Requires used.
The RPM spec template file does not have any hard coded Requires, only
those from PACKAGE_DEPENDENCIES. I looked around in the source code, and
could only see this was set from the command line arguments for
dependencies. Does it scan the runtime image to produce its additional
Requires list? I have the javafx as dependencies in my project, but those
are not "scanned" for linux package dependencies.
https://hg.openjdk.java.net/jdk/sandbox/file/bf06a1d3aef6/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/

Trying with the --linux-package-deps none of those dependencies ended up in
the built RPM package. Only those from jpackage and those from our custom
spec file.

/Sverre


tor. 19. sep. 2019 kl. 01:09 skrev Michael Paus :


If you don't use audio or video, you will probably not need it.

Have a look here: https://ffmpeg.org/


Message: 2
Date: Wed, 18 Sep 2019 23:44:19 +0200
From: Sverre Moe 
To: Philip Race 
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Comments on jpackage (JEP 343)
Message-ID:
   
qakvdetirxlfcny0cvh4poezg...@mail.gmail.com>

Content-Type: text/plain; charset="UTF-8"

It is actually the javafx-web module that requires these.

Anyone know what part of the Web module that needs the libavcodec and
libavcoded-ffmpeg?

We are using a small part of the web module, just WebView for Tooltip

with

HTML. No Video or Audio.

/Sverre

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

Yes it would seem so.

I am still perplexed to why it has an RPM Requires libavcodec-ffmpeg.so.56.
That one does not exist as far as I can find anywhere. It is not provided
with the ffmpeg package.
I thought perhaps it was the same library as libavcodec.so.56 only named
differently, but considering that also is listed among the Requires it is a
distinct package.
As to why it has this Requires, perhaps I need to address it at the JavaFX
mailinglist.

How does jpackage accumulate its RPM Requires list? I thought it had it in
a default RPM spec file, but I don't see how that can be, we use our own
custom spec file, and jpackage adds many additional Requires not used in
our own. Only when javafx-web is within the built runtime image used with
jpackage, is these extra Requires used.
The RPM spec template file does not have any hard coded Requires, only
those from PACKAGE_DEPENDENCIES. I looked around in the source code, and
could only see this was set from the command line arguments for
dependencies. Does it scan the runtime image to produce its additional
Requires list? I have the javafx as dependencies in my project, but those
are not "scanned" for linux package dependencies.
https://hg.openjdk.java.net/jdk/sandbox/file/bf06a1d3aef6/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/

Trying with the --linux-package-deps none of those dependencies ended up in
the built RPM package. Only those from jpackage and those from our custom
spec file.

/Sverre


tor. 19. sep. 2019 kl. 01:09 skrev Michael Paus :

> If you don't use audio or video, you will probably not need it.
>
> Have a look here: https://ffmpeg.org/
>
> > Message: 2
> > Date: Wed, 18 Sep 2019 23:44:19 +0200
> > From: Sverre Moe 
> > To: Philip Race 
> > Cc: core-libs-dev@openjdk.java.net
> > Subject: Re: Comments on jpackage (JEP 343)
> > Message-ID:
> >qakvdetirxlfcny0cvh4poezg...@mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > It is actually the javafx-web module that requires these.
> >
> > Anyone know what part of the Web module that needs the libavcodec and
> > libavcoded-ffmpeg?
> >
> > We are using a small part of the web module, just WebView for Tooltip
> with
> > HTML. No Video or Audio.
> >
> > /Sverre
>
>

Re: Comments on jpackage (JEP 343)

[Michael Paus]

If you don't use audio or video, you will probably not need it.

Have a look here: https://ffmpeg.org/


Message: 2
Date: Wed, 18 Sep 2019 23:44:19 +0200
From: Sverre Moe 
To: Philip Race 
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Comments on jpackage (JEP 343)
Message-ID:

Content-Type: text/plain; charset="UTF-8"

It is actually the javafx-web module that requires these.

Anyone know what part of the Web module that needs the libavcodec and
libavcoded-ffmpeg?

We are using a small part of the web module, just WebView for Tooltip with
HTML. No Video or Audio.

/Sverre

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

It seems many of the RPM Requires comes from me adding the JavaFX jmods to
the application image.
--add-modules javafx.base javafx.controls javafx.graphics javafx.fxml
javafx.media javafx.web javafx.swing

Without the JavaFX jmods added to runtime image I get only these Requires.

libX11.so.6()(64bit)
libXext.so.6()(64bit)
libXi.so.6()(64bit)
libXrender.so.1()(64bit)
libXtst.so.6()(64bit)
libasound.so.2()(64bit)
libasound.so.2(ALSA_0.9)(64bit)
libasound.so.2(ALSA_0.9.0rc4)(64bit)
libawt.so()(64bit)
libawt_xawt.so()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.6)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libfreetype.so()(64bit)
libjava.so()(64bit)
libjli.so()(64bit)
libjvm.so()(64bit)
libjvm.so(SUNWprivate_1.1)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libnet.so()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
libverify.so()(64bit)
libz.so.1()(64bit)


/Sverre


tir. 17. sep. 2019 kl. 10:25 skrev Sverre Moe :

> I have built many times with the new jpackage, but actually just now tried
> to install the package built by it.
>
> The new jpackage adds a lot of Requires to the built RPM package. We had
> the same problem with the old javapackager. Its default RPM spec file had a
> lot of Requires that made it difficult for us to install our package on
> different Linux distributions. We circumvented this by packaging the
> application image with the Gradle ospackage plugin for RPM and DEB packages.
>
> Only the last one of these requires is actually in our RPM spec file
> provided with --resource-dir.
>
> I cannot even install the package on the system I built it, because it
> cannot find libavcodec-ffmpeg.so.56
> For OpenSUSE Leap 15.1, my Linux distribution there is no package that
> provides the libavcodec-ffmpeg.
>
> Are all these Requires actually necessary for running a JavaFX application
> on Linux?
> As mentioned we had packaged our JavaFX 8 application with Gradle
> ospackage plugin without all these Requires, and it has worked fine on RPM
> Linux distributions.
>
> ld-linux-x86-64.so.2()(64bit)
> ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
> libGL.so.1()(64bit)
> libX11.so.6()(64bit)
> libXext.so.6()(64bit)
> libXi.so.6()(64bit)
> libXrender.so.1()(64bit)
> libXtst.so.6()(64bit)
> libasound.so.2()(64bit)
> libasound.so.2(ALSA_0.9)(64bit)
> libasound.so.2(ALSA_0.9.0rc4)(64bit)
> libavcodec-ffmpeg.so.56()(64bit)
> libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit)
> libavcodec.so.54()(64bit)
> libavcodec.so.54(LIBAVCODEC_54)(64bit)
> libavcodec.so.56()(64bit)
> libavcodec.so.56(LIBAVCODEC_56)(64bit)
> libavcodec.so.57()(64bit)
> libavcodec.so.57(LIBAVCODEC_57)(64bit)
> libavformat-ffmpeg.so.56()(64bit)
> libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit)
> libavformat.so.54()(64bit)
> libavformat.so.54(LIBAVFORMAT_54)(64bit)
> libavformat.so.56()(64bit)
> libavformat.so.56(LIBAVFORMAT_56)(64bit)
> libavformat.so.57()(64bit)
> libavformat.so.57(LIBAVFORMAT_57)(64bit)
> libawt.so()(64bit)
> libawt_xawt.so()(64bit)
> libc.so.6()(64bit)
> libc.so.6(GLIBC_2.11)(64bit)
> libc.so.6(GLIBC_2.14)(64bit)
> libc.so.6(GLIBC_2.15)(64bit)
> libc.so.6(GLIBC_2.17)(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libc.so.6(GLIBC_2.3)(64bit)
> libc.so.6(GLIBC_2.3.2)(64bit)
> libc.so.6(GLIBC_2.3.4)(64bit)
> libc.so.6(GLIBC_2.4)(64bit)
> libc.so.6(GLIBC_2.6)(64bit)
> libc.so.6(GLIBC_2.7)(64bit)
> libcairo.so.2()(64bit)
> libdl.so.2()(64bit)
> libdl.so.2(GLIBC_2.2.5)(64bit)
> libfreetype.so()(64bit)
> libfreetype.so.6()(64bit)
> libgdk-3.so.0()(64bit)
> libgdk-x11-2.0.so.0()(64bit)
> libgdk_pixbuf-2.0.so.0()(64bit)
> libgio-2.0.so.0()(64bit)
> libglib-2.0.so.0()(64bit)
> libgmodule-2.0.so.0()(64bit)
> libgobject-2.0.so.0()(64bit)
> libgstreamer-lite.so()(64bit)
> libgthread-2.0.so.0()(64bit)
> libgtk-3.so.0()(64bit)
> libgtk-x11-2.0.so.0()(64bit)
> libjava.so()(64bit)
> libjli.so()(64bit)
> libjvm.so()(64bit)
> libjvm.so(SUNWprivate_1.1)(64bit)
> libm.so.6()(64bit)
> libm.so.6(GLIBC_2.15)(64bit)
> libm.so.6(GLIBC_2.2.5)(64bit)
> libnet.so()(64bit)
> libpango-1.0.so.0()(64bit)
> libpangoft2-1.0.so.0()(64bit)
> libpthread.so.0()(64bit)
> libpthread.so.0(GLIBC_2.2.5)(64bit)
> libpthread.so.0(GLIBC_2.3.2)(64bit)
> librt.so.1()(64bit)
> librt.so.1(GLIBC_2.2.5)(64bit)
> libverify.so()(64bit)
> libz.so.1()(64bit)
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> rpmlib(PayloadIsXz) <= 5.2-1
> rtld(GNU_HASH)
> xdg-utils
>

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

It is actually the javafx-web module that requires these.

Anyone know what part of the Web module that needs the libavcodec and
libavcoded-ffmpeg?

We are using a small part of the web module, just WebView for Tooltip with
HTML. No Video or Audio.

/Sverre


ons. 18. sep. 2019 kl. 23:30 skrev Sverre Moe :

> Where does the Requires for libavcodec-ffmpeg and libavcodec.so come from?
> Is it javafx-media which requires these.
>
> The first one of these two requires I cannot find an RPM package for on
> www.rpmfind.net.
>
> Actually we are not using the javafx-media in our application. I could
> remove that jmods, but would be interesting to see what would happen
> without this require while running an media JavaFX application.
>
> /Sverre
>
>
> ons. 18. sep. 2019 kl. 23:20 skrev Sverre Moe :
>
>> It seems many of the RPM Requires comes from me adding the JavaFX jmods
>> to the application image.
>> --add-modules javafx.base javafx.controls javafx.graphics javafx.fxml
>> javafx.media javafx.web javafx.swing
>>
>> Without the JavaFX jmods added to runtime image I get only these Requires.
>>
>> libX11.so.6()(64bit)
>> libXext.so.6()(64bit)
>> libXi.so.6()(64bit)
>> libXrender.so.1()(64bit)
>> libXtst.so.6()(64bit)
>> libasound.so.2()(64bit)
>> libasound.so.2(ALSA_0.9)(64bit)
>> libasound.so.2(ALSA_0.9.0rc4)(64bit)
>> libawt.so()(64bit)
>> libawt_xawt.so()(64bit)
>> libc.so.6()(64bit)
>> libc.so.6(GLIBC_2.2.5)(64bit)
>> libc.so.6(GLIBC_2.3)(64bit)
>> libc.so.6(GLIBC_2.3.2)(64bit)
>> libc.so.6(GLIBC_2.3.4)(64bit)
>> libc.so.6(GLIBC_2.4)(64bit)
>> libc.so.6(GLIBC_2.6)(64bit)
>> libc.so.6(GLIBC_2.7)(64bit)
>> libdl.so.2()(64bit)
>> libdl.so.2(GLIBC_2.2.5)(64bit)
>> libfreetype.so()(64bit)
>> libjava.so()(64bit)
>> libjli.so()(64bit)
>> libjvm.so()(64bit)
>> libjvm.so(SUNWprivate_1.1)(64bit)
>> libm.so.6()(64bit)
>> libm.so.6(GLIBC_2.2.5)(64bit)
>> libnet.so()(64bit)
>> libpthread.so.0()(64bit)
>> libpthread.so.0(GLIBC_2.2.5)(64bit)
>> libpthread.so.0(GLIBC_2.3.2)(64bit)
>> libverify.so()(64bit)
>> libz.so.1()(64bit)
>>
>>
>> /Sverre
>>
>>
>> tir. 17. sep. 2019 kl. 10:25 skrev Sverre Moe :
>>
>>> I have built many times with the new jpackage, but actually just now
>>> tried to install the package built by it.
>>>
>>> The new jpackage adds a lot of Requires to the built RPM package. We had
>>> the same problem with the old javapackager. Its default RPM spec file had a
>>> lot of Requires that made it difficult for us to install our package on
>>> different Linux distributions. We circumvented this by packaging the
>>> application image with the Gradle ospackage plugin for RPM and DEB packages.
>>>
>>> Only the last one of these requires is actually in our RPM spec file
>>> provided with --resource-dir.
>>>
>>> I cannot even install the package on the system I built it, because it
>>> cannot find libavcodec-ffmpeg.so.56
>>> For OpenSUSE Leap 15.1, my Linux distribution there is no package that
>>> provides the libavcodec-ffmpeg.
>>>
>>> Are all these Requires actually necessary for running a JavaFX
>>> application on Linux?
>>> As mentioned we had packaged our JavaFX 8 application with Gradle
>>> ospackage plugin without all these Requires, and it has worked fine on RPM
>>> Linux distributions.
>>>
>>> ld-linux-x86-64.so.2()(64bit)
>>> ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
>>> libGL.so.1()(64bit)
>>> libX11.so.6()(64bit)
>>> libXext.so.6()(64bit)
>>> libXi.so.6()(64bit)
>>> libXrender.so.1()(64bit)
>>> libXtst.so.6()(64bit)
>>> libasound.so.2()(64bit)
>>> libasound.so.2(ALSA_0.9)(64bit)
>>> libasound.so.2(ALSA_0.9.0rc4)(64bit)
>>> libavcodec-ffmpeg.so.56()(64bit)
>>> libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit)
>>> libavcodec.so.54()(64bit)
>>> libavcodec.so.54(LIBAVCODEC_54)(64bit)
>>> libavcodec.so.56()(64bit)
>>> libavcodec.so.56(LIBAVCODEC_56)(64bit)
>>> libavcodec.so.57()(64bit)
>>> libavcodec.so.57(LIBAVCODEC_57)(64bit)
>>> libavformat-ffmpeg.so.56()(64bit)
>>> libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit)
>>> libavformat.so.54()(64bit)
>>> libavformat.so.54(LIBAVFORMAT_54)(64bit)
>>> libavformat.so.56()(64bit)
>>> libavformat.so.56(LIBAVFORMAT_56)(64bit)
>>> libavformat.so.57()(64bit)
>>> libavformat.so.57(LIBAVFORMAT_57)(64bit)
>>> libawt.so()(64bit)
>>> libawt_xawt.so()(64bit)
>>> libc.so.6()(64bit)
>>> libc.so.6(GLIBC_2.11)(64bit)
>>> libc.so.6(GLIBC_2.14)(64bit)
>>> libc.so.6(GLIBC_2.15)(64bit)
>>> libc.so.6(GLIBC_2.17)(64bit)
>>> libc.so.6(GLIBC_2.2.5)(64bit)
>>> libc.so.6(GLIBC_2.3)(64bit)
>>> libc.so.6(GLIBC_2.3.2)(64bit)
>>> libc.so.6(GLIBC_2.3.4)(64bit)
>>> libc.so.6(GLIBC_2.4)(64bit)
>>> libc.so.6(GLIBC_2.6)(64bit)
>>> libc.so.6(GLIBC_2.7)(64bit)
>>> libcairo.so.2()(64bit)
>>> libdl.so.2()(64bit)
>>> libdl.so.2(GLIBC_2.2.5)(64bit)
>>> libfreetype.so()(64bit)
>>> libfreetype.so.6()(64bit)
>>> libgdk-3.so.0()(64bit)
>>> libgdk-x11-2.0.so.0()(64bit)
>>> libgdk_pixbuf-2.0.so.0()(64bit)
>>> libgio-2.0.so.0()(64bit)
>>> libglib-2.0.so.0()(64bit)
>>> libgmodule-2.0.so.0()(64bit)
>>> 

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

Where does the Requires for libavcodec-ffmpeg and libavcodec.so come from?
Is it javafx-media which requires these.

The first one of these two requires I cannot find an RPM package for on
www.rpmfind.net.

Actually we are not using the javafx-media in our application. I could
remove that jmods, but would be interesting to see what would happen
without this require while running an media JavaFX application.

/Sverre


ons. 18. sep. 2019 kl. 23:20 skrev Sverre Moe :

> It seems many of the RPM Requires comes from me adding the JavaFX jmods to
> the application image.
> --add-modules javafx.base javafx.controls javafx.graphics javafx.fxml
> javafx.media javafx.web javafx.swing
>
> Without the JavaFX jmods added to runtime image I get only these Requires.
>
> libX11.so.6()(64bit)
> libXext.so.6()(64bit)
> libXi.so.6()(64bit)
> libXrender.so.1()(64bit)
> libXtst.so.6()(64bit)
> libasound.so.2()(64bit)
> libasound.so.2(ALSA_0.9)(64bit)
> libasound.so.2(ALSA_0.9.0rc4)(64bit)
> libawt.so()(64bit)
> libawt_xawt.so()(64bit)
> libc.so.6()(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libc.so.6(GLIBC_2.3)(64bit)
> libc.so.6(GLIBC_2.3.2)(64bit)
> libc.so.6(GLIBC_2.3.4)(64bit)
> libc.so.6(GLIBC_2.4)(64bit)
> libc.so.6(GLIBC_2.6)(64bit)
> libc.so.6(GLIBC_2.7)(64bit)
> libdl.so.2()(64bit)
> libdl.so.2(GLIBC_2.2.5)(64bit)
> libfreetype.so()(64bit)
> libjava.so()(64bit)
> libjli.so()(64bit)
> libjvm.so()(64bit)
> libjvm.so(SUNWprivate_1.1)(64bit)
> libm.so.6()(64bit)
> libm.so.6(GLIBC_2.2.5)(64bit)
> libnet.so()(64bit)
> libpthread.so.0()(64bit)
> libpthread.so.0(GLIBC_2.2.5)(64bit)
> libpthread.so.0(GLIBC_2.3.2)(64bit)
> libverify.so()(64bit)
> libz.so.1()(64bit)
>
>
> /Sverre
>
>
> tir. 17. sep. 2019 kl. 10:25 skrev Sverre Moe :
>
>> I have built many times with the new jpackage, but actually just now
>> tried to install the package built by it.
>>
>> The new jpackage adds a lot of Requires to the built RPM package. We had
>> the same problem with the old javapackager. Its default RPM spec file had a
>> lot of Requires that made it difficult for us to install our package on
>> different Linux distributions. We circumvented this by packaging the
>> application image with the Gradle ospackage plugin for RPM and DEB packages.
>>
>> Only the last one of these requires is actually in our RPM spec file
>> provided with --resource-dir.
>>
>> I cannot even install the package on the system I built it, because it
>> cannot find libavcodec-ffmpeg.so.56
>> For OpenSUSE Leap 15.1, my Linux distribution there is no package that
>> provides the libavcodec-ffmpeg.
>>
>> Are all these Requires actually necessary for running a JavaFX
>> application on Linux?
>> As mentioned we had packaged our JavaFX 8 application with Gradle
>> ospackage plugin without all these Requires, and it has worked fine on RPM
>> Linux distributions.
>>
>> ld-linux-x86-64.so.2()(64bit)
>> ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
>> libGL.so.1()(64bit)
>> libX11.so.6()(64bit)
>> libXext.so.6()(64bit)
>> libXi.so.6()(64bit)
>> libXrender.so.1()(64bit)
>> libXtst.so.6()(64bit)
>> libasound.so.2()(64bit)
>> libasound.so.2(ALSA_0.9)(64bit)
>> libasound.so.2(ALSA_0.9.0rc4)(64bit)
>> libavcodec-ffmpeg.so.56()(64bit)
>> libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit)
>> libavcodec.so.54()(64bit)
>> libavcodec.so.54(LIBAVCODEC_54)(64bit)
>> libavcodec.so.56()(64bit)
>> libavcodec.so.56(LIBAVCODEC_56)(64bit)
>> libavcodec.so.57()(64bit)
>> libavcodec.so.57(LIBAVCODEC_57)(64bit)
>> libavformat-ffmpeg.so.56()(64bit)
>> libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit)
>> libavformat.so.54()(64bit)
>> libavformat.so.54(LIBAVFORMAT_54)(64bit)
>> libavformat.so.56()(64bit)
>> libavformat.so.56(LIBAVFORMAT_56)(64bit)
>> libavformat.so.57()(64bit)
>> libavformat.so.57(LIBAVFORMAT_57)(64bit)
>> libawt.so()(64bit)
>> libawt_xawt.so()(64bit)
>> libc.so.6()(64bit)
>> libc.so.6(GLIBC_2.11)(64bit)
>> libc.so.6(GLIBC_2.14)(64bit)
>> libc.so.6(GLIBC_2.15)(64bit)
>> libc.so.6(GLIBC_2.17)(64bit)
>> libc.so.6(GLIBC_2.2.5)(64bit)
>> libc.so.6(GLIBC_2.3)(64bit)
>> libc.so.6(GLIBC_2.3.2)(64bit)
>> libc.so.6(GLIBC_2.3.4)(64bit)
>> libc.so.6(GLIBC_2.4)(64bit)
>> libc.so.6(GLIBC_2.6)(64bit)
>> libc.so.6(GLIBC_2.7)(64bit)
>> libcairo.so.2()(64bit)
>> libdl.so.2()(64bit)
>> libdl.so.2(GLIBC_2.2.5)(64bit)
>> libfreetype.so()(64bit)
>> libfreetype.so.6()(64bit)
>> libgdk-3.so.0()(64bit)
>> libgdk-x11-2.0.so.0()(64bit)
>> libgdk_pixbuf-2.0.so.0()(64bit)
>> libgio-2.0.so.0()(64bit)
>> libglib-2.0.so.0()(64bit)
>> libgmodule-2.0.so.0()(64bit)
>> libgobject-2.0.so.0()(64bit)
>> libgstreamer-lite.so()(64bit)
>> libgthread-2.0.so.0()(64bit)
>> libgtk-3.so.0()(64bit)
>> libgtk-x11-2.0.so.0()(64bit)
>> libjava.so()(64bit)
>> libjli.so()(64bit)
>> libjvm.so()(64bit)
>> libjvm.so(SUNWprivate_1.1)(64bit)
>> libm.so.6()(64bit)
>> libm.so.6(GLIBC_2.15)(64bit)
>> libm.so.6(GLIBC_2.2.5)(64bit)
>> libnet.so()(64bit)
>> libpango-1.0.so.0()(64bit)
>> libpangoft2-1.0.so.0()(64bit)
>> libpthread.so.0()(64bit)
>> 

Re: Comments on jpackage (JEP 343)

[Kevin Rushforth]

Hi Phil,

In the app-image case it always creates a new directory with the name of 
the application underneath the dest/output directory for holding all of 
the files. So you either have:


   /appname.ext

or

   /appname/

So I think "." is a reasonable default if not specified.

As to whether to call it "--dest" or "--output", I don't have a strong 
opinion. There are precedents for both.


-- Kevin


On 9/16/2019 8:24 PM, Philip Race wrote:

> but I'd concede it to be "." as a default

On second thoughts I am not sure about that either.
I find it much cleaner to know what was generated by looking in a new 
directory rather than
hunting in my current directory, especially for the default app-image 
case which will dump

a bunch of unfamiliar files.

-phil.

On 9/16/19, 8:13 PM, Philip Race wrote:

I've been thinking about this.
output is nicely symmetrical with input and in the case of a default 
app-image it is more than a single item
and personally I'd much rather it not clutter my working directory 
and again you get symmetry with input
which you really want to specify  but I'd concede it to be "." as a 
default over changing the name to dest ...


There is also precedent :
jlink uses -output and these two tools are going to be frequently 
used together.


So I would like to see the status quo.

-phil.


On 9/3/19, 11:58 AM, mark.reinh...@oracle.com wrote:
   - The `--output`/`-o` option is confusing.  It doesn’t name the 
output
 itself, but rather a directory into which the single item of 
output
 will be placed.  Typing `-o .` all the time is just annoying.  
It’d
 be more logical to rename this option to `--dest`/`-d` and to 
make it

 optional, with a default value of `.`.

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

I have built many times with the new jpackage, but actually just now tried
to install the package built by it.

The new jpackage adds a lot of Requires to the built RPM package. We had
the same problem with the old javapackager. Its default RPM spec file had a
lot of Requires that made it difficult for us to install our package on
different Linux distributions. We circumvented this by packaging the
application image with the Gradle ospackage plugin for RPM and DEB packages.

Only the last one of these requires is actually in our RPM spec file
provided with --resource-dir.

I cannot even install the package on the system I built it, because it
cannot find libavcodec-ffmpeg.so.56
For OpenSUSE Leap 15.1, my Linux distribution there is no package that
provides the libavcodec-ffmpeg.

Are all these Requires actually necessary for running a JavaFX application
on Linux?
As mentioned we had packaged our JavaFX 8 application with Gradle ospackage
plugin without all these Requires, and it has worked fine on RPM Linux
distributions.

ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
libGL.so.1()(64bit)
libX11.so.6()(64bit)
libXext.so.6()(64bit)
libXi.so.6()(64bit)
libXrender.so.1()(64bit)
libXtst.so.6()(64bit)
libasound.so.2()(64bit)
libasound.so.2(ALSA_0.9)(64bit)
libasound.so.2(ALSA_0.9.0rc4)(64bit)
libavcodec-ffmpeg.so.56()(64bit)
libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit)
libavcodec.so.54()(64bit)
libavcodec.so.54(LIBAVCODEC_54)(64bit)
libavcodec.so.56()(64bit)
libavcodec.so.56(LIBAVCODEC_56)(64bit)
libavcodec.so.57()(64bit)
libavcodec.so.57(LIBAVCODEC_57)(64bit)
libavformat-ffmpeg.so.56()(64bit)
libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit)
libavformat.so.54()(64bit)
libavformat.so.54(LIBAVFORMAT_54)(64bit)
libavformat.so.56()(64bit)
libavformat.so.56(LIBAVFORMAT_56)(64bit)
libavformat.so.57()(64bit)
libavformat.so.57(LIBAVFORMAT_57)(64bit)
libawt.so()(64bit)
libawt_xawt.so()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.11)(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.15)(64bit)
libc.so.6(GLIBC_2.17)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.6)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libcairo.so.2()(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libfreetype.so()(64bit)
libfreetype.so.6()(64bit)
libgdk-3.so.0()(64bit)
libgdk-x11-2.0.so.0()(64bit)
libgdk_pixbuf-2.0.so.0()(64bit)
libgio-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgmodule-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libgstreamer-lite.so()(64bit)
libgthread-2.0.so.0()(64bit)
libgtk-3.so.0()(64bit)
libgtk-x11-2.0.so.0()(64bit)
libjava.so()(64bit)
libjli.so()(64bit)
libjvm.so()(64bit)
libjvm.so(SUNWprivate_1.1)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.15)(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libnet.so()(64bit)
libpango-1.0.so.0()(64bit)
libpangoft2-1.0.so.0()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
librt.so.1()(64bit)
librt.so.1(GLIBC_2.2.5)(64bit)
libverify.so()(64bit)
libz.so.1()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)
xdg-utils

Re: Comments on jpackage (JEP 343)

[Philip Race]

> but I'd concede it to be "." as a default

On second thoughts I am not sure about that either.
I find it much cleaner to know what was generated by looking in a new 
directory rather than
hunting in my current directory, especially for the default app-image 
case which will dump

a bunch of unfamiliar files.

-phil.

On 9/16/19, 8:13 PM, Philip Race wrote:

I've been thinking about this.
output is nicely symmetrical with input and in the case of a default 
app-image it is more than a single item
and personally I'd much rather it not clutter my working directory and 
again you get symmetry with input
which you really want to specify  but I'd concede it to be "." as a 
default over changing the name to dest ...


There is also precedent :
jlink uses -output and these two tools are going to be frequently used 
together.


So I would like to see the status quo.

-phil.


On 9/3/19, 11:58 AM, mark.reinh...@oracle.com wrote:
   - The `--output`/`-o` option is confusing.  It doesn’t name the 
output

 itself, but rather a directory into which the single item of output
 will be placed.  Typing `-o .` all the time is just annoying.  It’d
 be more logical to rename this option to `--dest`/`-d` and to 
make it

 optional, with a default value of `.`.

Re: Comments on jpackage (JEP 343)

[Philip Race]

I've been thinking about this.
output is nicely symmetrical with input and in the case of a default 
app-image it is more than a single item
and personally I'd much rather it not clutter my working directory and 
again you get symmetry with input
which you really want to specify  but I'd concede it to be "." as a 
default over changing the name to dest ...


There is also precedent :
jlink uses -output and these two tools are going to be frequently used 
together.


So I would like to see the status quo.

-phil.


On 9/3/19, 11:58 AM, mark.reinh...@oracle.com wrote:

   - The `--output`/`-o` option is confusing.  It doesn’t name the output
 itself, but rather a directory into which the single item of output
 will be placed.  Typing `-o .` all the time is just annoying.  It’d
 be more logical to rename this option to `--dest`/`-d` and to make it
 optional, with a default value of `.`.

Re: Comments on jpackage (JEP 343)

[Philip Race]

Please see https://bugs.openjdk.java.net/browse/JDK-8211182

IIRC there were also concerns that jpackage was not the right place to 
be defining this,
and also I think Andy wrote some boiler plate code that demonstrated it 
was not needed

for at least some of these use cases. Andy (?)

So not being revived soon.

-phil.

On 9/5/19, 2:53 AM, Lennart Börjeson wrote:

Could you please also revive the UserJvmOptionsService, that (for very unclear 
reasons) was removed together with JavaFX?

Since the functionality provided by the UserJvmOptionsService requires some 
cooperation with the launcher created by jpackage, I can't see how I could 
implement some work-around myself.

(I raised this question already in 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059419.html, 
but without response.)

Best regards,

Lennart Börjeson

Re: Comments on jpackage (JEP 343)

[Scott Palmer]

I use a very similar workflow, but I’m building for all platforms. I want the 
image to produce a simple zipped version of the app, and I want all the 
installer/bundles/packages as well. 

I also agree with all of the “would be nice to haves” - Particularly 
service/daemon support. 
I also agree with the recent comments here about getting back the user options 
support and having a way for args in the configure file to stay and be 
augmented by arguments added on the command line by the user. 

Scott

> On Sep 5, 2019, at 8:51 AM, Rachel Greenham  wrote:
> 
> (Sorry for non-threading, i read the digest)
> 
> As you've been lacking feedback from people using the jpackage EA builds, 
> here's mine FWIW.
> 
> I've been quiet because it's been working well enough for us. That said, our 
> needs and process probably simplify matters in that:
> 
> 1. We're only producing Windows installers
> 2. We've been lucky in having patient clients during this post-webstart, 
> post-javapackager disruption.
> 3. We were happy to modify our versioning to match Windows standards
> 4. Our application is non-modular
> 5. We do it in three steps: jlink to make a JRE, then jpackage to make an app 
> image, then jpackage again to make both an exe and msi installer based on 
> that image. (client slow to reply which one they'd actually prefer!) Not 
> trying to do everything in one step.
> 
> Since the fix that made new versions of our app correctly replace older ones 
> I've mostly just been testing new EA builds to make sure they don't break it! 
> They do sometimes, usually because of changes in the parameter names, and of 
> course we lost our Inno Setup customisations. I haven't yet made any attempt 
> to customise the EXE setup installer since then.
> 
> Would be nice:
> 
> 1. For it to use the supplied app icon for the installer, or be able to 
> supply another specifically for the installer. For it to be shown in the 
> installer in some fashion. Other exe customisations of straightforward 
> branding and/or flags to control what questions they're asked would be very 
> nice.
> 2. For it to be able to sign the installer in the fashion of, or actually 
> using, signtool. (Ideally internalised as installing signtool itself is a 
> pain.) Currently that's an extra step after the installers are built
> 
> But I can wait for them, I want it in a release so I can use it via 
> ToolProvider rather than execing an external JDK. All the while it's the way 
> it is it massively complicates the build.
> 
> Later would-be-nices, not for this desktop app, but ability to use it to 
> package background service-type apps, as a service for windows, using launchd 
> for osx, and systemd for linux.
> 
> -- 
> Rachel

Re: Comments on jpackage (JEP 343)

[Alexey Semenyuk]

Hi Rachel,

Thank you for your feedback. I created 
https://bugs.openjdk.java.net/browse/JDK-8230668 record to track work on 
your suggestions.


- Alexey

On 9/5/2019 8:50 AM, Rachel Greenham wrote:

(Sorry for non-threading, i read the digest)

As you've been lacking feedback from people using the jpackage EA 
builds, here's mine FWIW.


I've been quiet because it's been working well enough for us. That 
said, our needs and process probably simplify matters in that:


1. We're only producing Windows installers
2. We've been lucky in having patient clients during this 
post-webstart, post-javapackager disruption.

3. We were happy to modify our versioning to match Windows standards
4. Our application is non-modular
5. We do it in three steps: jlink to make a JRE, then jpackage to make 
an app image, then jpackage again to make both an exe and msi 
installer based on that image. (client slow to reply which one they'd 
actually prefer!) Not trying to do everything in one step.


Since the fix that made new versions of our app correctly replace 
older ones I've mostly just been testing new EA builds to make sure 
they don't break it! They do sometimes, usually because of changes in 
the parameter names, and of course we lost our Inno Setup 
customisations. I haven't yet made any attempt to customise the EXE 
setup installer since then.


Would be nice:

1. For it to use the supplied app icon for the installer, or be able 
to supply another specifically for the installer. For it to be shown 
in the installer in some fashion. Other exe customisations of 
straightforward branding and/or flags to control what questions 
they're asked would be very nice.
2. For it to be able to sign the installer in the fashion of, or 
actually using, signtool. (Ideally internalised as installing signtool 
itself is a pain.) Currently that's an extra step after the installers 
are built


But I can wait for them, I want it in a release so I can use it via 
ToolProvider rather than execing an external JDK. All the while it's 
the way it is it massively complicates the build.


Later would-be-nices, not for this desktop app, but ability to use it 
to package background service-type apps, as a service for windows, 
using launchd for osx, and systemd for linux.

Re: Comments on jpackage (JEP 343)

[Rachel Greenham]

(Sorry for non-threading, i read the digest)

As you've been lacking feedback from people using the jpackage EA 
builds, here's mine FWIW.


I've been quiet because it's been working well enough for us. That said, 
our needs and process probably simplify matters in that:


1. We're only producing Windows installers
2. We've been lucky in having patient clients during this post-webstart, 
post-javapackager disruption.

3. We were happy to modify our versioning to match Windows standards
4. Our application is non-modular
5. We do it in three steps: jlink to make a JRE, then jpackage to make 
an app image, then jpackage again to make both an exe and msi installer 
based on that image. (client slow to reply which one they'd actually 
prefer!) Not trying to do everything in one step.


Since the fix that made new versions of our app correctly replace older 
ones I've mostly just been testing new EA builds to make sure they don't 
break it! They do sometimes, usually because of changes in the parameter 
names, and of course we lost our Inno Setup customisations. I haven't 
yet made any attempt to customise the EXE setup installer since then.


Would be nice:

1. For it to use the supplied app icon for the installer, or be able to 
supply another specifically for the installer. For it to be shown in the 
installer in some fashion. Other exe customisations of straightforward 
branding and/or flags to control what questions they're asked would be 
very nice.
2. For it to be able to sign the installer in the fashion of, or 
actually using, signtool. (Ideally internalised as installing signtool 
itself is a pain.) Currently that's an extra step after the installers 
are built


But I can wait for them, I want it in a release so I can use it via 
ToolProvider rather than execing an external JDK. All the while it's the 
way it is it massively complicates the build.


Later would-be-nices, not for this desktop app, but ability to use it to 
package background service-type apps, as a service for windows, using 
launchd for osx, and systemd for linux.


--
Rachel

Re: Comments on jpackage (JEP 343)

[Andy Herrick]

Thank you very much for the detailed feedback.

see inline for Change Requests created or associated with each point .

/Andy

On 9/3/2019 2:58 PM, mark.reinh...@oracle.com wrote:

I spent some time last week playing with the jpackage tool, using build
14-jpackage+1-35 from https://jdk.java.net/jpackage.

Overall, I can see that you’ve made good progress, but there’s still some
work to be done.  I’ll start with high-level comments and questions, and
then comment on my experience using the tool on Debian and then macOS.

High-level comments/questions

   - It’s good that you’re publishing EA builds, but I haven’t seen very
 much feedback from those builds.  It may be better to propose this as
 an experimental feature when it’s ready to target.  That would give
 you the freedom to improve it incompatibly over one or two release
 cycles before you commit to a final version.


We like the suggestion to release as an experimental feature.

see: JDK-8230649 



   - The tool still generates an image by default, rather than a package.
 This will surprise many users, especially those who just want to do
 something simple and straightforward.  The least-surprising default
 behavior would be to generate a package of the type most suitable for
 the current platform.  An option to generate just an image would be
 fine, for those who want to tweak it before the actual packaging
 step, but that shouldn’t be the default.

   - Related to the previous point, I should only have to specify the
 `--package-type` option if I want something other than the default
 for the current platform.


We will add "app-image" as an explicit type and change the 
--package-type default to be type most suitable for the current platform.


see: JDK-8230519 



   - The tool assumes that the application being packaged will have a GUI.
 This isn’t surprising, considering its heritage, but as a consequence
 it always produces packages that perform GUI-specific actions, such
 as installing icons and desktop-menu entries.  If I’m just packaging
 a command-line tool then these are unnecessary, and supporting them
 can pull in lots of additional dependencies (e.g., a ton of Perl
 scripts on Debian).  Consider adding an option (`--gui`?) so that
 the user can indicate when an application is to be installed for
 graphical use.


For giving the developer the control of shortcuts we have created : 
JDK-8229779 


If an application does not request shortcut(s) there should be no need 
for gui code.


   - The `--output`/`-o` option is confusing.  It doesn’t name the output
 itself, but rather a directory into which the single item of output
 will be placed.  Typing `-o .` all the time is just annoying.  It’d
 be more logical to rename this option to `--dest`/`-d` and to make it
 optional, with a default value of `.`.


We will change name of option and default as suggested

see: JDK-8230521 



   - If my app is modular, and my main module has a version string, then
 it’d be nice for that to be used as the package version unless a
 specific version is specified on the command line.

see: JDK-8230651 

   - Terminology: For Linux we generally speak of “packages” rather than
 “bundles.”  Rename `--linux-bundle-name` to `--linux-package-name`.
this will be fixed as part of: JDK-8230522 



   - The `--temp-root` option could be shortened to `--temp`.

see: JDK-8230522 


   - Periods at the ends of error messages are unsightly and unnecessary.
 We don’t use them in other JDK tools.  Please remove them.
This is also included in: JDK-8230522 



   - It’d be nice to have an option that displays the programs being run
 by the tool, in a form that can easily be cut-and-pasted into a
 script for those who need to do a lot of customization.  The current
 verbose output shows (at least some of) this information, but in a
 difficult-to-use format.

see:JDK-8230652 


   - What’s the rationale for copying the entire “input” directory as-is?
 Why is its structure important?  Couldn’t you just as well limit this
 to a single directory full of JAR files?
After discussion , I will look for use case where this existing behavior 
is desirable.


Comments on Debian packaging


All of the below comments on Debian packaging  are reflected in 
JDK-8230507 


They may or may not be split up into individual CR's as they are addressed.

Re: Comments on jpackage (JEP 343)

[Lennart Börjeson]

Could you please also revive the UserJvmOptionsService, that (for very unclear 
reasons) was removed together with JavaFX?

Since the functionality provided by the UserJvmOptionsService requires some 
cooperation with the launcher created by jpackage, I can't see how I could 
implement some work-around myself.

(I raised this question already in 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059419.html, 
but without response.)

Best regards,

Lennart Börjeson

Re: Comments on jpackage (JEP 343)

[Alexey Semenyuk]

Hi Sverre,

Thank you for your feedback.

I've filed [1] bug to address Debian packaging issue.

As for your question regarding release number, it is not supported by 
WiX on Windows. See [2].
Also product version string should follow quite strict rules [3]. 
However you can encode release value in the third component of product 
version (build number) as a workaround on condition release is a number.


[1] https://bugs.openjdk.java.net/browse/JDK-8230612
[2] https://wixtoolset.org/documentation/manual/v3/xsd/wix/product.html
[3] https://docs.microsoft.com/en-us/windows/win32/msi/productversion

- Alexey

On 9/4/2019 5:53 AM, Sverre Moe wrote:

I tired the latest build 14-jpackage+1-35 today. Good to see that debian
package file name is finally up to the specification.

Noticed something though with building the debian package:
When using a control file from the resource directory, jpackage does not
use its version and release.
Must apply "--app-version" and "--linux-app-release" in order to get the
proper version and release on file name.

Running dpkg-deb --show and --info has the correct version and release.
   dpkg-deb --show build/deb/application_1.0-1_amd64.deb
   application 1.1.0-SNAPSHOT20190904113134

I wonder where it gets the version 1.0 from, since my
project.version=1.1.0. The jpackage should at least use the project version
if no other version is specified.

This is a problem only for the debian package on Linux. When building an
RPM, jpackage uses both the Version and Release defined within the spec
resource file.

Isn't release also applicable for Windows and Mac?
What about, instead of calling it "--linux-app-release", why not simply
call it "--app-release". That would stand much better together with
"--app-version".
With "--linux-app-release" it makes it more more verbose when scripting the
build, when it needs to check for Windows and Mac in order to omit that
flag.

/Sverre


tir. 3. sep. 2019 kl. 21:01 skrev :


I spent some time last week playing with the jpackage tool, using build
14-jpackage+1-35 from https://jdk.java.net/jpackage.

Overall, I can see that you’ve made good progress, but there’s still some
work to be done.  I’ll start with high-level comments and questions, and
then comment on my experience using the tool on Debian and then macOS.

High-level comments/questions

   - It’s good that you’re publishing EA builds, but I haven’t seen very
 much feedback from those builds.  It may be better to propose this as
 an experimental feature when it’s ready to target.  That would give
 you the freedom to improve it incompatibly over one or two release
 cycles before you commit to a final version.

   - The tool still generates an image by default, rather than a package.
 This will surprise many users, especially those who just want to do
 something simple and straightforward.  The least-surprising default
 behavior would be to generate a package of the type most suitable for
 the current platform.  An option to generate just an image would be
 fine, for those who want to tweak it before the actual packaging
 step, but that shouldn’t be the default.

   - Related to the previous point, I should only have to specify the
 `--package-type` option if I want something other than the default
 for the current platform.

   - The tool assumes that the application being packaged will have a GUI.
 This isn’t surprising, considering its heritage, but as a consequence
 it always produces packages that perform GUI-specific actions, such
 as installing icons and desktop-menu entries.  If I’m just packaging
 a command-line tool then these are unnecessary, and supporting them
 can pull in lots of additional dependencies (e.g., a ton of Perl
 scripts on Debian).  Consider adding an option (`--gui`?) so that
 the user can indicate when an application is to be installed for
 graphical use.

   - The `--output`/`-o` option is confusing.  It doesn’t name the output
 itself, but rather a directory into which the single item of output
 will be placed.  Typing `-o .` all the time is just annoying.  It’d
 be more logical to rename this option to `--dest`/`-d` and to make it
 optional, with a default value of `.`.

   - If my app is modular, and my main module has a version string, then
 it’d be nice for that to be used as the package version unless a
 specific version is specified on the command line.

   - Terminology: For Linux we generally speak of “packages” rather than
 “bundles.”  Rename `--linux-bundle-name` to `--linux-package-name`.

   - The `--temp-root` option could be shortened to `--temp`.

   - Periods at the ends of error messages are unsightly and unnecessary.
 We don’t use them in other JDK tools.  Please remove them.

   - It’d be nice to have an option that displays the programs being run
 by the tool, in a form that can easily be cut-and-pasted into a
 script for 

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

I tired the latest build 14-jpackage+1-35 today. Good to see that debian
package file name is finally up to the specification.

Noticed something though with building the debian package:
When using a control file from the resource directory, jpackage does not
use its version and release.
Must apply "--app-version" and "--linux-app-release" in order to get the
proper version and release on file name.

Running dpkg-deb --show and --info has the correct version and release.
  dpkg-deb --show build/deb/application_1.0-1_amd64.deb
  application 1.1.0-SNAPSHOT20190904113134

I wonder where it gets the version 1.0 from, since my
project.version=1.1.0. The jpackage should at least use the project version
if no other version is specified.

This is a problem only for the debian package on Linux. When building an
RPM, jpackage uses both the Version and Release defined within the spec
resource file.

Isn't release also applicable for Windows and Mac?
What about, instead of calling it "--linux-app-release", why not simply
call it "--app-release". That would stand much better together with
"--app-version".
With "--linux-app-release" it makes it more more verbose when scripting the
build, when it needs to check for Windows and Mac in order to omit that
flag.

/Sverre


tir. 3. sep. 2019 kl. 21:01 skrev :

> I spent some time last week playing with the jpackage tool, using build
> 14-jpackage+1-35 from https://jdk.java.net/jpackage.
>
> Overall, I can see that you’ve made good progress, but there’s still some
> work to be done.  I’ll start with high-level comments and questions, and
> then comment on my experience using the tool on Debian and then macOS.
>
> High-level comments/questions
>
>   - It’s good that you’re publishing EA builds, but I haven’t seen very
> much feedback from those builds.  It may be better to propose this as
> an experimental feature when it’s ready to target.  That would give
> you the freedom to improve it incompatibly over one or two release
> cycles before you commit to a final version.
>
>   - The tool still generates an image by default, rather than a package.
> This will surprise many users, especially those who just want to do
> something simple and straightforward.  The least-surprising default
> behavior would be to generate a package of the type most suitable for
> the current platform.  An option to generate just an image would be
> fine, for those who want to tweak it before the actual packaging
> step, but that shouldn’t be the default.
>
>   - Related to the previous point, I should only have to specify the
> `--package-type` option if I want something other than the default
> for the current platform.
>
>   - The tool assumes that the application being packaged will have a GUI.
> This isn’t surprising, considering its heritage, but as a consequence
> it always produces packages that perform GUI-specific actions, such
> as installing icons and desktop-menu entries.  If I’m just packaging
> a command-line tool then these are unnecessary, and supporting them
> can pull in lots of additional dependencies (e.g., a ton of Perl
> scripts on Debian).  Consider adding an option (`--gui`?) so that
> the user can indicate when an application is to be installed for
> graphical use.
>
>   - The `--output`/`-o` option is confusing.  It doesn’t name the output
> itself, but rather a directory into which the single item of output
> will be placed.  Typing `-o .` all the time is just annoying.  It’d
> be more logical to rename this option to `--dest`/`-d` and to make it
> optional, with a default value of `.`.
>
>   - If my app is modular, and my main module has a version string, then
> it’d be nice for that to be used as the package version unless a
> specific version is specified on the command line.
>
>   - Terminology: For Linux we generally speak of “packages” rather than
> “bundles.”  Rename `--linux-bundle-name` to `--linux-package-name`.
>
>   - The `--temp-root` option could be shortened to `--temp`.
>
>   - Periods at the ends of error messages are unsightly and unnecessary.
> We don’t use them in other JDK tools.  Please remove them.
>
>   - It’d be nice to have an option that displays the programs being run
> by the tool, in a form that can easily be cut-and-pasted into a
> script for those who need to do a lot of customization.  The current
> verbose output shows (at least some of) this information, but in a
> difficult-to-use format.
>
>   - What’s the rationale for copying the entire “input” directory as-is?
> Why is its structure important?  Couldn’t you just as well limit this
> to a single directory full of JAR files?
>
> Comments on Debian packaging
>
>   - On a Debian machine I tried to create a package for a trivial,
> two-module application using the command
>
>   $ jpackage -o . --package-type deb -p lib -m org.openjdk.hello -n
>