RFR: 8257733: Move module-specific data from make to respective module

[Magnus Ihse Bursie]

On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> To facilitate review, here is a list on how the different directories under make/data has moved.
>> 
>> **To java.base:**
>> * blacklistedcertsconverter
>> * cacerts
>> * characterdata
>> * charsetmapping
>> * cldr
>> * currency
>> * lsrdata
>> * publicsuffixlist
>> * tzdata
>> * unicodedata
>> 
>> **To java.desktop:**
>> * dtdbuilder
>> * fontconfig
>> * macosxicons
>> * x11wrappergen
>> 
>> **To jdk.compiler:**
>> * symbols
>> 
>> **To jdk.jdi:**
>> * jdwp
>> 
>> **Remaining in make:**
>> * bundle
>> * docs-resources
>> * macosxsigning
>> * mainmanifest
>
> Are you proposing any text or guidelines to be added to JEP 201 as part of this?
> 
> I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module.

@AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written.

I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented.

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

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