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.reinh...@oracle.com wrote:
2012/9/5 14:08 -0700, michael.f...@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



Reply via email to