forrest-svn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cross...@apache.org
Subject svn commit: r526968 [3/3] - in /forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo: ./ resources/stylesheets/ src/documentation/ src/documentation/content/ src/documentation/content/svn-log/ src/documentation/content/useCases/ src/docume...
Date Tue, 10 Apr 2007 00:20:10 GMT
Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/useCases/changeLogFeatures.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/useCases/changeLogFeatures.xml?view=diff&rev=526968&r1=526967&r2=526968
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/useCases/changeLogFeatures.xml (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/useCases/changeLogFeatures.xml Mon Apr  9 17:20:08 2007
@@ -17,63 +17,70 @@
 -->
 <useCases>
   <title>Uses Cases for Change Log management features of org.apache.forrest.plugin.input.projectInfo</title>
-
   <useCase>
     <title>Write status.xml File</title>
     <description>
-      <p>Status.xml if an XML file that records the actions that have been taken in each release
-      of a project. You can then generate a Change Log from that file using the projectInfo
-      plugin.</p>
-
+      <p>
+        Status.xml if an XML file that records the actions that have been taken
+        in each release of a project. You can then generate a Change Log from
+        that file using the projectInfo plugin.
+      </p>
       <section>
         <title>Justification</title>
-
-        <p>Provide a central location and a semi-structured format for recording
-        actions taken during project development. This file can then be used to 
-        generate various views on the changes in a release. For example:</p>
-
+        <p>
+          Provide a central location and a semi-structured format for recording
+          actions taken during project development. This file can then be used
+          to generate various views on the changes in a release. For example:
+        </p>
         <ul>
           <li>Changes between releases</li>
           <li>Developers involved in a release</li>
           <li>Release notes</li>
         </ul>
       </section>
-      
     </description>
-
     <steps>
       <step>
         <title>Create/open a status.xml file</title>
         <description>
-          <p>In your favourite XML editor either create a new file
-          or open an existing status.xml file. The default location of these files
-          within a Forrest content object is in the project root. This file should
-          conform to one of the status.xml schemas. The root element for this
-          document is <code>status</code>.</p>
+          <p>
+            In your favourite XML editor either create a new file or open an
+            existing status.xml file. The default location of these files within
+            a Forrest content object is in the project root. This file should
+            conform to one of the status.xml schemas. The root element for this
+            document is <code>status</code>.
+          </p>
         </description>
         <result>You have either a blank status.xml document or an existing one ready for editing.</result>
       </step>
-      
       <step>
         <title>Create a developer list</title>
         <description>
-          <p>In order to attribute changes to a specific developer it is neceessary to create
-          a <code>developers</code> element. Within this element you should add a single
-          <code>person</code> element for each develop who works on the project.</p>
+          <p>
+            In order to attribute changes to a specific developer it is
+            neceessary to create a <code>developers</code> element. Within this
+            element you should add a single <code>person</code> element for each
+            develop who works on the project.
+          </p>
         </description>
         <result>Each developer is identified in the status.xml file.</result>
       </step>
-
-      
       <step>
         <title>Create a contexts list</title>
         <description>
-          <p>Each action within a release is given a context to help classify changes.
-          When reports are created the context of an action is used to create a more
-          readable report in which similar actions are grouped together. You can
-          specify any contexts you like within the <code>contexts</code> element.</p>
-          <p>Common contexts used in an software development project are:</p>
-          <source><![CDATA[
+          <p>
+            Each action within a release is given a context to help classify
+            changes. When reports are created the context of an action is used
+            to create a more readable report in which similar actions are
+            grouped together. You can specify any contexts you like within the
+            <code>contexts</code> element.
+          </p>
+
+          <p>
+            Common contexts used in an software development project are:
+          </p>
+          <source>
+<![CDATA[
 <contexts>
  <context id="code" title="Changes to the Code Base"/>
  <context id="docs" title="Changes to Documentation"/>
@@ -81,78 +88,91 @@
  <context id="design" title="Changes to Design"/>
  <context id="build" title="Changes to Build"/>
 </contexts> 
-          ]]></source>
+          ]]>
+          </source>
         </description>
         <result>The status.xml file describes the sufficient contexts to group common
         actions together.</result>
       </step>
-      
       <step>
         <title>Create a changes element</title>
         <description>
-          <p>Actions that describe the changed in a release are placed within
-          a <code>changes</code>.</p>
+          <p>
+            Actions that describe the changed in a release are placed within a
+            <code>changes</code>.
+          </p>
         </description>
         <result>Status.xml holds an changes element that will group all release 
         information.</result>
       </step>
-      
       <step>
         <title>Create a release element</title>
         <description>
-          <p>The details of each release are enclosed within a <code>release</code> element,
-          so you need to create that now.</p>
+          <p>
+            The details of each release are enclosed within a
+            <code>release</code> element, so you need to create that now.
+          </p>
         </description>
-
         <result>You have the container for your current development release.</result>
       </step>
-
-        <step>
-          <title>Create a notes element</title>
-          <description>
-            <p>Each release can have a <code>notes</code> section. This is used
-            to provide descriptive text at the start of many reports. The notes
+      <step>
+        <title>Create a notes element</title>
+        <description>
+          <p>
+            Each release can have a <code>notes</code> section. This is used to
+            provide descriptive text at the start of many reports. The notes
             should describe the release in fairly high level detail, it should
-            not describe any change descriptions, these will be added in the 
-            next step.</p>
-          </description>
-
-          <result>You have a user focussed description of the project and this release.</result>
-        </step>
-
-        <step>
-          <title>Add actions taken during the development cycle</title>
-          <description>
-            <p>During the development cycle for the release <code>action</code> elements
-            should be added for each significant contribution to the release.</p>
-            
-            <p>If the change is of particular significance and you woul dlike it to appear
-            in the release notes generated by the projectInfo plugin you should set the
-            <code>importance</code> attribute to <code>"high"</code>.</p>
-          </description>
-          
-          <result>Each significant change in this development cycle is describe in a 
+            not describe any change descriptions, these will be added in the
+            next step.
+          </p>
+        </description>
+        <result>You have a user focussed description of the project and this release.</result>
+      </step>
+      <step>
+        <title>Add actions taken during the development cycle</title>
+        <description>
+          <p>
+            During the development cycle for the release <code>action</code>
+            elements should be added for each significant contribution to the
+            release.
+          </p>
+
+          <p>
+            If the change is of particular significance and you woul dlike it to
+            appear in the release notes generated by the projectInfo plugin you
+            should set the <code>importance</code> attribute to
+            <code>"high"</code>.
+          </p>
+        </description>
+        <result>Each significant change in this development cycle is describe in a 
           <code>action</code> element.</result>
-        </step>
-
-        <step>
-          <title>Generate the change log</title>
-          <description>
-            <p>To generate a changelog from your status.xml file you need to request
-            <code>/changes.html</code> or <code>changes.pdf</code> or whatever format
-            you have enabled within Forrest using output plugins.</p>
-            
-            <p>Note that the projectInfo plugin provides a special RSS output format
-            of. Technically, this should not be part of an input plugin and therefore
-            it may be moved at a later date. However, you will always be able to 
-            generate the RSS feed by requesting <code>changes.rss</code>.</p>
-            
-            <p>You can generate a change log for a specific version by specifying a 
-            version number in the request, for example, <code>changes_0.1.html</code>.</p>
-          </description>
-          
-          <result>Your project is able to generate a changelog.</result>
-        </step>
+      </step>
+      <step>
+        <title>Generate the change log</title>
+        <description>
+          <p>
+            To generate a changelog from your status.xml file you need to
+            request <code>/changes.html</code> or <code>changes.pdf</code> or
+            whatever format you have enabled within Forrest using output
+            plugins.
+          </p>
+
+          <p>
+            Note that the projectInfo plugin provides a special RSS output
+            format of. Technically, this should not be part of an input plugin
+            and therefore it may be moved at a later date. However, you will
+            always be able to generate the RSS feed by requesting
+            <code>changes.rss</code>.
+          </p>
+
+          <p>
+            You can generate a change log for a specific version by specifying a
+            version number in the request, for example,
+            <code>changes_0.1.html</code>.
+          </p>
+        </description>
+        <result>Your project is able to generate a changelog.</result>
+      </step>
     </steps>
   </useCase>
 </useCases>

Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/useCases/useCaseFeatures.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/useCases/useCaseFeatures.xml?view=diff&rev=526968&r1=526967&r2=526968
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/useCases/useCaseFeatures.xml (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/useCases/useCaseFeatures.xml Mon Apr  9 17:20:08 2007
@@ -17,24 +17,27 @@
 -->
 <useCases>
   <title>Uses Cases for the Use Case management features of org.apache.forrest.plugin.input.projectInfo</title>
-
   <useCase>
     <title>Write Use Case Documentation</title>
     <description>
-      <p>Write semi-structured use case documents so that they can be reused in a variety of ways.
-      This use case describews a process for writing such documents. This document is derived from
-      such a <a href="useCaseFeatures.source.xml">source document</a>.</p>
-
+      <p>
+        Write semi-structured use case documents so that they can be reused in a
+        variety of ways. This use case describews a process for writing such
+        documents. This document is derived from such a
+        <a href="useCaseFeatures.source.xml">source document</a>.
+      </p>
       <section>
         <title>Justification</title>
-
-        <p>A use case describes a unit of work. It is typically used in the design
-        stages of a software project. It is very useful for describing what an applicaiton must
-        do and what patchs through the system can be taken.</p>
-
-        <p>By bringing this information together in a semi-structured document we can use it in many
-        different ways. For example:</p>
-
+        <p>
+          A use case describes a unit of work. It is typically used in the
+          design stages of a software project. It is very useful for describing
+          what an applicaiton must do and what patchs through the system can be
+          taken.
+        </p>
+        <p>
+          By bringing this information together in a semi-structured document we
+          can use it in many different ways. For example:
+        </p>
         <ul>
           <li>Requirements Documentation</li>
           <li>Developer Documentation</li>
@@ -43,181 +46,198 @@
           <li>Task Lists</li>
         </ul>
       </section>
-      
     </description>
-
     <steps>
       <step>
         <title>Create/open a Use Case file</title>
-        <description>In your favourite XML editor either create a new file
-        or open an existing use case file. The default location of these files
-        within a Forrest content object is <code>/content/documentation/useCases/**.xml</code>
+        <description>
+          In your favourite XML editor either create a new file or open an
+          existing use case file. The default location of these files within a
+          Forrest content object is
+          <code>/content/documentation/useCases/**.xml</code>
         </description>
         <result>You have either a blank use case document or an existing one ready for editing.</result>
-
-        <fixme priority="Medium">Create a DTD for use case descriptions.</fixme>
-        <fixme priority="High">Aggregate all documents in the useCases directory to provide
-        ne large document describing all use cases.</fixme>
+        <fixme priority="Medium">
+          Create a DTD for use case descriptions.
+        </fixme>
+        <fixme priority="High">
+          Aggregate all documents in the useCases directory to provide ne large
+          document describing all use cases.
+        </fixme>
       </step>
-
       <step>
         <title>Create a new use case</title>
         <description>
-          <p>A use case is enclosed within a <code>useCase</code> element.
-          Each use case should be given a brief <code>title</code> to describe it.</p>
-
+          <p>
+            A use case is enclosed within a <code>useCase</code> element. Each
+            use case should be given a brief <code>title</code> to describe it.
+          </p>
         </description>
-
         <result>You have the container for your new use case.</result>
       </step>
-
-        <step>
-          <title>Describe the overall objective of the use case</title>
-          <description>
-            <p>Each use case should be described in terms of:</p>
-            <ul>
-              <li>The objective</li>
-              <li>The expected results</li>
-              <li>The justification</li>
-            </ul>
-            <p>This information should be placed in the <code>description</code> element
-          of your use case. This node allows any XDoc markup and therefore you are
-          reasonably free to use whatever formatting or images are needed to convey the
-          important details most efficiently.</p>
-          </description>
-
-          <result>You have a use case that is described sufficiently well for an average user of the end system
+      <step>
+        <title>Describe the overall objective of the use case</title>
+        <description>
+          <p>
+            Each use case should be described in terms of:
+          </p>
+          <ul>
+            <li>The objective</li>
+            <li>The expected results</li>
+            <li>The justification</li>
+          </ul>
+          <p>
+            This information should be placed in the <code>description</code>
+            element of your use case. This node allows any XDoc markup and
+            therefore you are reasonably free to use whatever formatting or
+            images are needed to convey the important details most efficiently.
+          </p>
+        </description>
+        <result>You have a use case that is described sufficiently well for an average user of the end system
         to understand its purpose.</result>
-        </step>
-
-        <step>
-          <title>Define each step in the Use Case</title>
-          <description>
-            <p>Each use case will be subdivided into one or more steps that must be carried out
-          in order to complete the task. Each of these steps is defined within a <code>step</code>
-          element which are chilren of a <code>steps</code> element.</p>
-          </description>
-        </step>
-
-        <step>
-          <title>Descripbe the step</title>
-          <description>
-            <p>Each step has a title and a description. The description should provide enough information
-            for a user to complete the task and for a developer to implement support for the user in that
-            task.</p>
-
-            <p>In addition each step can be described as required or optional. By default a step is assumed
-            be required. To set it to optional add a <code>required="false"</code> attribute to the
-            <code>step</code> element.</p>
-          </description>
-
-          <result>A user will be able to follow instructions on how to carry out the step.</result>
-        </step>
+      </step>
+      <step>
+        <title>Define each step in the Use Case</title>
+        <description>
+          <p>
+            Each use case will be subdivided into one or more steps that must be
+            carried out in order to complete the task. Each of these steps is
+            defined within a <code>step</code> element which are chilren of a
+            <code>steps</code> element.
+          </p>
+        </description>
+      </step>
+      <step>
+        <title>Descripbe the step</title>
+        <description>
+          <p>
+            Each step has a title and a description. The description should
+            provide enough information for a user to complete the task and for a
+            developer to implement support for the user in that task.
+          </p>
 
-        <step>
-          <title>Describe the expected results</title>
-          <description>
-            <p>Provide, within a <code>result</code> a brief description of the expected results from
-            this step. This should summarise what state the application will be in once this use case
-            has been performed.</p>
-          </description>
-          <result>You will have provided enough information to allow developers to test the functionality and
+          <p>
+            In addition each step can be described as required or optional. By
+            default a step is assumed be required. To set it to optional add a
+            <code>required="false"</code> attribute to the <code>step</code>
+            element.
+          </p>
+        </description>
+        <result>A user will be able to follow instructions on how to carry out the step.</result>
+      </step>
+      <step>
+        <title>Describe the expected results</title>
+        <description>
+          <p>
+            Provide, within a <code>result</code> a brief description of the
+            expected results from this step. This should summarise what state
+            the application will be in once this use case has been performed.
+          </p>
+        </description>
+        <result>You will have provided enough information to allow developers to test the functionality and
           users to identify when a step has been succesfully completed.</result>
-        </step>
-
-        <step required="false">
-          <title>Add "fixme" notes</title>
-          <description>
-            <p>A fixme note is enclosed within a <code>fixme</code> element. It describes something that
-            remains to be done within this step. Each fixme has a priority attribute which can take one of
-            of the followin values:</p>
-
-            <ul>
-              <li>Enhancement - a nice to have ehancment that may or may not be implemented.</li>
-              <li>Low - this is considered an important addition to the use case, but everything works without it.</li>
-              <li>High - this is an important addition. Everything works without it, but having this implmeneted would
+      </step>
+      <step required="false">
+        <title>Add "fixme" notes</title>
+        <description>
+          <p>
+            A fixme note is enclosed within a <code>fixme</code> element. It
+            describes something that remains to be done within this step. Each
+            fixme has a priority attribute which can take one of of the followin
+            values:
+          </p>
+          <ul>
+            <li>Enhancement - a nice to have ehancment that may or may not be implemented.</li>
+            <li>Low - this is considered an important addition to the use case, but everything works without it.</li>
+            <li>High - this is an important addition. Everything works without it, but having this implmeneted would
               improve the application considerably.</li>
-              <li>Major - this is nor preventing work that utilises the use case, but it is considered a requirement
+            <li>Major - this is nor preventing work that utilises the use case, but it is considered a requirement
               for the next release since it adds key functionlaity.</li>
-              <li>Blocker - this is preventing the correct operation of this use case and must be implmeneted ASAP</li>
-            </ul>
-
-            <p>Although this step is optional, it is good practice to allways add a 
-            <code>&lt;fixme priority="blocker"&gt;Not yet implemented&lt;/fixme&gt;</code>
-            element to all new steps. This is becuase these nodes will be used to build a 
-            functionality matrix later on.</p>
-          </description>
-
-          <result>Users will be able to understand to what degree a step is implemented and developers will be able to 
+            <li>Blocker - this is preventing the correct operation of this use case and must be implmeneted ASAP</li>
+          </ul>
+          <p>
+            Although this step is optional, it is good practice to allways add a
+            <code>&lt;fixme priority="blocker"&gt;Not yet
+            implemented&lt;/fixme&gt;</code> element to all new steps. This is
+            becuase these nodes will be used to build a functionality matrix
+            later on.
+          </p>
+        </description>
+        <result>Users will be able to understand to what degree a step is implemented and developers will be able to 
           see what remains to be done.</result>
-          
-          <fixme priority="enhancement">All fixmes to link to an issue tracker entry</fixme>
-        </step>
-
-        <step required="false">
-          <title>Add alternatives</title>
-          <description>
-            <p>Sometimes there will be alternative paths through each step. These can be described in an
-            <code>alternatives</code> element that allows free-form XDoc content. However, please be
-            careful, if an alternative is more than a simple variation you may want to consider a 
-            whole new use case for the alternative.</p>
-          </description>
-
-          <result>Minor variations in the path through a use case will be documented for your users.</result>
-        </step>
-        
-        <step required="false">
-          <title>Write Implementation Notes</title>
-          <description>
-            <p>Developer implementation notes for each of the steps should be added either when writing the
-            initial use case or later during the development phases of the use case. These notes are for technical readers
-            and are intended to help those who come after the initial author to get a starting point when inspecting how
-            a feature is implemented. It is not intended that these notes will contain full implementation details, only an
-            overview should be provided.</p>
-          </description>
-          
-          <result>A technical reader will be able to gain a baisc understanding of how each step is implemented in the 
+        <fixme priority="enhancement">
+          All fixmes to link to an issue tracker entry
+        </fixme>
+      </step>
+      <step required="false">
+        <title>Add alternatives</title>
+        <description>
+          <p>
+            Sometimes there will be alternative paths through each step. These
+            can be described in an <code>alternatives</code> element that allows
+            free-form XDoc content. However, please be careful, if an
+            alternative is more than a simple variation you may want to consider
+            a whole new use case for the alternative.
+          </p>
+        </description>
+        <result>Minor variations in the path through a use case will be documented for your users.</result>
+      </step>
+      <step required="false">
+        <title>Write Implementation Notes</title>
+        <description>
+          <p>
+            Developer implementation notes for each of the steps should be added
+            either when writing the initial use case or later during the
+            development phases of the use case. These notes are for technical
+            readers and are intended to help those who come after the initial
+            author to get a starting point when inspecting how a feature is
+            implemented. It is not intended that these notes will contain full
+            implementation details, only an overview should be provided.
+          </p>
+        </description>
+        <result>A technical reader will be able to gain a baisc understanding of how each step is implemented in the 
           application.</result>
-        </step>          
+      </step>
     </steps>
   </useCase>
-
   <useCase status="In Progress" owner="open">
     <title>Generate Use Case Documentation for Developers</title>
-
     <description>
-      <p>Generate a complete list of all use cases for a project in a format useful to 
-      developers of the application. This list is to include:</p>
-
+      <p>
+        Generate a complete list of all use cases for a project in a format
+        useful to developers of the application. This list is to include:
+      </p>
       <ul>
         <li>a description of the use case</li>
         <li>a summary of each of the steps involved</li>
         <li>full details of each of the steps</li>
         <li>a description of the expected outcome of each step</li>
         <li>details of common alternatives in each step</li>
-        <li>implementation notes for each step</li> 
+        <li>implementation notes for each step</li>
       </ul>
-
       <section>
         <title>Justification</title>
-        <p>A use case describes a unit of work. It is typically used in the design
-        stages of a software project, however, they can often be useful in creating
-        user documentaiton. Especially when they describe user interface functionality.</p>
-
-        <warning>Unfortunately this use case document does not currently cover all functions
-        of the plugin since this functionlaity was added after many other features. Whilst you
-        are exploring this feature, why not add a use case to the plugin and submit a patch
-        so that those coming after you can enjoy more complete documentation.</warning>
+        <p>
+          A use case describes a unit of work. It is typically used in the
+          design stages of a software project, however, they can often be useful
+          in creating user documentaiton. Especially when they describe user
+          interface functionality.
+        </p>
+        <warning>
+          Unfortunately this use case document does not currently cover all
+          functions of the plugin since this functionlaity was added after many
+          other features. Whilst you are exploring this feature, why not add a
+          use case to the plugin and submit a patch so that those coming after
+          you can enjoy more complete documentation.
+        </warning>
       </section>
     </description>
-
     <steps>
       <step>
         <title>Make HTTP request</title>
         <description>
           <p>
-            Request
-            http://localhost:8888/docs/developer/useCases.xml
+            Request http://localhost:8888/docs/developer/useCases.xml
           </p>
         </description>
         <result>
@@ -225,38 +245,48 @@
             An XDoc is created that describes the use cases
           </p>
         </result>
-
-        <fixme priority="High">Make the summary optional - already added 
-        $includeImplementationNotes parameter to stylesheet. Need to pass value form sitemap.</fixme>
-        
+        <fixme priority="High">
+          Make the summary optional - already added $includeImplementationNotes
+          parameter to stylesheet. Need to pass value form sitemap.
+        </fixme>
         <alternatives>
-          <p>Depending on what plugins are available within your running instance of Forrest you will
-          be able to request different output formats as per the usual Forrest usage. For example requesting
-          a http://localhost:8888/docs/developer/useCases.html will generate the HTML document, whilst
-          http://localhost:8888/docs/developer/useCases.pdf will generate the PDF document (as long
-          as you have the relevant plugins installed).</p>
+          <p>
+            Depending on what plugins are available within your running instance
+            of Forrest you will be able to request different output formats as
+            per the usual Forrest usage. For example requesting a
+            http://localhost:8888/docs/developer/useCases.html will generate the
+            HTML document, whilst
+            http://localhost:8888/docs/developer/useCases.pdf will generate the
+            PDF document (as long as you have the relevant plugins installed).
+          </p>
         </alternatives>
-
         <implementation>
           <description>
-            <p>The source document for use cases is, by default, called <code>useCases.xml</code> and is
-            located in the root of the projects xdocs directory.</p>
-
-            <p>The URL space <code>docs/**/useCases.xml</code> is reserved for the projectInfo plugin. A request to
-            /docs/developer/useCases.xml results in the useCases.xml file being translated into an XDoc as per
-            the usual forrest processing. See the input.xmap file fo this plugin,</p>
+            <p>
+              The source document for use cases is, by default, called
+              <code>useCases.xml</code> and is located in the root of the
+              projects xdocs directory.
+            </p>
+
+            <p>
+              The URL space <code>docs/**/useCases.xml</code> is reserved for
+              the projectInfo plugin. A request to /docs/developer/useCases.xml
+              results in the useCases.xml file being translated into an XDoc as
+              per the usual forrest processing. See the input.xmap file fo this
+              plugin,
+            </p>
           </description>
         </implementation>
       </step>
     </steps>
   </useCase>
-  
   <useCase status="In Progress" owner="open">
     <title>Generate Use Case Documentation for Users</title>
-
     <description>
-      <p>Generate a complete list of all use cases for a project. This list is to include:</p>
-
+      <p>
+        Generate a complete list of all use cases for a project. This list is to
+        include:
+      </p>
       <ul>
         <li>a description of the use case</li>
         <li>a summary of each of the steps involved</li>
@@ -264,27 +294,29 @@
         <li>a description of the expected outcome of each step</li>
         <li>details of common alternatives in each step</li>
       </ul>
-
       <section>
         <title>Justification</title>
-        <p>A use case describes a unit of work. It is typically used in the design
-        stages of a software project, however, they can often be useful in creating
-        user documentaiton. Especially when they describe user interface functionality.</p>
-
-        <warning>Unfortunately the use case document does not currently cover all functions
-        of the plugin since this functionlaity was added after many other features. Whilst you
-        are exploring this feature, why not add a use case to the plugin and submit a patch
-        so that those coming after you can enjoy more complete documentation.</warning>
+        <p>
+          A use case describes a unit of work. It is typically used in the
+          design stages of a software project, however, they can often be useful
+          in creating user documentaiton. Especially when they describe user
+          interface functionality.
+        </p>
+        <warning>
+          Unfortunately the use case document does not currently cover all
+          functions of the plugin since this functionlaity was added after many
+          other features. Whilst you are exploring this feature, why not add a
+          use case to the plugin and submit a patch so that those coming after
+          you can enjoy more complete documentation.
+        </warning>
       </section>
     </description>
-
     <steps>
       <step>
         <title>Make HTTP request</title>
         <description>
           <p>
-            Request
-            http://localhost:8888/docs/user/useCases.xml
+            Request http://localhost:8888/docs/user/useCases.xml
           </p>
         </description>
         <result>
@@ -292,46 +324,60 @@
             An XDoc is created that describes the use cases
           </p>
         </result>
-
-        <fixme priority="High">Enable the retrieval of a specific use case rather than all at once.</fixme>
-        <fixme priority="Low">Make the summary optional - there is a switch in the XSL for this, just need to pass a property
-        from the XMAP</fixme>
-        
+        <fixme priority="High">
+          Enable the retrieval of a specific use case rather than all at once.
+        </fixme>
+        <fixme priority="Low">
+          Make the summary optional - there is a switch in the XSL for this,
+          just need to pass a property from the XMAP
+        </fixme>
         <alternatives>
-          <p>Depending on what plugins are available within your running instance of Forrest you will
-          be able to request different output formats as per the usual Forrest usage. For example requesting
-          a http://localhost:8888/docs/user/useCases.html will generate the HTML document, whilst
-          http://localhost:8888/docs/user/useCases.pdf will generate the PDF document (as long
-          as you have the relevant plugins installed).</p>
+          <p>
+            Depending on what plugins are available within your running instance
+            of Forrest you will be able to request different output formats as
+            per the usual Forrest usage. For example requesting a
+            http://localhost:8888/docs/user/useCases.html will generate the HTML
+            document, whilst http://localhost:8888/docs/user/useCases.pdf will
+            generate the PDF document (as long as you have the relevant plugins
+            installed).
+          </p>
         </alternatives>
-
         <implementation>
           <description>
-            <p>The source document for use cases is, by default, called <code>useCases.xml</code> and is
-            located in the root of the projects xdocs directory.</p>
-
-            <p>The URL space <code>docs/**/useCases.xml</code> is reserved for the projectInfo plugin. A request to
-            /docs/user/useCases.xml results in the useCases.xml file being translated into an XDoc as per
-            the usual forrest processing, see input.xmap for more details.</p>
+            <p>
+              The source document for use cases is, by default, called
+              <code>useCases.xml</code> and is located in the root of the
+              projects xdocs directory.
+            </p>
+
+            <p>
+              The URL space <code>docs/**/useCases.xml</code> is reserved for
+              the projectInfo plugin. A request to /docs/user/useCases.xml
+              results in the useCases.xml file being translated into an XDoc as
+              per the usual forrest processing, see input.xmap for more details.
+            </p>
           </description>
         </implementation>
       </step>
     </steps>
   </useCase>
-  
   <useCase status="In Progress">
     <title>Generate a Functionality Matrix</title>
     <description>
-      <p>If a use case document is correcly marked up with <code>fixme</code> elements it is possible
-      to create a functionality matrix for each use case. This will show how complete the implementation
-      of a use case is.</p>
-      
-      <p>A table can be created which shows each of the steps in a use case, each step can be given a
-      count for the bumber of fixme items outstanding on each of the steps. Furthermore, since each
-      <code>fixme</code> is given a priority we can clearly indicate which use cases are operational an 
-      hich are not.</p>
+      <p>
+        If a use case document is correcly marked up with <code>fixme</code>
+        elements it is possible to create a functionality matrix for each use
+        case. This will show how complete the implementation of a use case is.
+      </p>
+
+      <p>
+        A table can be created which shows each of the steps in a use case, each
+        step can be given a count for the bumber of fixme items outstanding on
+        each of the steps. Furthermore, since each <code>fixme</code> is given a
+        priority we can clearly indicate which use cases are operational an hich
+        are not.
+      </p>
     </description>
-    
     <steps>
       <step>
         <title>Make HTTP request</title>
@@ -343,34 +389,45 @@
         </description>
         <result>
           <p>
-            An XDoc is created that lists the steps in each use case and identifies the status
-            of each use case.
+            An XDoc is created that lists the steps in each use case and
+            identifies the status of each use case.
           </p>
         </result>
-
-        <fixme priority="Blocker">Not Implemented Yet - although the user and dev use case documents
-        do show the status of each step in the details table and implementation notes.</fixme>
-        
+        <fixme priority="Blocker">
+          Not Implemented Yet - although the user and dev use case documents do
+          show the status of each step in the details table and implementation
+          notes.
+        </fixme>
         <alternatives>
-          <p>Depending on what plugins are available within your running instance of Forrest you will
-          be able to request different output formats as per the usual Forrest usage. For example requesting
-          a http://localhost:8888/docs/developer/featureMatrix/useCases.html will generate the HTML document, whilst
-          http://localhost:8888/docs/developer/featureMatrix/useCases.pdf will generate the PDF document (as long
-          as you have the relevant plugins installed).</p>
+          <p>
+            Depending on what plugins are available within your running instance
+            of Forrest you will be able to request different output formats as
+            per the usual Forrest usage. For example requesting a
+            http://localhost:8888/docs/developer/featureMatrix/useCases.html
+            will generate the HTML document, whilst
+            http://localhost:8888/docs/developer/featureMatrix/useCases.pdf will
+            generate the PDF document (as long as you have the relevant plugins
+            installed).
+          </p>
         </alternatives>
