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

[Philip Race]

   74
   75     static String getTmpDir() {
   76         String os = System.getProperty("os.name").toLowerCase();
   77         if (os.contains("win")) {
   78             return System.getProperty("user.home")
   79                     + "\\AppData\\LocalLow\\Sun\\Java\\JPackager\\tmp";
   80         } else if (os.contains("mac") || os.contains("os x")) {
   81             return System.getProperty("user.home")
   82                     + "/Library/Application Support/Oracle/Java/JPackager/tmp";
   83         } else if (os.contains("nix") || os.contains("nux")
   84                 || os.contains("aix")) {
   85             return System.getProperty("user.home") + "/.java/jpackager/tmp";
   86         }
   87
   88         return System.getProperty("java.io.tmpdir");


This seems unduly complex, and I don't understand the implication of
supporting AIX .. or some unknown "Unix", when packager is targeted
only at mac, linux + windows.

I think its sufficient to look for the strings windows, macos and linux.
And if you want a persistent storage location then default to the "unix"
location if there's no match .. although I am not sure it makes sense
on platforms that aren't targeted by jpackager.

-phil.
>
> -phil.
>
> On 11/12/18, 12:22 PM, Philip Race wrote:
>> Adding build-dev back ..
>>
>> I noticed that module jdk.jpackager.runtime requires java.desktop on 
>> all platforms
>>
>> So far as I can tell this is for a Mac-only support for receiving and
>> handling file open events. Probably it only makes sense or gets used
>> when the API is used from a running desktop application.
>>
>> I might ask if we need this at all, but I definitely think it should
>> not be required on all platforms if needed only for Mac even if
>> we might want it on windows in a future version.
>>
>> Do we not envisage cases where you need the runtime API for
>> some kind of daemon service for which there should be a singleton ?
>> Do you really want to force the desktop module to be dragged along
>> in such a case ?
>>
>> I think we should remove this dependency even if it means losing a
>> MacOS feature at least for now.
>>
>> -phil.
>>
>> On 11/11/18, 2:40 PM, Andy Herrick wrote:
>>> On 11/9/2018 5:25 PM, Andy Herrick wrote:
>>>> This is an update to the Request For Review of the implementation 
>>>> of the Java Packager Tool (jpackager) as described in JEP 343: 
>>>> Packaging Tool <https://bugs.openjdk.java.net/browse/JDK-8200758>
>>>>
>>>> This refresh renames the packages used to jdk.jpackager and 
>>>> jdk.jpackager.runtime, removes the JNLPConverter demo, adds an 
>>>> initial set of automated tests, and contains fixes to the following 
>>>> issues:
>>>>
>>>> JDK-8213324 jpackager deletes existing app directory without warning
>>>> JDK-8213166 jpackager --argument arg is broken
>>>> JDK-8213163 --app-image arg does not work creating exe installers
>>>> JDK-8212089 Prepare packager for localization
>>>> JDK-8212537 Create method and class description comments for main 
>>>> functionality
>>>> JDK-8213332 Create minimal automated tests for jpackager
>>>> JDK-8213333 Fix issues found in jpackager with automated tests
>>>> JDK-8213394 Stop using Log.info() except for expected output.
>>>> JDK-8213345 Secondary Launchers broken on mac.
>>>> JDK-8213156 rename packages for jpackager
>>>> JDK-8213244 Fix all warnings in jpackager java code
>>>> JDK-8212143 Remove native code that supports UserJvmOptionsService
>>>> JDK-8213162 Association description in Inno Setup cannot contain 
>>>> double quotes
>>>>
>>>> The following additional issues are targeted to be address in the 
>>>> next few weeks:
>>>> JDK-8212936     Makefile and other improvements for jpackager
>>>> JDK-8212164     resolve jre.list and jre.module.list
>>>> JDK-8213392     Enhance --help and --version
>>>> JDK-8208652     File name is not passed to main() via file 
>>>> association on OS X
>>>> JDK-8212538     Determine standard way to determine if a Modular jar
>>>> JDK-8213558     Create more unit tests
>>> Note: The above issues are targeted to 'internal' - meaning we 
>>> expect to resolve them in the sandbox before the initial push to JDK12.
>>> Issues targeted to '12' are expected to be fixed after the initial 
>>> push.
>>>
>>> /Andy
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.2/
>>>>
>>>> please send feedback to core-libs-dev at openjdk.java.net
>>>>
>>>> /Andy Herrick
>>>>
>>>