Path resolution causes bundled jre to not be found on linux when building from windows

[keastrid]

I'm submitting a…

• bug report
• feature request
• other

Short description of the issue/suggestion:
When building a .deb for linux on windows, the jre ends up split into 2 pieces as the windows drive letter is prepended to the path, causing the launch script to fail to run.

I believe this is caused by the fix for #302, where the installation path is resolved as an absolute path first.

Steps to reproduce the issue/enhancement:

1. Build a deb on windows with bundled jre
2. install deb on linux
3. attempt to run (it will say the app is not installed, if you inspect the install location and attempt to run manually from there it say it cannot find the bundled jre)

What is the expected behavior?
Have the app run and not to include window's paths.

What is the current behavior?
App cannot run, installation succeeds but attempting to run the app will result in No such file or directory error.

Do you have outputs, screenshots, demos or samples which demonstrate the problem or enhancement?
As a test, I changed the 2 appPath.getAbsolutePath() to appPath.toPath().normalize().toString() (not sure if normalizing is what you were aiming for with the absolute path call), and this build and install succeeded, though I am using the default installation location.

What is the motivation / use case for changing the behavior?
Ability to build for linux from windows

Please tell us about your environment:

• JavaPackager version: 1.7.5
• OS version: Windows 10
• JDK version: 21
• Build tool:
  • Maven
  • Gradle

Other information (e.g. related issues, suggestions how to fix, links for us to have context)

[EasyG0ing1]

@keastrid

I've always built apps for a given OS on the OS that it needs to be built for. I leverage virtual machines with a build setup (JDK, Maven etc.) installed on the VM so I can just copy the project folder over to the other OS and build the final artifact. I'm not sure if cross-platform building is supported by JavaPackager, but I might be wrong about that.

[keastrid]

Crossplatform building has worked for all cases (except installer generation on some platforms, as those need specific tools) before, also evidenced by the ability to set the target platform for the packaging to be different from the current platform.

[fvarrui]

Hi @keastrid!
I've managed to reproduce your issue with 1.7.6-SNAPSHOT .... it seems that it only was tested on Linux, sorry! 😓
Just fixed in RPM and DEB generation and released a snapshot version: 1.7.6-20240623.184536-11
Please, test it and give me some feedback.
Thanks!

[keastrid]

That seems to work, thanks!

[chengjieFENG]

I found a similar problem with installationPath of linuxConfig. Like this problem, the generated address includes the name of the drive,When I set the address of installationPath it generates an address with the name of the drive

[fvarrui]

I found a similar problem with installationPath of linuxConfig. Like this problem, the generated address includes the name of the drive,When I set the address of installationPath it generates an address with the name of the drive

Hi @chengjieFENG!
Have you tried with 1.7.6-20240623.184536-11 snapshot version?

[chengjieFENG]

I found a similar problem with installationPath of linuxConfig. Like this problem, the generated address includes the name of the drive,When I set the address of installationPath it generates an address with the name of the drive

Hi @chengjieFENG! Have you tried with 1.7.6-20240623.184536-11 snapshot version?

Yes, I used this snapshot version and it was fixed when I didn't set the installtionPath. After I set the installationPath, it looked like it was before it was fixed

[keastrid]

I've done a clean rebuild (deleted cached files, uninstalled the app from linux) just to confirm the snapshot works, and I might have found an issue (or I've done something wrong, I don't use linux very often).

I can confirm the generated deb has the correct internal structure (though I did not test with installPath set to something); however, now when I install the app and try to run it it reports "command not found."

Running the path to the application under /opt (/opt/AstroImageJ/AstroImageJ) does work, but running from /usr (/usr/local/bin/AstroImageJ) does not work. Even though the file is there, it reports the file is not found and opening the file it appears to be empty. The deb seems to have the /usr as a symlink to the /opt version.

[fvarrui]

I think I'm going to change linuxConfig.installationPath from File to String to avoid these cross-platform issues and do some more exhaustive tests.

[fvarrui]

I think I'm going to change linuxConfig.installationPath from File to String to avoid these cross-platform issues and do some more exhaustive tests.

I just released a new snapshot version with this change: 1.7.6-20240629.194647-13. I tested the DEB package on Ubuntu and the RPM package on openSUSE (building both packages from Windows), leaving linuxConfig.installationPath at its default value (/opt) and also setting linuxConfig.installationPath=/usr/local, working fine on all cases.

Please, test this version and give me some feedback, so I can publish 1.7.6 on Maven Central ASAP.

[keastrid]

I gave it a test, and it still seems to fail for me. I have uploaded the built deb here in case it is useful.

I have probably done something wrong, in which case sorry for the trouble!

[fvarrui]

Hi @keastrid!
I installed your DEB package and all worked fine ... remember that Linux is case sensitive so your binary file is AstroImageJ instead of astroimagej

[fvarrui]

Branch issue-419 merged into devel, ready to be released to Maven Central.
Thanks for your contributions!

[fvarrui]

v1.7.6 released to Maven Central

[keastrid]

Ugh, sorry about that. Could have sworn lowercase had worked before... Thanks for the help!