JPackage application image file system layout
r.lichtenberger at gmail.com
Wed Jul 3 06:08:22 UTC 2019
I just noticed that my last reply was addressed to Scott Palmer only, so
I "repost" my latest thougths now:
Am 01.07.19 um 16:50 schrieb Scott Palmer:
>> On Jul 1, 2019, at 2:47 AM, Robert Lichtenberger <r.lichtenberger at gmail.com> wrote:
>> While trying to update our application to the (ea-version of) jpackager I
>> noticed that the executable files are now in a bin/ subdirectory, which
>> will make the application update from javapackager a real pain.
>> For Linux this can be argumented with the Filesystem Hierarchy Standard but
>> under Windows it is not common or standard to do so. The .exe file for an
>> application is expected to live in the base installation directory.
> It can also be argued that on Windows it is more common to launch the application from a shortcut in the Start menu, on the Desktop, or in the launch bar.
> I get that this is a change from the previous behaviour so some adjustments need to be made, but how bad is it really?
For me, right now, it is a showstopper.
I have to update my application silently, in-place. If jpackage isn't
adapted I'll have to resort to crude hacks like a "trampoline"
<name>.exe - File which will call bin/<name>.exe when it's called and/or
adapting existing .lnk - Files on the Windows machine (which will
probably look very suspicious to anti-malware solutions ...).
> The JDK has always had a bin directory and many other applications follow this pattern on Windows as well.
Usually these are applications ported from Linux/Unix. But I admit
there's no real standard or de-facto-standard about it. It's just the
fact that javapackager used to work this way and now jpackage works that
way, which makes it difficult in some situations.
I've digged into the jpackage source code yesterday and was able to
adapt LinuxAppImageBuilder.java and LinuxPlatform.cpp so that they would
no longer use the bin/ subdirectory and from a cursory look it seems
this could be done for Windows as well. Of course this would have to be
tested and checked much more.
To me it looks like there are three possible solutions:
a) Everything stays as it is now. Things will remain difficult for me
(and possibly for other people)
b) We change Windows so as to not use the bin/ subdirectory.
c) We add another config-option that will control whether or not to use
the bin/ subdirectory
I would be willing to invest time in a patch for b) or c) but only if
someone with authority (Andy Herrick?) tells me, this makes sense.
More information about the core-libs-dev