RFR: JDK-8230920: jpackage problems when -input dir contains any files with "cfg" extension.
andy.herrick at oracle.com
Tue Sep 17 20:24:28 UTC 2019
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  at .
>> 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.
> - Alexey
>>  https://bugs.openjdk.java.net/browse/JDK-8230920
>>  http://cr.openjdk.java.net/~herrick/8230920
More information about the core-libs-dev