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

[Roger Riggs]

Hi,

There are enough files unique to each platform to put them in separate 
packages
otherwise you get too many (IMHO) files in a single package/directory and
its harder to tell which go with which.  There isn't much of a problem with
classes being public because they are all in a module and not exported.

I would put them all under share/classes/jdk/jpackagers/internal/<OS> and
save a directory level.

$.02, Roger


On 11/13/2018 03:46 PM, Andy Herrick wrote:
> I agree with this and would take it further.
>
> 1 file is in ./share/classes/jdk/jpackager/internal/builders - why not 
> just ./share/classes/jdk/jpackager/internal
>
> 2 files are in ./share/classes/jdk/jpackager/internal/bundlers - why 
> not just in ./share/classes/jdk/jpackager/internal
>
> 1 file is in ./linux/classes/jdk/jpackager/internal/builders/linux - 
> why not just ./linux/classes/jdk/jpackager/internal
>
> 1 file is in ./macosx/classes/jdk/jpackager/internal/builders/mac - 
> why not just ./macosx/classes/jdk/jpackager/internal
>
> 1 file is in ./windows/classes/jdk/jpackager/internal/builders/windows 
> - why not just ./windows/classes/jdk/jpackager/internal
>
> then just move the associated resources -
>
> Basically put everything except Main in same package - everything 
> would be easier to find, and we could make almost all methods 
> package-private (the only exception would be the few things called by 
> Main, and the ToolProvider.
>
>
> On 11/13/2018 2:54 PM, Phil Race wrote:
>> Question .. why is "mac", "linux" and "windows" necessary in the 
>> package name here ?
>>
>>  src/jdk.jpackager/macosx/classes/jdk/jpackager/internal/mac/MacAppBundler.java 
>>
>>  src/jdk.jpackager/windows/classes/jdk/jpackager/internal/builders/windows/WindowsAppImageBuilder.java 
>>
>> src/jdk.jpackager/linux/classes/jdk/jpackager/internal/linux/LinuxRpmBundler.java 
>>
>>
>> There's not likely to be a clash, so is there some other reason not 
>> to want these
>> in the same package as the shared internals like
>> src/jdk.jpackager/share/classes/jdk/jpackager/internal/Param.java
>>
>> ?
>>
>> -phil.
>
> I agree with this and would take it further.
>
> 1 file is in ./share/classes/jdk/jpackager/internal/builders - why not 
> just ./share/classes/jdk/jpackager/internal
>
> 2 files are in ./share/classes/jdk/jpackager/internal/bundlers - why 
> not just in ./share/classes/jdk/jpackager/internal
>
> 1 file is in ./linux/classes/jdk/jpackager/internal/builders/linux - 
> why not just ./linux/classes/jdk/jpackager/internal
>
> 1 file is in ./macosx/classes/jdk/jpackager/internal/builders/mac - 
> why not just ./macosx/classes/jdk/jpackager/internal
>
> 1 file is in ./windows/classes/jdk/jpackager/internal/builders/windows 
> - why not just ./windows/classes/jdk/jpackager/internal
>
> then just move the associated resources -
>
> Basically put everything except Main in same package - everything 
> would be easier to find, and we could make almost all methods 
> package-private (the only exception would be the few things called by 
> Main, and the ToolProvider.
>
> /Andy
>