RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (original) (raw)

Roger Riggs Roger.Riggs at oracle.com
Tue Nov 13 20:52:56 UTC 2018

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/ 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

More information about the build-dev mailing list