[OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from make to respective module

[Magnus Ihse Bursie]

On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @erikj79 Good point, that makes much more sense.
>
> I'm not sure about the formal process for suggesting changes to a delivered JEP, but this is the text I suggest should replace the current definition of the new scheme:
> 
>     src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
>                             native/include/*.{h,hpp}
>                                    $LIBRARY/*.{c,cpp}
>                             conf/*
>                             legal/*
>                             data/*
>                             man/*
>                             lib/*
> 
> where:
> 
>   - $MODULE is a module name (_e.g._, `java.base`);
> 
>   - The `share` directory contains shared, cross-platform code, as
>     before;
> 
>   - The `$OS` directory contains operating-system-specific code, as
>     before, where `$OS` is one of `unix`, `windows`, _etc._;
> 
>   - The `classes` directory contains Java source files and resource files
>     organized into a directory tree reflecting their API `$PACKAGE`
>     hierarchy, as before;
> 
>   - The `native` directory contains C or C++ source files, as before but
>     organized differently:
> 
>     - The `include` directory contains C or C++ header files intended to
>       be exported for external use (_e.g._, `jni.h`);
> 
>     - C or C++ source files are placed in a `$LIBRARY` directory, whose
>       name is that of the shared library or DLL into which the compiled
>       code will be linked (_e.g._, `libjava` or `libawt`); and, finally,
> 
>   - The `conf` directory contains configuration files meant to be edited
>     by end users (_e.g._, `net.properties`).
> 
>   - The `legal` directory contains legal notices.
> 
>   - The `data` directory contains data files needed for building the module.
> 
>   - The `man` directory contains man pages in nroff or markdown format.
> 
>   - The `lib` directory contains configuration files not meant to be edited
>     by end users.
> 
> Rendered as markdown, it would look somewhat like this:
> 
>     src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
>                             native/include/*.{h,hpp}
>                                    $LIBRARY/*.{c,cpp}
>                             conf/*
>                             legal/*
>                             data/*
>                             man/*
>                             lib/*
> 
> where:
> 
>   - $MODULE is a module name (_e.g._, `java.base`);
> 
>   - The `share` directory contains shared, cross-platform code, as
>     before;
> 
>   - The `$OS` directory contains operating-system-specific code, as
>     before, where `$OS` is one of `unix`, `windows`, _etc._;
> 
>   - The `classes` directory contains Java source files and resource files
>     organized into a directory tree reflecting their API `$PACKAGE`
>     hierarchy, as before;
> 
>   - The `native` directory contains C or C++ source files, as before but
>     organized differently:
> 
>     - The `include` directory contains C or C++ header files intended to
>       be exported for external use (_e.g._, `jni.h`);
> 
>     - C or C++ source files are placed in a `$LIBRARY` directory, whose
>       name is that of the shared library or DLL into which the compiled
>       code will be linked (_e.g._, `libjava` or `libawt`); and, finally,
> 
>   - The `conf` directory contains configuration files meant to be edited
>     by end users (_e.g._, `net.properties`).
> 
>   - The `legal` directory contains legal notices.
> 
>   - The `data` directory contains data files needed for building the module.
> 
>   - The `man` directory contains man pages in nroff or markdown format.
> 
>   - The `lib` directory contains configuration files not meant to be edited
>     by end users.

I hope I understood the purpose of the `lib` directory correctly. Our only instance of this is for `java.base/*/lib/security/default.policy`.

I also noted that jdk.hotspot.agent violates this scheme by having a top-level `test` and `doc` directories, apart from `share` and the OS directories. The purposes of these two directories are not clear to me. The tests in `test` are definitely never executed. I don't know if this is an omission, or if they should be removed. The documentation in `doc` is not exported to the end product, nor is it references in any developer documentation. That too should either be removed, or moved to a more suitable home.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1611