[8] Review request for 7196354 check-in jdk.tbom file to openjdk repo (original) (raw)

Naoto Sato naoto.sato at oracle.com
Tue Sep 11 05:57:14 UTC 2012

Hi Michael,

Looks like the list does not reflect the recent changes introduced by the re-organization of the locale data (sun/util/resources).

To me, just keeping an eye on the files sounds error prone. Would it be possible to add some automated check, say in "jcheck"?

Naoto

On 9/10/12 2:26 PM, Michael Fang wrote:

Hi Mark and all,

I have updated the webrev: http://cr.openjdk.java.net/~mfang/7196354/webrev.01/ It includes the following changes: - removed component division and contact names - removed redundant "target" attributes

I am also moving the file from root of source tree to jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file naming convention used by the translation system, which is component-name.tbom. This is followed by all Oracle products requiring translation. We currently have no plan to publish the syntax and semantics to the openjdk community through JEP process. We would like to keep the syntax internal. When I review dev team's changes related to resource files, I will keep an eye on the files to be translated and translation language scope. thanks, -michael Server Globalization Technology On 12年09月06日 04:46 下午, Michael Fang wrote: Hi Mark,

Thanks for the review and feedback. Please see my comments inline below. thanks, -michael On 12年09月06日 01:29 下午, mark.reinhold at oracle.com wrote: 2012/9/5 14:08 -0700, michael.fang at oracle.com: Please help to review the new JDK8 file for the following CR: 7196354 check-in jdk.tbom file to openjdk repo

The webrev is located at: http://cr.openjdk.java.net/~mfang/7196354/webrev.00/ This file needs a more descriptive name, especially if it's going to be in the root of the source tree. Suggestion: translated-files.xml . The translation drop system is now an Oracle-wide translation system and we are strongly recommended to follow the standard naming convention for all Oracle products, which is component-name.tbom. I have checked with the team and we can move the file away from the root of the source tree to, for example, jdk/make/jdk.tbom. Is there a DTD or a schema for this file? I can guess what most of it means, but I might guess incorrectly. The XSD is available in NLSTOOLS ADE label. nlstools/lights2/Extractor/src/java/xsd/tbom.xsd It's internal information. I will find it and forward it to you separately. [line 8] "OpenJDK" isn't a component, it's a community. I think you mean "JDK" here. Yes, JDK. The "JDK" / "JRE" division in this file is somewhat artificial and likely to become incorrect over time -- not every developer knows exactly which files are in the JRE vs. the full JDK. I suggest doing away with that division and simply sorting the file-set elements by source file name. JDK and JRE are translated into different sets of languages. 2 languages for JDK and 10 for JRE. We used to divide the files this way in order to translate the files into the correct set of languages. But it's not necessary now. Sorting by groups or projects may be fine. Whatever is easy for the groups/teams to find and maintain their files. At a glance it looks like the source and target attributes for any given file are identical. Do you expect there to be cases where they're different? In jdk.tbom, source and target are the same for all files. But on jdkclosed.tbom, the man page files have different source and target directories. ... Mark: Since the dev team will need to maintain this file in the future (modifying it if you add or delete resource files), I temporarily put down your name as contact for the file. Please figure out the proper owner and we can update it again. We don't put contact names in source code. Please remove my name, and do not add another. OK, I will remove it. ... In the future, if any bug/rfe requires adding/deleting resource files, the dev work should include updating this file to reflect the correct resource file list. (and please ask me to review it). If you expect other people to update this file over time then you need to document that expectation somewhere and, as importantly, you need to document the syntax and semantics of the file. Fortunately we have a way to do that, namely the JEP process (http://openjdk.java.net/jeps/). I suggest you draft a JEP for this and circulate it for review along with the webrev. I will look into it. - Mark

More information about the core-libs-dev mailing list