Hi Jean,
Yes, I think that you should check your dita file in to the dev trunk
and mark it as do-not-merge in the 10.2 wiki page. That will give us a
more current version on the mainline.
Thanks!
-Rick
Jean T. Anderson wrote:
Rick Hillegas wrote:
Hi Jean,
I was thinking of something a little different. I hope this sounds ok.
If not, let me know and I'll change course:
1) Check this generator into the trunk and let it be swept up in
tomorrow's mega-merge.
2) Document the SQLState-generating process in the Snapshot/Release
instructions.
I was thinking the instructions would read like this:
a) Run the generator. This will build the latest SQLState dita file into
the documentation source tree. This will only include SQLStates that
appear in the branch. This will not include SQLStates introduced by
commits to the trunk which haven't been ported to the branch.
b) Check that dita source into the branched docs.
c) Continue building the docs and code distributions as before.
Does this sound ok?
yes; this makes excellent sense. --My thinking was faulty when I said to
check the resulting dita into both the trunk and the branch. :-) sorry!
Should I go ahead and commit the dita source I generated for the trunk
into the dita source for the trunk? And mark this as one NOT to merge?
--That way the dev Reference Guide will have a working copy of the sql
messages.
-jean
Thanks,
-Rick
Jean T. Anderson wrote:
Rick Hillegas wrote:
Hi Jean,
This sounds good to me. I have downloaded the generator together with
John's latest edits. I will add this text to the output generator. I
hope to check it in and use it tomorrow.
ok, I won't check the dita source for this file into the trunk then
(like I claimed I would on another thread).
I'll go ahead and let you generate and commit it.
After you generate the new rrefexcept71493.dita file, it needs to be
copied to derby/docs/trunk/src/ref/ , then merged to the 10.2 branch.
sound good?
-jean
Regards,
-Rick
Jean T. Anderson wrote:
Here's a first shot:
In the messages below each {n} tag, where n is a number, represents a
value that the Derby engine fills in at runtime. Examples of values
include database names, database object names, property names, user
names, and parameters passed to a function or procedure.
suggestions?
-jean
David Van Couvering wrote:
I think this is reasonable...
David
Laura Stewart (JIRA) wrote:
[
http://issues.apache.org/jira/browse/DERBY-1566?page=comments#action_12431970
] Laura Stewart commented on DERBY-1566:
--------------------------------------
I understand the benefit of using the tool to generate current
messages. Of course I do prefer the human readable variables instead
of the markers like
{0} and {1}.
If we stick with this approach, I recommend that a sentence be added
to the message files that explains the variable markers.
Document SQLStates in 10.2
--------------------------
Key: DERBY-1566
URL: http://issues.apache.org/jira/browse/DERBY-1566
Project: Derby
Issue Type: Improvement
Components: Documentation
Affects Versions: 10.2.1.0
Reporter: Rick Hillegas
Assigned To: David Van Couvering
Fix For: 10.2.1.0
Attachments: derby-1566-1.diff, derby-1566-2.diff,
derby-1566-3.diff, ErrorMessageGenerator.david.diffs,
ErrorMessageGenerator.david.diffs2,
ErrorMessageGenerator.david.diffs3,
ErrorMessageGenerator.david.java,
ErrorMessageGenerator.java, ErrorMessageGenerator_davidv3_john.diff,
newmsgs-10.2.txt, rrefexcept-2.html, rrefexcept-3.html,
rrefexcept71493.html
We need to update the Reference Guide to document the current
list of
SQLStates. This list goes into
Reference Guide
Derby exception messages and SQL states
SQLState and error message reference
The tool mentioned in DERBY-296 may be useful.
