Yes. I talked to a coworker and realized I glossed over that part. We run 
jpackage to create an application image and then use InstallBuilder to create 
an installer. We have 6 Java applications and dozens of C++ applications that 
all go into one big installer.

Andrew

-----Original Message-----
From: Alexey Semenyuk <alexey.semen...@oracle.com> 
Sent: Thursday, March 5, 2020 2:03 PM
To: Auclair, Andrew <aaucl...@curtisswright.com>; core-libs-dev@openjdk.java.net
Subject: Re: jpackage Linux rpath [EXTERNAL]

Andrew,

Thank you for sharing!
As far as I can see you use jpackage to create application image. I think your 
solution is optimal for this scenario.

- Alexey

On 3/5/2020 1:57 PM, Auclair, Andrew wrote:
> Hi Alexey,
>
> Thanks for the response! I think we will continue to do what we're doing now 
> because it works just fine and is pretty simple.
>
> If anyone d is interested, this is how we do it: We run everything through a 
> doLast in our build.gradle file and run an exec {} for jpackage and then if 
> we're on linux we run another exec {} for patchelf.
>
> exec {
>      def icon
>      executable "${System.env.JAVA_HOME}/bin/jpackage"
>      if (OperatingSystem.current().isLinux()) {
>          icon = "Example.png"
>      }
>      else {
>          icon = " Example.ico"
>      }
>      args = ["--type", "app-image", "--icon", icon, "--input", 
> "build/libs", "--dest", "build/install/tmp", "--name", " Example ", 
> "--main-class", "com.example", "--main-jar", " Example.jar"] } if 
> (OperatingSystem.current().isLinux()) {
>      exec {
>          executable "patchelf"
>          args = ["--force-rpath", "--set-rpath", "\$ORIGIN", 
> "../build/install/Example "]
>      }
> }
>
> Thanks Again,
> Andrew
>
> -----Original Message-----
> From: Alexey Semenyuk <alexey.semen...@oracle.com>
> Sent: Thursday, March 5, 2020 1:51 PM
> To: Auclair, Andrew <aaucl...@curtisswright.com>; 
> core-libs-dev@openjdk.java.net
> Subject: Re: jpackage Linux rpath [EXTERNAL]
>
> Hi Andrew,
>
> jpackage is providing similar functionality as javapackager, so I think you 
> need to keep using patchelf with jpackage as you used it with javapackager.
> I assume you use jpackage in two phases. The first phase creates application 
> image and you use patchelf on launchers created by jpackage and then in the 
> second phase you pack application image with modified launchers into rpm/deb 
> package.
> If this is the case and you would benefit from running jpackage in one phase, 
> then I can think of adding to jpackage ability to run 3rd party script after 
> application image creation. In this case you will need to create shell script 
> using patchelf, place the script in resource directory so that jpackage can 
> run the script after application image is created but before building rpm/deb 
> package.
>
> - Alexey
>
> On 3/5/2020 9:42 AM, Auclair, Andrew wrote:
>> Hi,
>>
>> We are in the process of upgrading to jpackage in Java 14 from javapackager 
>> in Java 10. So far the transition has been smooth and we're really liking 
>> jpackage.
>>
>> One question has come up regarding our Linux install. Currently we are using 
>> Patchelf on CentOS to set an rpath for the executables generated by 
>> javapackager. We have continued this with jpackage, but we were wondering if 
>> there's a way to set the rpath with jpackage to avoid using Patchelf.
>>
>> Thanks,
>>
>> Andrew Auclair
>> Software Engineer
>> Tactical Communications Group
>> A Curtiss-Wright Company
>> 2 Highwood Drive, Building 2, Suite 200 Tewksbury, MA  01876-1157
>>
>> ---------------------------------------------------------------------
>> - This e-mail and any files transmitted with it are proprietary and 
>> intended solely for the use of the individual or entity to whom they are 
>> addressed. If you have reason to believe that you have received this e-mail 
>> in error, please notify the sender and destroy this e-mail and any attached 
>> files. Please note that any views or opinions presented in this e-mail are 
>> solely those of the author and do not necessarily represent those of the 
>> Curtiss-Wright Corporation or any of its subsidiaries. Documents attached 
>> hereto may contain technology subject to the U.S. Export Regulations. 
>> Recipient is solely responsible for ensuring that any re-export, transfer or 
>> disclosure of this information is in accordance with U.S. Export 
>> Regulations. The recipient should check this e-mail and any attachments for 
>> the presence of viruses. Curtiss-Wright Corporation and its subsidiaries 
>> accept no liability for any damage caused by any virus transmitted by this 
>> e-mail.
>
> ----------------------------------------------------------------------
> This e-mail and any files transmitted with it are proprietary and intended 
> solely for the use of the individual or entity to whom they are addressed. If 
> you have reason to believe that you have received this e-mail in error, 
> please notify the sender and destroy this e-mail and any attached files. 
> Please note that any views or opinions presented in this e-mail are solely 
> those of the author and do not necessarily represent those of the 
> Curtiss-Wright Corporation or any of its subsidiaries. Documents attached 
> hereto may contain technology subject to the U.S. Export Regulations. 
> Recipient is solely responsible for ensuring that any re-export, transfer or 
> disclosure of this information is in accordance with U.S. Export Regulations. 
> The recipient should check this e-mail and any attachments for the presence 
> of viruses. Curtiss-Wright Corporation and its subsidiaries accept no 
> liability for any damage caused by any virus transmitted by this e-mail.


----------------------------------------------------------------------
This e-mail and any files transmitted with it are proprietary and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have reason to believe that you have received this e-mail in error, please 
notify the sender and destroy this e-mail and any attached files. Please note 
that any views or opinions presented in this e-mail are solely those of the 
author and do not necessarily represent those of the Curtiss-Wright Corporation 
or any of its subsidiaries. Documents attached hereto may contain technology 
subject to the U.S. Export Regulations. Recipient is solely responsible for 
ensuring that any re-export, transfer or disclosure of this information is in 
accordance with U.S. Export Regulations. The recipient should check this e-mail 
and any attachments for the presence of viruses. Curtiss-Wright Corporation and 
its subsidiaries accept no liability for any damage caused by any virus 
transmitted by this e-mail.

Reply via email to