-
         <implementation>
           <description>
-            <p>The source document for use cases is, by default, called <code>useCases.xml</code> and is
-            located in the root of the projects xdocs directory.</p>
-
-            <p>The URL space <code>docs/**/useCases.xml</code> is reserved for the projectInfo plugin. A request to
-            /docs/developer/featureMatrix/useCases.xml results in the useCases.xml file being translated into an XDoc as per
-            the usual forrest processing. See the input.xmap file fo this plugin,</p>
+            <p>
+              The source document for use cases is, by default, called
+              <code>useCases.xml</code> and is located in the root of the
+              projects xdocs directory.
+            </p>
+
+            <p>
+              The URL space <code>docs/**/useCases.xml</code> is reserved for
+              the projectInfo plugin. A request to
+              /docs/developer/featureMatrix/useCases.xml results in the
+              useCases.xml file being translated into an XDoc as per the usual
+              forrest processing. See the input.xmap file fo this plugin,
+            </p>
           </description>
         </implementation>
       </step>
     </steps>
   </useCase>
 </useCases>
-

Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/index.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/index.xml?view=diff&rev=526968&r1=526967&r2=526968
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/index.xml (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/index.xml Mon Apr  9 17:20:08 2007
@@ -16,168 +16,198 @@
   limitations under the License.
 -->
 <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
-<document> 
-  <header> 
-    <title>Welcome to the org.apache.forrest.plugin.input.projectInfo Plugin</title> 
-  </header> 
-  <body> 
+<document>
+  <header>
+    <title>Welcome to the org.apache.forrest.plugin.input.projectInfo Plugin</title>
+  </header>
+  <body>
     <section>
       <title>Apache Forrest - org.apache.forrest.plugin.input.projectInfo Plugin</title>
-      <p>This plugin generates project info from various configuration files.</p>
+      <p>
+        This plugin generates project info from various configuration files.
+      </p>
     </section>
-    
     <section>
       <title>Changes</title>
-      <p>By maintaining a file called <code>status.xml</code> you can manage a list
-      changes to your code base. This list can then be generated as a changes 
-      page and/or an RSS feed of those changes. For example, here are the 
-      <a href="changes.html">changes</a> for this plugin, here is the same
-      list of changes as an <a href="changes.rss">RSS feed</a>.</p>
-      
-      <p>It's possible to limit the displayed changes to a particular version
-      number as well. For example, here are the changes for 
-      <a href="changes_0.1.html">version 0.1</a> of this plugin (and
-      as an <a href="changes_0.1.rss">RSS feed</a>).</p>
-      
-      <p>If you want to only retrieve the changes for the most recent version
-      of the project then you can do that too. Here are the changes in the 
-      <a href="changes_current.html">current development version</a> of this 
-      plugin (and once more as an <a href="changes_current.rss">RSS feed</a>).</p>
-      
+      <p>
+        By maintaining a file called <code>status.xml</code> you can manage a
+        list changes to your code base. This list can then be generated as a
+        changes page and/or an RSS feed of those changes. For example, here are
+        the <a href="changes.html">changes</a> for this plugin, here is the same
+        list of changes as an <a href="changes.rss">RSS feed</a>.
+      </p>
+      <p>
+        It's possible to limit the displayed changes to a particular version
+        number as well. For example, here are the changes for
+        <a href="changes_0.1.html">version 0.1</a> of this plugin (and as an
+        <a href="changes_0.1.rss">RSS feed</a>).
+      </p>
+      <p>
+        If you want to only retrieve the changes for the most recent version of
+        the project then you can do that too. Here are the changes in the
+        <a href="changes_current.html">current development version</a> of this
+        plugin (and once more as an <a href="changes_current.rss">RSS feed</a>).
+      </p>
     </section>
-    
     <section>
       <title>SVN Changes</title>
-      <p>You can generate as well the changes with svn. For this you need to 
-        point forrest to the directory where the svn logs are. The defaut is 
-        set to <code>{properties:content}svn-log/</code> and you can change it by 
-        setting <code>projectInfo.svn.log.dir</code> in your project 
-        locationmap.</p>
-      <p>We created a log file for demonstration with the following command:</p>
+      <p>
+        You can generate as well the changes with svn. For this you need to
+        point forrest to the directory where the svn logs are. The defaut is set
+        to <code>{properties:content}svn-log/</code> and you can change it by
+        setting <code>projectInfo.svn.log.dir</code> in your project
+        locationmap.
+      </p>
+      <p>
+        We created a log file for demonstration with the following command:
+      </p>
       <source>
 cd forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo
 svn log --xml -v . > src/documentation/content/svn-log/log.svn.xml</source>
-      <p>This file reflect all changes that have been done to this plugin. You 
-        can see the result <a href="log.svn.html">log.svn.html</a>.</p>
-      <p>You see the only context we have definied is "code". This is 
-        controlled by a mapper file. The defaut is set to 
-        <code>{properties:content}path-to-context.xml</code> and you can change it 
-        by setting <code>projectInfo.svn.mapper</code> in your project 
-        locationmap.</p>
-      <source><![CDATA[<paths>
+      <p>
+        This file reflect all changes that have been done to this plugin. You
+        can see the result <a href="log.svn.html">log.svn.html</a>.
+      </p>
+      <p>
+        You see the only context we have definied is "code". This is controlled
+        by a mapper file. The defaut is set to
+        <code>{properties:content}path-to-context.xml</code> and you can change
+        it by setting <code>projectInfo.svn.mapper</code> in your project
+        locationmap.
+      </p>
+      <source>
+<![CDATA[<paths>
   <path context="Code">/forrest</path>
-</paths>]]></source>
-      <p>If the log file is growing, one is looking into splitting the file. 
-        You can find out the revision number of the first and last commit of a 
-        month within the log by requesting <a 
-        href="log.svn-revision.xml">log.svn-revision.xml</a>.</p>
-      <p>We implemented as well a small svn cli output to generate log files 
-        per month <a href="log.svn-sh.xml">log.svn-sh.xml</a>. The defaut url is set to 
-        <code>http://svn.myHost.org/repos</code> and you can change it 
-        by setting <code>project.svn.url</code> in your project 
-        locationmap.</p>
+</paths>]]>
+      </source>
+      <p>
+        If the log file is growing, one is looking into splitting the file. You
+        can find out the revision number of the first and last commit of a month
+        within the log by requesting
+        <a 
+        href="log.svn-revision.xml">log.svn-revision.xml</a>.
+      </p>
+      <p>
+        We implemented as well a small svn cli output to generate log files per
+        month <a href="log.svn-sh.xml">log.svn-sh.xml</a>. The defaut url is set
+        to <code>http://svn.myHost.org/repos</code> and you can change it by
+        setting <code>project.svn.url</code> in your project locationmap.
+      </p>
     </section>
-    
     <section>
       <title>To Do List</title>
-      <p>The status.xml file can also be used to manage a list of todo items for
-      the community. For example, here is a 
-      <a href="todo.html">psuedo todo list</a> for this plugin (our real todo list
-      is managed in an Issue Tracker, one day we hope to add support for that
-      here too).</p>
+      <p>
+        The status.xml file can also be used to manage a list of todo items for
+        the community. For example, here is a <a href="todo.html">psuedo todo
+        list</a> for this plugin (our real todo list is managed in an Issue
+        Tracker, one day we hope to add support for that here too).
+      </p>
     </section>
-    
     <section>
       <title>Release Notes</title>
-      <p>To produce release notes you must maintain a <code>status.xml</code> file
-      for your project and request a page with an URL such as 
-      <code>http://domain.com/releaseNotes_0.7-dev.html</code>, this will be produce
-      the release notes for 0.7-dev.</p>
-      
-      <p>If the version number ends with <code>-dev</code> a warning will be included 
-      in the generated page, informing the reader that it is a development version and
-      therefore the list of changes is incomplete.</p>
-
-      <p>For a <code>status.xml</code> <code>action</code> toi be included in the 
-      release notes it must have an attribute <code>importance="high"</code>. When
-      writing actions in <code>status.xml</code> you should write them with the
-      following two questions in mind:</p>
-
+      <p>
+        To produce release notes you must maintain a <code>status.xml</code>
+        file for your project and request a page with an URL such as
+        <code>http://domain.com/releaseNotes_0.7-dev.html</code>, this will be
+        produce the release notes for 0.7-dev.
+      </p>
+      <p>
+        If the version number ends with <code>-dev</code> a warning will be
+        included in the generated page, informing the reader that it is a
+        development version and therefore the list of changes is incomplete.
+      </p>
+      <p>
+        For a <code>status.xml</code> <code>action</code> toi be included in the
+        release notes it must have an attribute <code>importance="high"</code>.
+        When writing actions in <code>status.xml</code> you should write them
+        with the following two questions in mind:
+      </p>
       <ul>
         <li>should it be importance="high"?</li>
         <li>will the action read correctly in the release notes?</li>
       </ul>
-      
-      <p>The introductory text in the release notes comes from the (optional) 
-      element <code>notes</code> (a child of the <code>release</code> element).</p>
-      
-      <note>The same options with respect to retrieveing specific versions of the
-      release notes are available as with the changes feature (discuseed above).</note>
+      <p>
+        The introductory text in the release notes comes from the (optional)
+        element <code>notes</code> (a child of the <code>release</code>
+        element).
+      </p>
+      <note>
+        The same options with respect to retrieveing specific versions of the
+        release notes are available as with the changes feature (discuseed
+        above).
+      </note>
     </section>
-    
     <section>
       <title>Developers List</title>
-      <p>The status.xml file can also contain a list of committers and 
-      contributors which can, optionally, be displayed as part of the changes file.</p>
-      
-      <p>At the time of writing this functionality is quite minimal, being just
-      a list of authors at the end of the changes document. However, in future 
-      releases it is intended that a more configurable output will be 
-      available.</p>
-      
+      <p>
+        The status.xml file can also contain a list of committers and
+        contributors which can, optionally, be displayed as part of the changes
+        file.
+      </p>
+      <p>
+        At the time of writing this functionality is quite minimal, being just a
+        list of authors at the end of the changes document. However, in future
+        releases it is intended that a more configurable output will be
+        available.
+      </p>
       <section>
         <title>Contributor List</title>
-        <p>It may be that some items have been contributed by authors other
-        than those listed in the developer list. These are accredited in a
-        <code>due-to</code> attribute of the <code>action</code> element in
-        status.xml. A list of this contributors is made available at the
-        end of the release notes for each version.</p>
+        <p>
+          It may be that some items have been contributed by authors other than
+          those listed in the developer list. These are accredited in a
+          <code>due-to</code> attribute of the <code>action</code> element in
+          status.xml. A list of this contributors is made available at the end
+          of the release notes for each version.
+        </p>
       </section>
     </section>
-    
-    
     <section>
       <title>Use Cases</title>
-      <p>Projects can manage a document describing various use cases for the
-      application. These use cases can then be used to generate useful developer
-      and user documentation, as well as helping to track the implementation
-      status of features.</p>
-      
-      <p>Some of the uses of this feature are:</p>
-
+      <p>
+        Projects can manage a document describing various use cases for the
+        application. These use cases can then be used to generate useful
+        developer and user documentation, as well as helping to track the
+        implementation status of features.
+      </p>
+      <p>
+        Some of the uses of this feature are:
+      </p>
       <ul>
         <li>during design - what needs to be done</li>
         <li>during development - what needs to be done/has been done</li>
         <li>during use - user documentation of common activities</li>
         <li>during maintenance - how something was implemented</li>
       </ul>
-      
-      <p>To see some examples take a look at:</p>
-      
+      <p>
+        To see some examples take a look at:
+      </p>
       <ul>
         <li><a href="docs/user/useCases/all.html">User Docs</a> for the Use Case features of this plugin</li>
         <li><a href="docs/developer/useCases/all.html">Developer Docs</a> for the Use Case features of this plugin</li>
       </ul>
     </section>
-    
     <section>
       <title>Experimental Features</title>
-      <p>These features are operational, however, they are not fully developed and
-      may change considerably before they become part of the official feature set.
-      You can use them, but be prepared for changes, possibly without warning. If you
-      do use these features we recomend that you join the developers mailing list.</p>
-      
+      <p>
+        These features are operational, however, they are not fully developed
+        and may change considerably before they become part of the official
+        feature set. You can use them, but be prepared for changes, possibly
+        without warning. If you do use these features we recomend that you join
+        the developers mailing list.
+      </p>
       <section>
         <title>Configuration</title>
-        <p>This plugin uses an experimental properties system that allows plugins
-        to expose configuration information to the project. It is likely that at
-        least some of these configuration options will eventually move into Dispatcher
-        based contracts. In the meantime, you can use this config system to control
-        some aspects of the display information. See the 
-        <code>forrest.properties.xml</code> file for a description of the config
-        options available. To alter the configuration simply override these
-        properties in your projects <code>forrest.properties.xml</code> file.</p>
-        
+        <p>
+          This plugin uses an experimental properties system that allows plugins
+          to expose configuration information to the project. It is likely that
+          at least some of these configuration options will eventually move into
+          Dispatcher based contracts. In the meantime, you can use this config
+          system to control some aspects of the display information. See the
+          <code>forrest.properties.xml</code> file for a description of the
+          config options available. To alter the configuration simply override
+          these properties in your projects <code>forrest.properties.xml</code>
+          file.
+        </p>
       </section>
     </section>
   </body>

Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/site.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/site.xml?view=diff&rev=526968&r1=526967&r2=526968
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/site.xml (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/site.xml Mon Apr  9 17:20:08 2007
@@ -15,7 +15,6 @@
   See the License for the specific language governing permissions and
   limitations under the License.
 -->
-
 <!--
 Forrest site.xml
 
@@ -29,12 +28,10 @@
 
 See http://forrest.apache.org/docs/linking.html for more info
 -->
-
 <site label="org.apache.forrest.plugin.input.projectInfo" href="" tab="" 
   xmlns="http://apache.org/forrest/linkmap/1.0"
   xmlns:xi="http://www.w3.org/2001/XInclude"
   >
-
   <about label="About">
     <index label="Index" href="index.html" description="Welcome to org.apache.forrest.plugin.input.projectInfo"/>
     <release label="Release Notes">
@@ -43,10 +40,8 @@
     </release>
     <changes label="Changes" href="changes.html" description="History of Changes" />
     <todo label="Todo" href="todo.html" description="Todo List" />
-      
     <forrestPlugins label="Plugins Index" href="site:forrest/plugins" description="Index of Forrest Plugins"/>
   </about>
-  
   <docs label="Documentation" href="docs/">
     <user label="User" href="user/useCases/">
       <useCases label="Change Log" href="changeLogFeatures.html"/>
@@ -57,18 +52,16 @@
       <useCases label="Change Log" href="changeLogFeatures.html"/>
       <useCases label="Use Cases" href="useCaseFeatures.html"/>
       <all label="All Cases" href="all.html"/>
-      <!-- In development: <featureMatrix label="Feature Matrix" href="featureMatrix/useCases.html"/> -->
+<!-- In development: <featureMatrix label="Feature Matrix" href="featureMatrix/useCases.html"/> -->
     </developer>
   </docs>
-  
-  <!--
+<!--
   The href must be wholesite.html/pdf  You can change the labels and node names
   <all label="All">
     <whole_site_html label="Whole Site HTML" href="wholesite.html"/>
     <whole_site_pdf label="Whole Site PDF" href="wholesite.pdf"/>
   </all>
   -->
-
   <external-refs>
     <forrest href="http://forrest.apache.org/">
       <changes href="changes.html"/>
@@ -79,5 +72,4 @@
       <plugins href="docs/plugins"/>
     </forrest>
   </external-refs>
-
 </site>

Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/tabs.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/tabs.xml?view=diff&rev=526968&r1=526967&r2=526968
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/tabs.xml (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/content/xdocs/tabs.xml Mon Apr  9 17:20:08 2007
@@ -16,13 +16,11 @@
   limitations under the License.
 -->
 <!DOCTYPE tabs PUBLIC "-//APACHE//DTD Cocoon Documentation Tab V1.1//EN" "http://forrest.apache.org/dtd/tab-cocoon-v11.dtd">
-
 <tabs software="MyProj"
   title="MyProj"
   copyright="Foo"
   xmlns:xlink="http://www.w3.org/1999/xlink">
-
-  <!-- The rules for tabs are:
+<!-- The rules for tabs are:
     @dir will always have '/@indexfile' added.
     @indexfile gets appended to @dir if the tab is selected. Defaults to 'index.html'
     @href is not modified unless it is root-relative and obviously specifies a
@@ -32,12 +30,10 @@
    Tabs can be embedded to a depth of two. The second level of tabs will only 
     be displayed when their parent tab is selected.    
   -->
-
   <tab id="plugins" label="Forrest Plugins" href="http://forrest.apache.org/pluginDocs" indexfile="index.html"/>
   <tab id="" label="Home" dir="" indexfile="index.html"/>
-  <!-- Add new tabs here, eg:
+<!-- Add new tabs here, eg:
   <tab label="How-Tos" dir="community/howto/"/>
   <tab label="XML Site" dir="xml-site/"/>
   -->
-
 </tabs>

Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/skinconf.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/skinconf.xml?view=diff&rev=526968&r1=526967&r2=526968
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/skinconf.xml (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/skinconf.xml Mon Apr  9 17:20:08 2007
@@ -15,16 +15,13 @@
   See the License for the specific language governing permissions and
   limitations under the License.
 -->
-
 <!DOCTYPE skinconfig PUBLIC "-//APACHE//DTD Skin Configuration V0.7-1//EN" "http://forrest.apache.org/dtd/skinconfig-v07-1.dtd"
 [
   <!ENTITY skinconf-common PUBLIC "-//Apache Forrest//ENTITIES Skin Configuration common plugins V0.7-1//EN" "">
 ]>
-
 <skinconfig>
   &skinconf-common;
 
   <project-name>Plugin: projectInfo input</project-name>
   <project-description>org.apache.forrest.plugin.input.projectInfo plugin for Apache Forrest</project-description>
-
 </skinconfig>

Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/translations/ProjectInfoMessages_en.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/translations/ProjectInfoMessages_en.xml?view=diff&rev=526968&r1=526967&r2=526968
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/translations/ProjectInfoMessages_en.xml (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/translations/ProjectInfoMessages_en.xml Mon Apr  9 17:20:08 2007
@@ -16,5 +16,5 @@
   limitations under the License.
 -->
 <catalogue>
-  <!-- To be done - actually, not necessary because the code already contains english text -->
+<!-- To be done - actually, not necessary because the code already contains english text -->
 </catalogue>

Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/translations/ProjectInfoMessages_es.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/translations/ProjectInfoMessages_es.xml?view=diff&rev=526968&r1=526967&r2=526968
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/translations/ProjectInfoMessages_es.xml (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/src/documentation/translations/ProjectInfoMessages_es.xml Mon Apr  9 17:20:08 2007
@@ -16,6 +16,6 @@
   limitations under the License.
 -->
 <catalogue>
-  <!-- FIXME - to be translated by a spanish people ... -->
-  <!-- don't start from scratch, the french messages already exist ! -->
+<!-- FIXME - to be translated by a spanish people ... -->
+<!-- don't start from scratch, the french messages already exist ! -->
 </catalogue>

Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml?view=diff&rev=526968&r1=526967&r2=526968
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/status.xml Mon Apr  9 17:20:08 2007
@@ -17,43 +17,42 @@
 -->
 <!DOCTYPE status PUBLIC "-//APACHE//DTD Status V1.3//EN" "status-v13.dtd">
 <status>
-
   <developers>
-    <!-- FIFO order -->
+<!-- FIFO order -->
     <person name="Ross Gardler" email="rgardler@apache.org" id="RDG"/>
-    <person name="David Crossley" email="crossley@apache.org" id="DC"/>    
+    <person name="David Crossley" email="crossley@apache.org" id="DC"/>
     <person name="Cyriaque Dupoirieux" email="Cyriaque.Dupoirieux@apache.org" id="CD"/>
-    <person name="Thorsten Scherler" email="thorsten@apache.org" id="TS"/>    
+    <person name="Thorsten Scherler" email="thorsten@apache.org" id="TS"/>
     <person name="Juan Jose Pablos"     email="cheche@apache.org"       id="jjp" />
     <person name="Volunteer needed" email="dev@forrest.apache.org" id="open"/>
   </developers>
-
-  <!-- Define here the Title of the Context you want to display in the Changes pages.
+<!-- Define here the Title of the Context you want to display in the Changes pages.
        id = the context value of actions
        title = Title of the Context
-  -->  
+  -->
   <contexts>
-   <context id="code" title="Changes to the Code Base"/>
-   <context id="docs" title="Changes to Documentation"/>
-   <context id="admin" title="Changes to Project Administration"/>
-   <context id="design" title="Changes to Design"/>
-   <context id="build" title="Changes to Build"/>
-  </contexts> 
-
+    <context id="code" title="Changes to the Code Base"/>
+    <context id="docs" title="Changes to Documentation"/>
+    <context id="admin" title="Changes to Project Administration"/>
+    <context id="design" title="Changes to Design"/>
+    <context id="build" title="Changes to Build"/>
+  </contexts>
   <changes>
-    <!-- Add new releases here -->
+<!-- Add new releases here -->
     <release version="0.2-dev" date="not-released">
       <introduction>
-        <p>See also the main
-          <link href="ext:forrest/changes">changes</link>
+        <p>
+          See also the main <link href="ext:forrest/changes">changes</link>
           related to all plugins.
         </p>
       </introduction>
       <notes>
         <section>
           <title>pluginInfo 0.2</title>
-          <p>This plugin provides various mechanisms for extracting and
-          displaying information about one or more projects.</p>
+          <p>
+            This plugin provides various mechanisms for extracting and
+            displaying information about one or more projects.
+          </p>
         </section>
       </notes>
       <action type="update" context="code" dev="RDG" fixes-bug="FOR-977">
@@ -178,18 +177,21 @@
         Add projectDetails page using the DOAP.xml descriptor.
       </action>
     </release>
-    
     <release version="0.1" date="25 May 2005">
       <notes>
         <section>
-            <title>PluginInfo 0.1</title>
-            <p>This plugin encapsulates and extends functionality that was originally in
-            Forrest Core. With the advent of plugins in Forrest 0.7 we extracted the
-            functionality for generating changes.xml and todo.xml from the status.xml file. It is 
-            intended that this functionality be extended further within this plugin.</p>
-            
-            <p>In fact, we have already extended the functionality in a couple of important
-            ways. See the changelog for more details.</p>
+          <title>PluginInfo 0.1</title>
+          <p>
+            This plugin encapsulates and extends functionality that was
+            originally in Forrest Core. With the advent of plugins in Forrest
+            0.7 we extracted the functionality for generating changes.xml and
+            todo.xml from the status.xml file. It is intended that this
+            functionality be extended further within this plugin.
+          </p>
+          <p>
+            In fact, we have already extended the functionality in a couple of
+            important ways. See the changelog for more details.
+          </p>
         </section>
       </notes>
       <action dev="RDG" type="add" context="code" importance="high">
@@ -238,7 +240,6 @@
       </action>
     </release>
   </changes>
-
   <todo>
     <actions priority="high">
       <action context="code" dev="open" type="add">
@@ -255,16 +256,12 @@
         Create an icon for and action of type "refactor".
       </action>
     </actions>
-    
     <actions priority="medium">
       <action context="admin" dev="open" type="update">
         Move DTD's to this plugin from core (depends on having a catalog 
         extension mechanism for plugins).
       </action>
     </actions>
-    
-    
-    
     <actions priority="low">
       <action context="admin" dev="open" type="update">
         Look at the make sourcetype actions for changes in sitemap.xmap and
@@ -275,5 +272,4 @@
       </action>
     </actions>
   </todo>
-
 </status>

Modified: forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/svnHelper.xmap
URL: http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/svnHelper.xmap?view=diff&rev=526968&r1=526967&r2=526968
==============================================================================
--- forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/svnHelper.xmap (original)
+++ forrest/trunk/plugins/org.apache.forrest.plugin.input.projectInfo/svnHelper.xmap Mon Apr  9 17:20:08 2007
@@ -59,4 +59,4 @@
       </map:match>
     </map:pipeline>
   </map:pipelines>
-</map:sitemap>
\ No newline at end of file
+</map:sitemap>



Mime
View raw message