RFR: JDK-8230920: jpackage problems when -input dir contains any files with "cfg" extension.

[Andy Herrick]

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,
>>
>