RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

[Andy Herrick]

On 10/30/2018 10:11 AM, Andy Herrick wrote:
>
>
> On 10/24/2018 10:22 AM, Alan Bateman wrote:
>> On 23/10/2018 16:49, Andy Herrick wrote:
>>> This patch implements the Java Packager Tool (jpackager) as 
>>> described in JEP 343: Packaging Tool 
>>> <https://bugs.openjdk.java.net/browse/JDK-8200758>
>>>
>>> jpackager is a simple packaging tool, based on the JavaFX 
>>> |javapackager| tool, that:
>>>
>>>  * Supports native packaging formats to give the end user a natural
>>>    installation experience. These formats include |msi| and |exe| on
>>>    Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux.
>>>  * Allows launch-time parameters to be specified at packaging time.
>>>  * Can be invoked directly, from the command line, or programmatically,
>>>    via the |ToolProvider| API.
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~herrick/8212780/webrev.01/
>>>
>> cc'ing build-dev as it's important to get it reviewed there.
>>
>> What is the plan for tests to go with this tool? I see there is one 
>> test in the webrev to do some argument validation but I don't see 
>> anything else right now.
> We plan to incorporate the initial feedback from this review, and 
> include an initial set of automated tests in a refresh sometime next 
> week.
> We will continue to develop and automate tests for future updates.
>>
>> What is the status of the JNLPConverter tool? I see it is included as 
>> a "demo" but maybe it would be better to host somewhere else as this 
>> is for developers migrating Java Web Start applications.
> Our current plan is to deliver it only as a demo.
After further discussion, we have decided to remove the JNLPConversion 
tool , and find another home for it.

/Andy

>>
>> Would it be possible to update the JEP with all the CLI options? That 
>> would be useful for review and also useful for those invoking it with 
>> the ToolProvider API.
> Done.
>>
>> If I read the webrev correctly then it adds two modules, one with the 
>> jpackager tool and the other with an API. It would be useful to get a 
>> bit more information on the split. Also I think the name of the API 
>> module and the package that it exports needs discussion to make sure 
>> that the right names are chosen.
> Yes - though we are currently using jdk.packager.services, we are open 
> to other suggestions as the name for these. "jdk.packager.runtime" has 
> also been suggested.
>>
>> -Alan
> /Andy