Author: ekoneil
Date: Fri Sep  9 08:33:52 2005
New Revision: 279796

URL: http://svn.apache.org/viewcvs?rev=279796&view=rev
Log:
Some additions to the Controls doc including how to add Controls infrastructure 
to SCM.

BB: self
Test: build.dist pass


Modified:
    
beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/overview.xml
    
beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/projects.xml

Modified: 
beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/overview.xml
URL: 
http://svn.apache.org/viewcvs/beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/overview.xml?rev=279796&r1=279795&r2=279796&view=diff
==============================================================================
--- 
beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/overview.xml
 (original)
+++ 
beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/overview.xml
 Fri Sep  9 08:33:52 2005
@@ -54,16 +54,16 @@
         trader.remove();
 }</source>
                 <p>A common solution to this problem is often to 
-                                       task the J2EE professional developer 
with constructing facades or custom 
-                                       frameworks that hide some of the 
underlying complexity of the resource access 
-                                       mechanisms and provides appropriate 
guarantees that system resources 
-                                       (connections, sessions, handles, etc) 
are utilized properly. But constructing 
-                                       these intermediate abstractions is an 
inefficient use of 
-                                       (often scarce and expensive) 
-                                       systems development resources. 
Depending upon the "thickness" of the intermediate 
-                                       abstractions, 
-                                       this approach can also have performance 
or application deployment footprint 
-                                       implications. </p>
+                    task the J2EE professional developer with constructing 
facades or custom 
+                    frameworks that hide some of the underlying complexity of 
the resource access 
+                    mechanisms and provides appropriate guarantees that system 
resources 
+                    (connections, sessions, handles, etc) are utilized 
properly. But constructing 
+                    these intermediate abstractions is an inefficient use of 
+                    (often scarce and expensive) 
+                    systems development resources. Depending upon the 
"thickness" of the intermediate 
+                    abstractions, 
+                    this approach can also have performance or application 
deployment footprint 
+                    implications. </p>
             </section>
             <section>
                 <title>Solution: Controls: A Unified Client Programming Model 
</title>
@@ -94,9 +94,7 @@
                 <p>
                 Using a Control that exposes the Trader EJB in the earlier 
example, the code to invoke the buy() method on this bean can become:
                 </p>
-<source>
-    traderControl.buy();
-</source>
+<source>traderControl.buy();</source>
                 <p>The TraderBean Control fully encapsulates the JNDI lookup 
as well as the home/bean interface operations needed to get an 
                    instance of the Trader EJB and invoke the buy() method on 
it, and exposes the JNDI name of the EJB as a property that can 
                    be set either programmatic, via metadata, or using an 
external deployment descriptor.
@@ -352,9 +350,9 @@
 Contextual services can also define an event model, so contextual services can 
also declare and fire events on Controls that have registered in interest. As 
an example, a basic ControlContext contextual service is provided as part of 
the base Controls architecture. This contextual service provides common 
services for Controls, such as access to properties, as well as a set of 
lifecycle events for Controls.
 </p>
 <p>The discovery and implementation model for Controls Contextual Services 
will be based upon the 
-       JavaBeans Runtime Containment and Services Protocol (Glasgow) 
-       (<a 
href="http://java.sun.com/products/javabeans/glasgow/#containment";>http://java.sun.com/products/javabeans/glasgow/#containment</a>)
 
-       that is already shipping as part of J2SE.</p>
+    JavaBeans Runtime Containment and Services Protocol (Glasgow) 
+    (<a 
href="http://java.sun.com/products/javabeans/glasgow/#containment";>http://java.sun.com/products/javabeans/glasgow/#containment</a>)
 
+    that is already shipping as part of J2SE.</p>
             </section>
             <section>
                 <title>Resource Management</title>

Modified: 
beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/projects.xml
URL: 
http://svn.apache.org/viewcvs/beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/projects.xml?rev=279796&r1=279795&r2=279796&view=diff
==============================================================================
--- 
beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/projects.xml
 (original)
+++ 
beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/projects.xml
 Fri Sep  9 08:33:52 2005
@@ -82,5 +82,56 @@
             have been built.
             </p>
         </section>
+        <section id="sourceControl">
+            <title>Source Control</title>
+            <p>
+            In order to correctly add a Controls project to source control, 
several resources need to be checked in.  Both required
+            and optional resources are listed in the table below:
+            </p>
+            <table>
+                <tr><th>Name</th><th>JAR 
file</th><th>Version</th><th>Required</th></tr>
+                <tr>
+                    <td>Beehive Controls</td>
+                    <td>beehive-controls.jar</td>
+                    <td><em>distribution</em></td>
+                    <td>Yes</td>
+                </tr>
+                <tr>
+                    <td>Beehive EJB Control</td>
+                    <td>beehive-ejb-control.jar</td>
+                    <td><em>distribution</em></td>
+                    <td>Yes; if using EJB control functionality</td>
+                </tr>
+                <tr>
+                    <td>Beehive JDBC Control</td>
+                    <td>beehive-jdbc-control.jar</td>
+                    <td><em>distribution</em></td>
+                    <td>Yes; if using JDBC control functionality</td>
+                </tr>
+                <tr>
+                    <td>Beehive JMS Control</td>
+                    <td>beehive-jms-control.jar</td>
+                    <td><em>distribution</em></td>
+                    <td>Yes; if using JMS control functionality</td>
+                </tr>
+                <tr>
+                    <td>Commons Codec</td>
+                    <td>commons-codec-1.3.jar</td>
+                    <td><em>distribution</em></td>
+                    <td>Yes</td>
+                </tr>
+                <tr>
+                    <td>Jakarta Velocity-dep</td>
+                    <td>velocity-dep-1.4.jar</td>
+                    <td><em>distribution</em></td>
+                    <td>Yes; required at build time</td>
+                </tr>
+            </table>
+            <p>
+            The Velocity JARs are used by Controls for code-generation and do 
not need to be committed to SCM if they are
+            referenced from a Beehive distribution.  They are not required at 
runtime.  The system control JARs are needed
+            only if they are used in an application.
+            </p>
+        </section>
     </body>
 </document>


Reply via email to