RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
kevin.rushforth at oracle.com
Tue Oct 30 16:29:55 UTC 2018
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
More information about the core-libs-dev