[jira] Updated: (DERBY-1868) Merge argument descriptors into SQLState strings so that SQLState documentation can be generated by a program
[ http://issues.apache.org/jira/browse/DERBY-1868?page=all ]
Rick Hillegas updated DERBY-1868:
-
Fix Version/s: 10.3.0.0
(was: 10.2.2.0)
Reassigning to 10.3 since that's where the work will show up.
Merge argument descriptors into SQLState strings so that SQLState
documentation can be generated by a program
-
Key: DERBY-1868
URL: http://issues.apache.org/jira/browse/DERBY-1868
Project: Derby
Issue Type: Improvement
Components: Build tools
Affects Versions: 10.2.1.6
Reporter: Rick Hillegas
Assigned To: Rick Hillegas
Fix For: 10.3.0.0
Attachments: antlib.diff, derby-1868-lineEndings-v01.diff,
derby-1868-merged-v01.diff, derby-1868-merged-v02.diff,
derby-1868-merged-v03.diff, messages.dtd, messages.xml
See DERBY-1566. That JIRA introduced a program, written by David, which
generates human-readable tables of message strings for inclusion in the
Reference Guide. The tool doesn't patch in friendly arguments. That leaves
the message strings peppered with unfriendly placeholders like {0}. {1},
etc.. Laura painstakingly editted the tables, by hand substituting in
friendlier arguments like userName and tableName.
We need to move Laura's substitutions into the source code so that David's
program can automatically plug them in. This will save us a lot of grief when
we generate future releases. Dan and Andrew have proposed approaches to this
problem. Those approaches are discussed in DERBY-1566. Here is Andrew's
comment on Dan's proposal:
While Dan's suggestion here:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/[EMAIL
PROTECTED]
to generate the message file and doc from a single XML file would be ideal, a
simpler approach to implement would be to maintain the meanings of the
markers in another properties file, identified by message key and marker
number. So, e.g. the new properties file would contain:
01500.0=constraintName
01500.1=tableName
Then ErrorMessageGenerator could look up the value of the markers by SQLState
and MessageFormat marker number in the properties file, although this
approach would require maintaining two files instead of one.
I glossed this further: If we adopt Andrew's approach, I would recommend
co-locating the argument descriptiors in the same properties file which
contains the messages. This will help keep the argument descriptors from
drifting out of sync with the messages themselves--that is a substantial
advantage of Dan's approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1868) Merge argument descriptors into SQLState strings so that SQLState documentation can be generated by a program
[ http://issues.apache.org/jira/browse/DERBY-1868?page=all ]
Rick Hillegas updated DERBY-1868:
-
Attachment: derby-1868-merged-v03.diff
Committed derby-1868-merged-v03.diff at subversion revision 470862. This adds
to message.xml a sentence which directs message writers to the website for
guidance on how to write messages.
Merge argument descriptors into SQLState strings so that SQLState
documentation can be generated by a program
-
Key: DERBY-1868
URL: http://issues.apache.org/jira/browse/DERBY-1868
Project: Derby
Issue Type: Improvement
Components: Build tools
Affects Versions: 10.2.1.6
Reporter: Rick Hillegas
Assigned To: Rick Hillegas
Fix For: 10.2.2.0
Attachments: antlib.diff, derby-1868-lineEndings-v01.diff,
derby-1868-merged-v01.diff, derby-1868-merged-v02.diff,
derby-1868-merged-v03.diff, messages.dtd, messages.xml
See DERBY-1566. That JIRA introduced a program, written by David, which
generates human-readable tables of message strings for inclusion in the
Reference Guide. The tool doesn't patch in friendly arguments. That leaves
the message strings peppered with unfriendly placeholders like {0}. {1},
etc.. Laura painstakingly editted the tables, by hand substituting in
friendlier arguments like userName and tableName.
We need to move Laura's substitutions into the source code so that David's
program can automatically plug them in. This will save us a lot of grief when
we generate future releases. Dan and Andrew have proposed approaches to this
problem. Those approaches are discussed in DERBY-1566. Here is Andrew's
comment on Dan's proposal:
While Dan's suggestion here:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/[EMAIL
PROTECTED]
to generate the message file and doc from a single XML file would be ideal, a
simpler approach to implement would be to maintain the meanings of the
markers in another properties file, identified by message key and marker
number. So, e.g. the new properties file would contain:
01500.0=constraintName
01500.1=tableName
Then ErrorMessageGenerator could look up the value of the markers by SQLState
and MessageFormat marker number in the properties file, although this
approach would require maintaining two files instead of one.
I glossed this further: If we adopt Andrew's approach, I would recommend
co-locating the argument descriptiors in the same properties file which
contains the messages. This will help keep the argument descriptors from
drifting out of sync with the messages themselves--that is a substantial
advantage of Dan's approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1868) Merge argument descriptors into SQLState strings so that SQLState documentation can be generated by a program
[ http://issues.apache.org/jira/browse/DERBY-1868?page=all ]
Rick Hillegas updated DERBY-1868:
-
Attachment: derby-1868-merged-v02.diff
Commit derby-1868-merged-v02.diff at subversion revision 470008. This causes
the clobber target to delete the generated messages_en.properties. This also
hides that generated file from subversion.
Merge argument descriptors into SQLState strings so that SQLState
documentation can be generated by a program
-
Key: DERBY-1868
URL: http://issues.apache.org/jira/browse/DERBY-1868
Project: Derby
Issue Type: Improvement
Components: Build tools
Affects Versions: 10.2.1.6
Reporter: Rick Hillegas
Assigned To: Rick Hillegas
Fix For: 10.2.2.0
Attachments: derby-1868-lineEndings-v01.diff,
derby-1868-merged-v01.diff, derby-1868-merged-v02.diff, messages.dtd,
messages.xml
See DERBY-1566. That JIRA introduced a program, written by David, which
generates human-readable tables of message strings for inclusion in the
Reference Guide. The tool doesn't patch in friendly arguments. That leaves
the message strings peppered with unfriendly placeholders like {0}. {1},
etc.. Laura painstakingly editted the tables, by hand substituting in
friendlier arguments like userName and tableName.
We need to move Laura's substitutions into the source code so that David's
program can automatically plug them in. This will save us a lot of grief when
we generate future releases. Dan and Andrew have proposed approaches to this
problem. Those approaches are discussed in DERBY-1566. Here is Andrew's
comment on Dan's proposal:
While Dan's suggestion here:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/[EMAIL
PROTECTED]
to generate the message file and doc from a single XML file would be ideal, a
simpler approach to implement would be to maintain the meanings of the
markers in another properties file, identified by message key and marker
number. So, e.g. the new properties file would contain:
01500.0=constraintName
01500.1=tableName
Then ErrorMessageGenerator could look up the value of the markers by SQLState
and MessageFormat marker number in the properties file, although this
approach would require maintaining two files instead of one.
I glossed this further: If we adopt Andrew's approach, I would recommend
co-locating the argument descriptiors in the same properties file which
contains the messages. This will help keep the argument descriptors from
drifting out of sync with the messages themselves--that is a substantial
advantage of Dan's approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1868) Merge argument descriptors into SQLState strings so that SQLState documentation can be generated by a program
[ http://issues.apache.org/jira/browse/DERBY-1868?page=all ]
Knut Anders Hatlen updated DERBY-1868:
--
Attachment: antlib.diff
I'm not able to build Derby after these changes, probably because my ant
installation doesn't have ant.jar under ${ant.home}/lib/ant.jar. The attached
patch, which changes the classpath entry to ${ant.library.dir}/ant.jar, makes
it possible to build Derby in my environment. Rick, could you test whether
${ant.library.dir} works in your environment? Thanks.
Merge argument descriptors into SQLState strings so that SQLState
documentation can be generated by a program
-
Key: DERBY-1868
URL: http://issues.apache.org/jira/browse/DERBY-1868
Project: Derby
Issue Type: Improvement
Components: Build tools
Affects Versions: 10.2.1.6
Reporter: Rick Hillegas
Assigned To: Rick Hillegas
Fix For: 10.2.2.0
Attachments: antlib.diff, derby-1868-lineEndings-v01.diff,
derby-1868-merged-v01.diff, derby-1868-merged-v02.diff, messages.dtd,
messages.xml
See DERBY-1566. That JIRA introduced a program, written by David, which
generates human-readable tables of message strings for inclusion in the
Reference Guide. The tool doesn't patch in friendly arguments. That leaves
the message strings peppered with unfriendly placeholders like {0}. {1},
etc.. Laura painstakingly editted the tables, by hand substituting in
friendlier arguments like userName and tableName.
We need to move Laura's substitutions into the source code so that David's
program can automatically plug them in. This will save us a lot of grief when
we generate future releases. Dan and Andrew have proposed approaches to this
problem. Those approaches are discussed in DERBY-1566. Here is Andrew's
comment on Dan's proposal:
While Dan's suggestion here:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/[EMAIL
PROTECTED]
to generate the message file and doc from a single XML file would be ideal, a
simpler approach to implement would be to maintain the meanings of the
markers in another properties file, identified by message key and marker
number. So, e.g. the new properties file would contain:
01500.0=constraintName
01500.1=tableName
Then ErrorMessageGenerator could look up the value of the markers by SQLState
and MessageFormat marker number in the properties file, although this
approach would require maintaining two files instead of one.
I glossed this further: If we adopt Andrew's approach, I would recommend
co-locating the argument descriptiors in the same properties file which
contains the messages. This will help keep the argument descriptors from
drifting out of sync with the messages themselves--that is a substantial
advantage of Dan's approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1868) Merge argument descriptors into SQLState strings so that SQLState documentation can be generated by a program
[ http://issues.apache.org/jira/browse/DERBY-1868?page=all ]
Rick Hillegas updated DERBY-1868:
-
Attachment: derby-1868-merged-v01.diff
Attaching derby-1868-merge-v01.diff. This makes the changes necessary for this
JIRA:
1) Removes the now obsolete ErrorMessageGenerator.
2) Replaces it with a new Ant Task, MessageBuilder. This new task runs during
the Derby build at the same time that the splitmessages target runs.
MessageBuilder takes an xml file of message descriptors and generates the
engine's messages_en.properties as well as the SQLState tables in the Reference
Guide (rrefexcept71493.dita).
3) Makes corresponding changes to the build file in engine/org/apache/derby/loc.
4) Removes the engine's messages_en.properties from version control since this
file is now generated.
5) Adds the corresponding descriptor file and its grammar: messages.xml and
messages.dtd.
Derbyall ran cleanly for me. This patch touches the following files:
D java/build/org/apache/derbyBuild/ErrorMessageGenerator.java
A java/build/org/apache/derbyBuild/MessageBuilder.java
M java/build/org/apache/derbyBuild/build.xml
A java/engine/org/apache/derby/loc/messages.dtd
D java/engine/org/apache/derby/loc/messages_en.properties
M java/engine/org/apache/derby/loc/build.xml
A java/engine/org/apache/derby/loc/messages.xml
Merge argument descriptors into SQLState strings so that SQLState
documentation can be generated by a program
-
Key: DERBY-1868
URL: http://issues.apache.org/jira/browse/DERBY-1868
Project: Derby
Issue Type: Improvement
Components: Build tools
Affects Versions: 10.2.1.6
Reporter: Rick Hillegas
Assigned To: Rick Hillegas
Fix For: 10.2.2.0
Attachments: derby-1868-lineEndings-v01.diff,
derby-1868-merged-v01.diff, messages.dtd, messages.xml
See DERBY-1566. That JIRA introduced a program, written by David, which
generates human-readable tables of message strings for inclusion in the
Reference Guide. The tool doesn't patch in friendly arguments. That leaves
the message strings peppered with unfriendly placeholders like {0}. {1},
etc.. Laura painstakingly editted the tables, by hand substituting in
friendlier arguments like userName and tableName.
We need to move Laura's substitutions into the source code so that David's
program can automatically plug them in. This will save us a lot of grief when
we generate future releases. Dan and Andrew have proposed approaches to this
problem. Those approaches are discussed in DERBY-1566. Here is Andrew's
comment on Dan's proposal:
While Dan's suggestion here:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/[EMAIL
PROTECTED]
to generate the message file and doc from a single XML file would be ideal, a
simpler approach to implement would be to maintain the meanings of the
markers in another properties file, identified by message key and marker
number. So, e.g. the new properties file would contain:
01500.0=constraintName
01500.1=tableName
Then ErrorMessageGenerator could look up the value of the markers by SQLState
and MessageFormat marker number in the properties file, although this
approach would require maintaining two files instead of one.
I glossed this further: If we adopt Andrew's approach, I would recommend
co-locating the argument descriptiors in the same properties file which
contains the messages. This will help keep the argument descriptors from
drifting out of sync with the messages themselves--that is a substantial
advantage of Dan's approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1868) Merge argument descriptors into SQLState strings so that SQLState documentation can be generated by a program
[ http://issues.apache.org/jira/browse/DERBY-1868?page=all ]
Rick Hillegas updated DERBY-1868:
-
Attachment: derby-1868-lineEndings-v01.diff
When I run the generator on xp/cygwin, it generates a file with windows-style
line endings (carriage-return + linefeed). This confuses subversion when I try
to check the generated file into the docs source tree. Attaching
derby-1868-lineEndings-v01.diff, which causes the program to emit UNIX-style
line endings (linefeed) suitable for checkin.
Merge argument descriptors into SQLState strings so that SQLState
documentation can be generated by a program
-
Key: DERBY-1868
URL: http://issues.apache.org/jira/browse/DERBY-1868
Project: Derby
Issue Type: Improvement
Components: Build tools
Affects Versions: 10.2.1.5
Reporter: Rick Hillegas
Fix For: 10.2.2.0
Attachments: derby-1868-lineEndings-v01.diff
See DERBY-1566. That JIRA introduced a program, written by David, which
generates human-readable tables of message strings for inclusion in the
Reference Guide. The tool doesn't patch in friendly arguments. That leaves
the message strings peppered with unfriendly placeholders like {0}. {1},
etc.. Laura painstakingly editted the tables, by hand substituting in
friendlier arguments like userName and tableName.
We need to move Laura's substitutions into the source code so that David's
program can automatically plug them in. This will save us a lot of grief when
we generate future releases. Dan and Andrew have proposed approaches to this
problem. Those approaches are discussed in DERBY-1566. Here is Andrew's
comment on Dan's proposal:
While Dan's suggestion here:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/[EMAIL
PROTECTED]
to generate the message file and doc from a single XML file would be ideal, a
simpler approach to implement would be to maintain the meanings of the
markers in another properties file, identified by message key and marker
number. So, e.g. the new properties file would contain:
01500.0=constraintName
01500.1=tableName
Then ErrorMessageGenerator could look up the value of the markers by SQLState
and MessageFormat marker number in the properties file, although this
approach would require maintaining two files instead of one.
I glossed this further: If we adopt Andrew's approach, I would recommend
co-locating the argument descriptiors in the same properties file which
contains the messages. This will help keep the argument descriptors from
drifting out of sync with the messages themselves--that is a substantial
advantage of Dan's approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
