RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
andy.herrick at oracle.com
Tue Oct 30 20:54:53 UTC 2018
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
>>> 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.
>> 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
> 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.
>> 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.
>> 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.
More information about the core-libs-dev