vmassol 2003/09/11 11:14:13
Modified: documentation/docs/xdocs how_it_works.xml
changes_archive.xml mock_vs_cactus.xml goals.xml
documentation/docs/xdocs/writing howto_testcase_jsp.xml
documentation/docs/xdocs/integration howto_config.xml
documentation/docs/xdocs/integration/ant
howto_ant_primer.xml
Log:
English grammar fix
Revision Changes Path
1.8 +2 -2 jakarta-cactus/documentation/docs/xdocs/how_it_works.xml
Index: how_it_works.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/how_it_works.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- how_it_works.xml 18 Jan 2003 00:08:32 -0000 1.7
+++ how_it_works.xml 11 Sep 2003 18:14:13 -0000 1.8
@@ -116,9 +116,9 @@
</li>
<li>
If an exception has been raised, the Redirector proxy returns the
- information about the exception (it's name, class, stack trace) back
+ information about the exception (its name, class, stack trace) back
to the client side. Information about the exception will then be
- printed by JUnit in it's Test Runner console.
+ printed by JUnit in its Test Runner console.
</li>
<li>
If no exception occurred, the <code>YYYTestCase.runTest()</code>
1.2 +1 -1 jakarta-cactus/documentation/docs/xdocs/changes_archive.xml
Index: changes_archive.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/changes_archive.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- changes_archive.xml 13 Jul 2003 10:32:08 -0000 1.1
+++ changes_archive.xml 11 Sep 2003 18:14:13 -0000 1.2
@@ -525,7 +525,7 @@
</action>
<action dev="VMA" type="add">
Added a new target called <code>deploy-site</code> that automatically
- deploy the generated web site to it's home page on the Jakarta server.
+ deploy the generated web site to its home page on the Jakarta server.
This will be very useful when integrated with GUMP nightly builds so
that the web site is always up to date.
</action>
1.5 +1 -1 jakarta-cactus/documentation/docs/xdocs/mock_vs_cactus.xml
Index: mock_vs_cactus.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/mock_vs_cactus.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- mock_vs_cactus.xml 18 Jan 2003 00:08:32 -0000 1.4
+++ mock_vs_cactus.xml 11 Sep 2003 18:14:13 -0000 1.5
@@ -52,7 +52,7 @@
The main goal of MO is to unit test a method in isolation of other
domain objects. Thus, the MO approach is to fake domain objects
by using simulated copies instead of the real objects (be careful
- MO does not implement any logic in it's fake objects, that would be
+ MO does not implement any logic in its fake objects, that would be
"stubbing". All behaviours of mock objects are controlled by the unit
test itself). This enables to
finely unit test the method with no environment
1.13 +1 -1 jakarta-cactus/documentation/docs/xdocs/goals.xml
Index: goals.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/goals.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- goals.xml 13 Jul 2003 10:42:42 -0000 1.12
+++ goals.xml 11 Sep 2003 18:14:13 -0000 1.13
@@ -96,7 +96,7 @@
ensuring that the code behaves ok. Indeed, as the components will
rely more and more on the container's services, the confidence that
the tests will run well when deployed will decrease and the need
- for a solution that ensures the code will run correctly in it's
+ for a solution that ensures the code will run correctly in its
environment will increase,
</li>
<li>
1.6 +1 -1
jakarta-cactus/documentation/docs/xdocs/writing/howto_testcase_jsp.xml
Index: howto_testcase_jsp.xml
===================================================================
RCS file:
/home/cvs/jakarta-cactus/documentation/docs/xdocs/writing/howto_testcase_jsp.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- howto_testcase_jsp.xml 28 Jan 2003 15:48:18 -0000 1.5
+++ howto_testcase_jsp.xml 11 Sep 2003 18:14:13 -0000 1.6
@@ -475,7 +475,7 @@
this object (the old out object is saved) to capture all of the
response writing that goes on in the body of the tag. After the
tag's body has been evaluated, the tag itself has a chance to
- do something with the result of the evaluation in it's
+ do something with the result of the evaluation in its
<code>doAfterBody()</code> method. After the tag has completed
its execution, the container restores the old out object with
a call to <code>pageContext.popBody()</code>.
1.2 +1 -1
jakarta-cactus/documentation/docs/xdocs/integration/howto_config.xml
Index: howto_config.xml
===================================================================
RCS file:
/home/cvs/jakarta-cactus/documentation/docs/xdocs/integration/howto_config.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_config.xml 6 May 2003 16:11:09 -0000 1.1
+++ howto_config.xml 11 Sep 2003 18:14:13 -0000 1.2
@@ -288,7 +288,7 @@
copy the <code>jspRedirector.jsp</code> file (found in the
<code>sample/web</code> directory where you unpacked your
Cactus distribution) in a directory in your webapp and you need to
- put it's relative path in the mapping defined above (here we
+ put its relative path in the mapping defined above (here we
have put it in the webapp root.
</note>
1.4 +1 -1
jakarta-cactus/documentation/docs/xdocs/integration/ant/howto_ant_primer.xml
Index: howto_ant_primer.xml
===================================================================
RCS file:
/home/cvs/jakarta-cactus/documentation/docs/xdocs/integration/ant/howto_ant_primer.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- howto_ant_primer.xml 25 Apr 2003 13:54:32 -0000 1.3
+++ howto_ant_primer.xml 11 Sep 2003 18:14:13 -0000 1.4
@@ -893,7 +893,7 @@
you need to deliver a jar file. We also include a manifest file
in the jar, with version information. We copy the manifest to the
output directory in order to replace the <code>@version@</code>
- token with it's value.
+ token with its value.
</p>
<p>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
