On 9/17/2019 3:51 PM, Alexey Semenyuk wrote:
On 9/17/2019 3:17 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
On Windows when building MSI, the original application name was
determined by looking into the /app dir for a ".cfg" file.
The problem was that:
- There may be application files with ".cfg" extension.
- There may be multiple ".cfg" files due to --add-launcher option(s)
Instead we create an "<application name>.id" in the root of the
app-image , to insure we can derive application name from app-image.
`<application name>.id` will be another well known file. Why it is
better than `app/<application name>.cfg`? Because there can be
multiple `app/<application name>.cfg` files and only a single
`<application name>.id`? What will prevent people from creating their
own .id files?
because any file created by user will be in app directory, not in root.
I don't like this solution, to be honest. Its only benefit is that it
is simple. Can we instead put some data in `app/<application
name>.cfg` file for the main launcher when building app image so that
bundle packagers can read all .cfg files and find the one that
corresponds to the main launcher and thus get application name?
I began implementing it this way, adding an app.isMain=true or
app.isMain=false entry in each cfg file (at least those generated by
us). That made it far more complicated. Just to determine the
application name required reading and parsing all the cfg files. There
is currently no other reason for the bundling code to ever read these
files, so I reverted to this simpler solution.
/Andy
- Alexey
[1] https://bugs.openjdk.java.net/browse/JDK-8230920
[2] http://cr.openjdk.java.net/~herrick/8230920
Thanks
Andy,
