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

[Kevin Rushforth]

inline

On 10/30/2018 9:09 AM, Alan Bateman wrote:
> On 30/10/2018 14:11, Andy Herrick wrote:
>
>> :
>>>
>>> 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.
> Alex has suggested jdk.jpackager to avoid giving the impression that 
> it's the "JDK packager". Also several existing tool modules have the 
> tool name in the module name (jdk.jdeps, jdk.jlink, jdk.jshell, ...).

Yes, I think jdk.jpackager is a fine name for this module.

> Is the API to ensure that only one instance of the application is 
> running really tied to the jpackager tool? Could it be used by 
> applications that aren't packaged in with this tool? I'm asking in 
> case there is a better name for this API module.

In its current form it is tied to jpackager. Andy might be able to 
comment on how tightly-coupled it is, and what it would take to 
generalize it, but that wasn't a goal to make it usable for apps that 
aren't packaged using jpackager. Other things that will likely go into 
this runtime support module in the future:

* Service daemon support
* User JVM args support

-- Kevin