[rkward-cvs] SF.net SVN: rkward:[3800] trunk/rkward/doc/rkward/ writing_plugins_introduction.docbook

[sjar at users.sourceforge.net]

Revision: 3800
          http://rkward.svn.sourceforge.net/rkward/?rev=3800&view=rev
Author:   sjar
Date:     2011-09-19 19:32:01 +0000 (Mon, 19 Sep 2011)
Log Message:
-----------
some spelling

Modified Paths:
--------------
    trunk/rkward/doc/rkward/writing_plugins_introduction.docbook

Modified: trunk/rkward/doc/rkward/writing_plugins_introduction.docbook
===================================================================
--- trunk/rkward/doc/rkward/writing_plugins_introduction.docbook	2011-09-19 15:01:43 UTC (rev 3799)
+++ trunk/rkward/doc/rkward/writing_plugins_introduction.docbook	2011-09-19 19:32:01 UTC (rev 3800)
@@ -1374,7 +1374,7 @@
 		<para>For external plugins to install and work properly, they must follow some structural guidelines regarding their file hierarchy. </para>
     
 		<section id="file_hierarchy"><title>File hierarchy</title>
-			<para>Lets have a look at the prototypic file hierarchy of an elaborate plugin archive. You don’t have to include all of these directories and/or files for a plugin to work (read on to learn what’s absolutely neccessary), consider this a "best practice" example: </para>
+			<para>Lets have a look at the prototypic file hierarchy of an elaborate plugin archive. You don’t have to include all of these directories and/or files for a plugin to work (read on to learn what’s absolutely necessary), consider this a "best practice" example: </para>
 			<programlisting>
 	plugin_name/
 		inst/
@@ -1431,7 +1431,7 @@
 			</section>
 			<section id="automated_plugin_testing">
 				<title>Automated plugin testing (optional)</title>
-				<para>Another optional directory is "tests", which is meant to provide files needed for automated plugin testing. These tests are helpful to quickly check if your plugins still work with new versions of R or &kapp;. If you want to include tests, you should really restrain yourself to the naming scheme and hierarchy shown here. That is, tests should reside in a directory called "tests", which includes a file "testsuite.R" and a folder with tests standards named after the appropriate test suite. You can, however, provide more than one test suite; in that case, if you don’t want to append them all in the one "testsuite.R" file, you can split them in e.g. one file for each test suite and create one "testsuite.R" with "source()" calls for each suite file. In either case, create seperate subdirectories with test standards for each defined suite. </para>
+				<para>Another optional directory is "tests", which is meant to provide files needed for automated plugin testing. These tests are helpful to quickly check if your plugins still work with new versions of R or &kapp;. If you want to include tests, you should really restrain yourself to the naming scheme and hierarchy shown here. That is, tests should reside in a directory called "tests", which includes a file "testsuite.R" and a folder with tests standards named after the appropriate test suite. You can, however, provide more than one test suite; in that case, if you don’t want to append them all in the one "testsuite.R" file, you can split them in e.g. one file for each test suite and create one "testsuite.R" with "source()" calls for each suite file. In either case, create separate subdirectories with test standards for each defined suite. </para>
 				<para>The benefits of upholding to this structure is that plugin tests can be run simply by calling "rktests.makplugintests()" from the tests directory without additional arguments. </para>
 			</section>
 		</section>
@@ -1439,7 +1439,7 @@
   
 	<section id="meta-information">
 		<title>Meta-information</title>
-		<para>Each plugin archive should provide some basic meta information on what it deals with, where to find more information, who maintians it, if it relies on specific R packages or other plugins, etc. </para>
+		<para>Each plugin archive should provide some basic meta information on what it deals with, where to find more information, who maintains it, if it relies on specific R packages or other plugins, etc. </para>
 		<para>This information is given at least once in your .pluginmap, and can then be included or overwritten in each plugin .xml file (which might be useful if that particular plugin file was contributed by someone else, for instance). </para>
 		<para>To achieve this, the <about> tag is used. The overall structure of this tag looks something like this: </para>
 		<programlisting>

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.