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

[Magnus Ihse Bursie]

On 2022-03-16 20:53, Alan Bateman wrote:
> On 16/03/2022 08:44, Magnus Ihse Bursie wrote:
>> :
>>
>> If you have such strong opinions on the data files shared between 
>> java.base and jdk.charsets/jdk.localedata, I propose we leave them in 
>> make/data for the time being, clean up the associated mess, and then 
>> work out where they actually should be. Does that sound okay to you?
>
> The concern, as before, is that it puts data files into src/java.base 
> that are used by the build to generate classes/resources for the 
> service provider modules.  We also have the complication that the 
> charsets to include in java.base varies by platform so the 
> module/package for each charset is decided at build time. It's always 
> been low-priority to re-visit that and not clear if we could even get 
> to an agreement easily because there are IBM platforms that want 
> EBCDIC and other double byte charsets whereas other platforms don't 
> want these in java.base. So yes, if you can drop the move of the 
> charset data and CLDR data from the patch then it will make it easier 
> to discuss.

Okay, fine. I'll revert the move of `charsetmapping` and `cldr`, and put 
them back in `make/data`. We can deal with them in due time. I agree 
that they are tricky and might need more consideration than the rest of 
the module-specific data files.

The `make/data` directory will not be entirely gone even with my 
original patch. Left in there were files that did not belong to a 
specific module, like macOS and Windows metadata files. One could argue 
that the charsetmapping and cldr does not belong to a module as well. 
The difference here is that it does not even make sense to talk about 
module ownership for the other files in make/data , but these files are 
clearly related to two modules (java.base and 
jdk.charsets/jdk.localedata) -- just not a *single*  module.

/Magnus