avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From blorit...@apache.org
Subject cvs commit: avalon-excalibur/util build.xml
Date Fri, 07 Feb 2003 17:56:32 GMT
bloritsch    2003/02/07 09:56:32

  Modified:    .        forrest.properties
               fortress/src/xdocs cli.xml design-notes.xml features.xml
                        getting-started.xml index.xml
                        lifecycle-extensions.xml servlet.xml swing.xml
               util     build.xml
  Log:
  forrestize fortress
  
  Revision  Changes    Path
  1.2       +1 -1      avalon-excalibur/forrest.properties
  
  Index: forrest.properties
  ===================================================================
  RCS file: /home/cvs/avalon-excalibur/forrest.properties,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- forrest.properties	7 Feb 2003 16:38:19 -0000	1.1
  +++ forrest.properties	7 Feb 2003 17:56:31 -0000	1.2
  @@ -13,7 +13,7 @@
   project.skin=avalon-tigris
   #project.skin=krysalis-site
   
  -project.site-dir=target/docs
  +project.site-dir=build/docs
   
   ##############
   # layout properties
  
  
  
  1.3       +4 -2      avalon-excalibur/fortress/src/xdocs/cli.xml
  
  Index: cli.xml
  ===================================================================
  RCS file: /home/cvs/avalon-excalibur/fortress/src/xdocs/cli.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- cli.xml	7 Feb 2003 16:08:12 -0000	1.2
  +++ cli.xml	7 Feb 2003 17:56:31 -0000	1.3
  @@ -1,4 +1,5 @@
   <?xml version="1.0"?>
  +<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
   
   <document>
     <header>
  @@ -8,7 +9,8 @@
       </authors>
     </header>
     <body>
  -    <s1 title="Command Line Tools">
  +    <section>
  +      <title>Command Line Tools"</title>
         <p>
           Command Line Tools are the class of tools or applications that are
           run from a command shell.  Typical examples are the ANT build tool,
  @@ -45,6 +47,6 @@
           portions are not likely to change at all.  What will change is how
           you plan on interacting with your container.
         </p>
  -    </s1>
  +    </section>
     </body>
   </document>
  
  
  
  1.3       +20 -13    avalon-excalibur/fortress/src/xdocs/design-notes.xml
  
  Index: design-notes.xml
  ===================================================================
  RCS file: /home/cvs/avalon-excalibur/fortress/src/xdocs/design-notes.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- design-notes.xml	4 Feb 2003 20:00:42 -0000	1.2
  +++ design-notes.xml	7 Feb 2003 17:56:31 -0000	1.3
  @@ -1,4 +1,5 @@
   <?xml version="1.0"?>
  +<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
   
   <document>
     <header>
  @@ -8,7 +9,8 @@
       </authors>
     </header>
     <body>
  -    <s1 title="Fortress Design Notes">
  +    <section>
  +      <title>Fortress Design Notes</title>
         <p>
           Fortress has two design goals: facilitate heirarchical containers and
           take management functions outside of the critical path. The critical
  @@ -18,7 +20,8 @@
           also assumes that there is one root container, although it does not
           force that upon the developer.
         </p>
  -      <s2 title="Asynchronous Management">
  +      <section>
  +        <title>Asynchronous Management</title>
           <p>
             Due to the long startup times of certain components like the
             DataSourceComponent ECM based code suffered from slowness. The problem
  @@ -43,8 +46,9 @@
             critical path (the code that actually does the work of the system) is
             not delayed unnecessarily.
           </p>
  -      </s2>
  -      <s2 title="Hierarchical Containers">
  +      </section>
  +      <section>
  +        <title>Hierarchical Containers</title>
           <p>
             Part of the design concept for Fortress heirarchical containers is to
             use a ContainerManager to make sure all the necessary services are set
  @@ -70,7 +74,8 @@
             the ContainerManager to set up any missing kernel services, you can
             get the Container from the ContainerManager and start using it.
           </p>
  -        <s3 title="Why Not Set Up a Standard Container Interface?">
  +	<section>
  +	  <title>Why Not Set Up a Standard Container Interface?</title>
             <p>
               Each domain has its own needs. For instance, Cocoon is based on a
               request/response processing model. Component based tools are based
  @@ -79,8 +84,9 @@
               these solutions. As an interim solution, the DefaultContainer does
               have one public method exposed: <code>getServiceManager()</code>.
             </p>
  -        </s3>
  -        <s3 title="Why Not Use a Central Kernel?">
  +        </section>
  +	<section>
  +	  <title>Why Not Use a Central Kernel?</title>
             <p>
               This was actually planned in a future release. There are some issues
               to work out with a central kernel though. Those issues include how
  @@ -91,9 +97,10 @@
               components involved. In the future Avalon Container: Merlin release,
               we will have a proper meta model.
             </p>
  -        </s3>
  -      </s2>
  -      <s2 title="Smooth Migration for Component Lookup">
  +        </section>
  +      </section>
  +      <section>
  +	<title>Smooth Migration for Component Lookup</title>
           <p>
             Due to the fact there are many ways of implementing the "preferred
             practices" for role naming, different components make assumptions
  @@ -130,8 +137,8 @@
             separator is the "/" character.  Fortress will be able to interpret
             that and skip the ServiceSelector step.
           </p>
  -      </s2>
  -    </s1>
  +      </section>
  +    </section>
     </body>
     <footer>
       <legal>
  
  
  
  1.3       +10 -9     avalon-excalibur/fortress/src/xdocs/features.xml
  
  Index: features.xml
  ===================================================================
  RCS file: /home/cvs/avalon-excalibur/fortress/src/xdocs/features.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- features.xml	26 Jul 2002 16:12:44 -0000	1.2
  +++ features.xml	7 Feb 2003 17:56:31 -0000	1.3
  @@ -1,4 +1,5 @@
   <?xml version="1.0"?>
  +<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
   
   <document>
     <header>
  @@ -8,7 +9,7 @@
       </authors>
     </header>
     <body>
  -    <s1 title="Features">
  +    <section><title>Features</title>
         <p>
   	Fortress provides a framework for you to easily create your
   	own application specific containers.  We strive to make it
  @@ -16,7 +17,7 @@
   	allows you to focus on the core issues in your system, without
   	worrying about the component management getting in your way.
         </p>
  -      <s2 title="Asynchronous Component Management">
  +      <section><title>Asynchronous Component Management</title>
   	<p>
             Most component management functions don't take that long to
   	  perform, but the time they do take can directly affect how
  @@ -32,16 +33,16 @@
   	  background as well.  Fortress will likely be your choice of
   	  containers if you have strict performance constraints.
           </p>
  -      </s2>
  -      <s2 title="Extensible Lifecycle">
  +      </section>
  +      <section><title>Extensible Lifecycle</title>
   	<p>
             Fortress has support for an experimental feature that allows
   	  you to extend your component lifecycle in an application
   	  specific manner.  If it proves to be a truly useful feature,
   	  other Avalon containers will adopt it.
           </p>
  -      </s2>
  -      <s2 title="Instrumentation">
  +      </section>
  +      <section><title>Instrumentation</title>
           <p>
             Fortress is integrated with the Instrumentation package so
   	  you can get a graphical view of the health of your system
  @@ -50,8 +51,8 @@
   	  instances each handler is responsible for.  Using that
   	  information, you can tune your container more intelligently.
           </p>
  -      </s2>
  -    </s1>
  +      </section>
  +    </section>
     </body>
     <footer>
       <legal>
  
  
  
  1.4       +20 -129   avalon-excalibur/fortress/src/xdocs/getting-started.xml
  
  Index: getting-started.xml
  ===================================================================
  RCS file: /home/cvs/avalon-excalibur/fortress/src/xdocs/getting-started.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- getting-started.xml	7 Feb 2003 16:08:12 -0000	1.3
  +++ getting-started.xml	7 Feb 2003 17:56:31 -0000	1.4
  @@ -1,202 +1,93 @@
   <?xml version="1.0"?>
  -
  -
  +<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
   
   <document>
  -
       <header>
  -
           <title>Excalibur Fortress - Getting Started</title>
  -
           <authors>
  -
               <person name="The Avalon Documentation Team" email="dev@avalon.apache.org"/>
  -
           </authors>
  -
       </header>
  -
       <body>
  -
  -        <s1 title="Introduction">
  -
  +        <section><title>Introduction</title>
               <p>
  -
                   This is a brief guide to getting you up and running with fortress.
  -
                   For complex topics like how to decompose a system into individual
  -
                   components, Seperation of Concerns, etc, refer to other documentation.
  -
               </p>
  -
  -        </s1>
  -
  -        <s1 title="Getting your stuff together">
  -
  +        </section>
  +        <section><title>Getting your stuff together</title>
               <ul>
  -
                   <li>If you haven't already, download and install the latest version
  -
                   of <link href="http://ant.apache.org/">Apache Ant</link>.</li>
  -
                   <li>Get and install a CVS client (see
  -
                   <link href="http://jakarta.apache.org/site/cvsindex.html">here</link>
  -
                   for information on CVS).</li>
  -
                   <li>Check out the modules avalon, avalon-excalibur,
  -
                   avalon-logkit and jakarta-site</li>
  -
  -                <li>Use ant to build the various projects:
  -
  -                    <source>
  -
  -cd $CVSROOT/avalon
  -
  -ant jar
  -
  -cd $CVSROOT/avalon-logkit
  -
  -ant jar
  -
  -cd $CVSROOT/avalon-excalibur/fortress
  -
  -ant dist
  -
  -cd examples
  -
  -ant
  -
  -                    </source>
  -
  +	<li>Use ant to build the various projects: avalon, logkit, excalibur fortress.
                   If something goes wrong, run ant in verbose mode using the -v option and
  -
                   send the output to the avalon-user mailing list. Someone'll help you out.
  -
                   </li>
  -
               </ul>
   
  -
  -
               <p>Or, if you hate CVS, get a nightly build.</p>
  -
  -        </s1>
  -
  -        <s1 title="Hello, world!">
  -
  +        </section>
  +        <section><title>Hello, world!</title>
               <p>You just built fortress, its dependencies, and its examples from cvs
in
  -
               the previous step. This enables you to (finally!) run a HelloWorld demo.
  -
               change into the bin directory for the examples and run the
  -
               scripts there (runswing.sh is a nice one).</p>
  -
  -        </s1>
  -
  -        <s1 title="Well, duh! So now what?">
  -
  -            <s2 title="Play with the examples">
  -
  +        </section>
  +        <section><title>Well, duh! So now what?</title>
  +            <section><title>Play with the examples</title>
                   <p>After looking at the sources to the examples provided and figuring
out
  -
                   what goes on (if you're an IDE person, run the examples in your IDE
  -
                   debugger! If you develop servlets, be sure to try to get the servlet
  -
                   example to run), the real cool but also the hard part begins.</p>
  -
  -            </s2>
  -
  -            <s2 title="Converting from ECM">
  -
  +            </section>
  +            <section><title>Converting from ECM</title>
                   <p>If you're looking at converting an existing avalonized application
that
  -
                   uses ECM, well, we want to write a tool that does this all but automatically
  -
                   for you. Not there yet though.</p>
  -
  -            </s2>
  -
  -            <s2 title="Convert a non-avalon application">
  -
  +            </section>
  +            <section><title>Convert a non-avalon application</title>
                   <p>The first thing you want to do is to create a fortress instance
inside
  -
                   your applications main loop or bootstrap class. The second thing you want
  -
                   to do is identify the building blocks of your application, and transform
  -
                   them into avalon components (by making them passive, and extending the
  -
                   avalon framework lifecycle interfaces).
  -
                   Then, create the fortress configuration files to tell it about those new
  -
                   components, and transfer control over those components from your bootstrap
  -
                   code to fortress. Done!</p>
  -
                   <p>Okay, so it may not be so simple as it sounds, but that is the
general
  -
                   idea. Just get started, and come and talk to us on the mailing list when
  -
                   you get lost.</p>
  -
  -            </s2>
  -
  -            <s2 title="Creating a new application">
  -
  +            </section>
  +            <section><title>Creating a new application</title>
                   <p>Start with the example that fits your enviroment (console, GUI
  -
                   or embedded), and simply start hacking from there. You'll want to think
  -
                   about the various tasks your app serves, and how to decompose your app
  -
                   into components that fit those tasks. The
  -
                   <link href="http://jakarta.apache.org/avalon/developing">Developing
with Avalon</link>
  -
                   paper talks you through this.</p>
  -
  -            </s2>
  -
  -        </s1>
  -
  -        <s1 title="Mastering Fortress">
  -
  +            </section>
  +        </section>
  +        <section><title>Mastering Fortress</title>
               <p>
  -
                   The best way to learn about avalon and its concepts is to build your own
  -
                   container. Try and plug in your own implementations of the different parts
  -
                   of fortress, like a different ComponentHandler. Once you get a hang of
it,
  -
                   come and join the avalon folks in their quest for the holy grail of
  -
                   software architecture!
  -
               </p>
  -
  -        </s1>
  -
  +        </section>
       </body>
  -
       <footer>
  -
       <legal>
  -
           Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
  -
           $Revision$ $Date$
  -
       </legal>
  -
       </footer>
  -
   </document>
   
  
  
  
  1.9       +10 -9     avalon-excalibur/fortress/src/xdocs/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/avalon-excalibur/fortress/src/xdocs/index.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- index.xml	7 Feb 2003 16:08:12 -0000	1.8
  +++ index.xml	7 Feb 2003 17:56:31 -0000	1.9
  @@ -1,4 +1,5 @@
   <?xml version="1.0"?>
  +<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
   
   <document>
     <header>
  @@ -8,14 +9,14 @@
       </authors>
     </header>
     <body>
  -    <s1 title="Introduction">
  -      <warn>
  +    <section><title>Introduction</title>
  +      <warning>
           This package is under development, and the API is not
           guaranteed to be the same when it is ready for release.
           You can find this in the excalibur-fortress-1.0.jar file if you want
           to play with it. Do not blame us if the next release of
           Excalibur breaks your code if you use this package.
  -      </warn>
  +      </warning>
         <p>
           Fortress contains a framework to help you create your own
           avalon containers.  It boasts asynchronous management of your
  @@ -23,8 +24,8 @@
           your code, and easy embedding into various environments like
           servlet engines.
         </p>
  -    </s1>
  -    <s1 title="downloads">
  +    </section>
  +    <section><title>downloads</title>
           <p>
               When fortress is released, binaries will be made available. For
               now, you can try downloading a nightly build from
  @@ -33,8 +34,8 @@
           <p>
               Other than that, the only way to get fortress is by using cvs.
           </p>
  -    </s1>
  -    <s1 title="available documentation">
  +    </section>
  +    <section><title>available documentation</title>
           <ul>
               <li>The primary source of documentation is the fortress website, available
               at
  @@ -57,7 +58,7 @@
               <link href="http://jakarta.apache.org/site/mail2.html#Avalon">avalon-user
list</link>
               and its archive can be incredibly useful.</li>
           </ul>
  -    </s1>
  +    </section>
     </body>
     <footer>
       <legal>
  
  
  
  1.6       +57 -78    avalon-excalibur/fortress/src/xdocs/lifecycle-extensions.xml
  
  Index: lifecycle-extensions.xml
  ===================================================================
  RCS file: /home/cvs/avalon-excalibur/fortress/src/xdocs/lifecycle-extensions.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- lifecycle-extensions.xml	7 Feb 2003 16:08:12 -0000	1.5
  +++ lifecycle-extensions.xml	7 Feb 2003 17:56:31 -0000	1.6
  @@ -1,4 +1,5 @@
   <?xml version="1.0"?>
  +<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
   
   <document>
     <header>
  @@ -9,7 +10,7 @@
     </header>
     <body>
   
  -  <s1 title="What are lifecycle extensions ?">
  +  <section><title>What are lifecycle extensions ?</title>
      <p>
       Lifecycle extensions are additional stages a component can traverse through during
       it's lifetime. Lifecycle extensions allow a Container to provide extra functionality
  @@ -61,12 +62,10 @@
       by the reader.
      </p>
   
  -   <p>
       <note>As at the time of writing, Fortress is the only Avalon container that
       supports lifecycle extensions, which means Components that use this feature will most
likely
       only work as expected with Fortress, and not with the other Avalon containers
       (ExcaliburComponentManager, Phoenix, Merlin, Tweety, etc)</note>
  -   </p>
   
      <p>
       Support for lifecycle extensions in the other Avalon containers is technically possible
but
  @@ -74,98 +73,86 @@
       one of these containers and would like to use lifecycle extensions.
      </p>
   
  -  </s1>
  +  </section>
   
  -  <s1 title="How do I extend a Component's lifecycle ?">
  +  <section><title>How do I extend a Component's lifecycle ?</title>
      <p>
       Extending a Component's lifecycle is straightforward. An overview of the process
       follows:
      </p>
   
       <ol>
  -     <li>Define the new component interface</li>
  +	    <li>Define the new component interface<br/>
   
  -     <p>
         Create the new interface defining the operations that should be called upon components
         that implement this interface. Using the previously mentioned examples, this would
be
         your <code>SecurityManageable</code>, <code>Cacheable</code>,
<code>Decryptable</code>,
         <code>Recycleable</code> interfaces.
  -     </p>
  +      </li>
   
        <li>Define an extension object that calls upon the methods defined in the new
interface,
  -     during one or more of the pre-defined phases of component's lifecycle</li>
  -
  -     <p>
  +     during one or more of the pre-defined phases of component's lifecycle<br/>
  +    
         Create a class that implements <code>LifecycleExtension</code>, that
tests any given
         component for the above defined interface (and others if applicable), invoking methods
         defined in that interface.
  -     </p>
  +    </li>
   
  -     <li>Register the extension object with Fortress' <code>LifecycleExtensionManager</code></li>
  +     <li>Register the extension object with Fortress' <code>LifecycleExtensionManager</code><br/>
   
  -     <p>
         Create an instance of the class defined in the previous step, and register it with
a
         <code>LifecycleExtensionManager</code>, using either the default manager
available inside
         of your container, or an externally created manager that is later given to the container
         to use.
  -     </p>
  +      </li>
   
  -     <li>Implement the new component interface on your component</li>
  +     <li>Implement the new component interface on your component<br/>
   
  -     <p>
         Add the new <code>implements</code> clause to your Component, or Component
implementation,
         and write any methods defined in the implemented interface.
  -     </p>
  +      </li>
   
  -     <li><code>lookup()/select()/release()</code> components as normal</li>
  -
  -     <p>
  +      <li><code>lookup()/select()/release()</code> components as normal<br/>
         Proceed as normal. Checking for extensions is done implicitly within Fortress. Once
         lifecycle extensions are registered they will be invoked on any implementing components
         during the 4 phases defined later in this document.
  -     </p>
  +     </li>
       </ol>
  -  </s1>
  +  </section>
   
  -  <s1 title="When can a Component's lifecycle be extended ?">
  +  <section><title>When can a Component's lifecycle be extended ?</title>
      <p>
       The life of any component can be broken down to the following phases:
      </p>
   
       <ol>
  -     <li>Creation</li>
  +	    <li>Creation<br/>
   
  -     <p>
         When the Component is actually instantiated.
  -     </p>
  +     </li>
   
  -     <li>Access</li>
  +     <li>Access<br/>
   
  -     <p>
         When the Component is accessed via a ComponentManager/Selector
         (<code>lookup()/select()</code>).
  -     </p>
  +     </li>
   
  -     <li>Release</li>
  +     <li>Release<br/>
   
  -     <p>
         When the Component is released via a ComponentManager/Selector (<code>release()</code>).
  -     </p>
  +     </li>
   
  -     <li>Destruction</li>
  +     <li>Destruction<br/>
   
  -     <p>
         When the Component is decommissioned, ready for garbage collection.
  -     </p>
  +     </li>
   
       </ol>
   
  -   <p>
       <note>A Component will go through it's Creation and Destruction phase only once.
Since
       <code>ComponentHandler</code> classes can implement different handling
strategies
       (Poolable, ThreadSafe, etc), the access and release phases of a component can be
       done multiple times.</note>
  -   </p>
   
      <p>
       Lifecycle extensions can be added to any of the above defined phases. This allows
  @@ -184,15 +171,15 @@
       to any one context of use.
      </p>
   
  -  </s1>
  +  </section>
   
  -  <s1 title="Which interfaces and classes do I need to use ?">
  +  <section><title>Which interfaces and classes do I need to use ?</title>
   
      <p>
       Support for lifecycle extensions in Fortress is done using the following classes/interfaces.
      </p>
   
  -  <s2 title="The Component Extension Interface">
  +  <section><title>The Component Extension Interface</title>
      <p>
       This interface specifies the business particular extension components will be tested
for.
       It defines the new interface that components will implement to receive additional
  @@ -203,9 +190,9 @@
       There is no particular base interface the developer needs to extend, and the interface
       can be kept separate from the Container itself.
      </p>
  -  </s2>
  +  </section>
   
  -  <s2 title="The LifecycleExtension Interface">
  +  <section><title>The LifecycleExtension Interface</title>
   
      <p>
       Component extensions are invoked via a Lifecycle extension object. Lifecycle extension
  @@ -301,9 +288,9 @@
       necessary for your particular extension.
      </p>
   
  -  </s2>
  +  </section>
   
  -  <s2 title="The LifecycleExtensionManager class">
  +  <section><title>The LifecycleExtensionManager class</title>
   
      <p>
       The <code>LifecycleExtensionManager</code> class provides default management
of
  @@ -335,9 +322,9 @@
       <code>LifecycleExtensionManager.addExtension()</code>. Methods also exist
for removing
       and iterating through the currently available extensions.
      </p>
  -  </s2>
  +  </section>
   
  -  <s2 title="FortressComponentManager/FortressComponentSelector">
  +  <section><title>FortressComponentManager/FortressComponentSelector</title>
   
      <p>
       Fortress' inbuilt Component Manager/Selector/Factory code will automatically call
  @@ -346,46 +333,40 @@
      </p>
   
       <ol>
  -     <li>Access</li>
  +	    <li>Access<br/>
   
  -     <p>
         Called inside the ComponentManager, after the component has been retrieved
         from it's handler, but before it's returned to the invoker of
         <code>lookup()/select()</code>.
  -     </p>
  +     </li>
   
  -     <li>Release</li>
  +     <li>Release<br/>
   
  -     <p>
         Called inside the ComponentManager, before the component is passed back to
         it's handler to be disposed/pooled/etc.
  -     </p>
  +     </li>
   
  -     <li>Creation</li>
  +     <li>Creation<br/>
   
  -     <p>
         Called inside the ComponentFactory, before <code>initialize()</code>.
  -     </p>
  +     </li>
   
  -     <li>Destruction</li>
  +     <li>Destruction<br/>
   
  -     <p>
         Called inside the ComponentFactory, after <code>dispose()</code>.
  -     </p>
  +     </li>
       </ol>
   
  -   <p>
       <note>, components created via Fortress' ComponentHandler classes directly
       will bypass the logic for <code>access</code> and <code>release</code>
extensions. This is
       because the code performing this logic is located in the ComponentManager/Selector
classes
       (independent from all handlers).</note>
  -   </p>
   
  -  </s2>
  +  </section>
   
  -  </s1>
  +  </section>
   
  -  <s1 title="An Example">
  +  <section><title>An Example</title>
   
      <p>
       Let's look at a simple example. The following is also available as a working sample
  @@ -397,7 +378,7 @@
       Components. We'll call it the <code>SecurityManageable</code> interface.
      </p>
   
  -  <s2 title="Define the component extension interface">
  +  <section><title>Define the component extension interface</title>
   
      <p>
       First we define the new Component extension interface.
  @@ -420,9 +401,9 @@
      }
      </source>
   
  -  </s2>
  +  </section>
   
  -  <s2 title="Create the lifecycle extensions class">
  +  <section><title>Create the lifecycle extensions class</title>
   
      <p>
       Next we define the actual extension implementation which invokes the <code>secure()</code>
  @@ -460,14 +441,12 @@
      }
      </source>
   
  -   <p>
       <note>An extension class may run components through any given number of
       extensions, and are not limited to just one.</note>
  -   </p>
   
  -  </s2>
  +  </section>
   
  -  <s2 title="Register the lifecycle extensions class">
  +  <section><title>Register the lifecycle extensions class</title>
   
      <p>
       We then inform our container about the extension. This could be done in several different
  @@ -498,9 +477,9 @@
      }
      </source>
   
  -  </s2>
  +  </section>
   
  -  <s2 title="Use the new component interface">
  +  <section><title>Use the new component interface</title>
   
      <p>
       To use the new SecurityManageable lifecycle extension, we simply implement
  @@ -546,20 +525,20 @@
          }
      }
      </source>
  -  </s2>
  +  </section>
   
      <p>
       As you can see, it's a straightforward process to implement a new extension.
      </p>
   
  -  </s1>
  +  </section>
   
  -  <s1 title="Need more information ?">
  +  <section><title>Need more information ?</title>
      <p>
       If you have any particular questions, comments, etc, please send an email to the Avalon
       developer mailing <link href="mailto:dev@avalon.apache.org">list</link>.
      </p>
  -  </s1>
  +  </section>
   
     </body>
     <footer>
  
  
  
  1.4       +3 -2      avalon-excalibur/fortress/src/xdocs/servlet.xml
  
  Index: servlet.xml
  ===================================================================
  RCS file: /home/cvs/avalon-excalibur/fortress/src/xdocs/servlet.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- servlet.xml	7 Feb 2003 16:08:12 -0000	1.3
  +++ servlet.xml	7 Feb 2003 17:56:31 -0000	1.4
  @@ -1,4 +1,5 @@
   <?xml version="1.0"?>
  +<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
   
   <document>
     <header>
  @@ -8,7 +9,7 @@
       </authors>
     </header>
     <body>
  -    <s1 title="Swing Based Applications">
  +    <section><title>Swing Based Applications</title>
         <p>
           Servlet based applications are viewed on the web.  Examples of these
           types of Java projects are Jakarta Turbine, and Apache Cocoon.
  @@ -92,6 +93,6 @@
   }
             ]]>
         </source>
  -    </s1>
  +    </section>
     </body>
   </document>
  
  
  
  1.3       +7 -6      avalon-excalibur/fortress/src/xdocs/swing.xml
  
  Index: swing.xml
  ===================================================================
  RCS file: /home/cvs/avalon-excalibur/fortress/src/xdocs/swing.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- swing.xml	7 Feb 2003 16:08:12 -0000	1.2
  +++ swing.xml	7 Feb 2003 17:56:31 -0000	1.3
  @@ -1,4 +1,5 @@
   <?xml version="1.0"?>
  +<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
   
   <document>
     <header>
  @@ -8,7 +9,7 @@
       </authors>
     </header>
     <body>
  -    <s1 title="Swing Based Applications">
  +    <section><title>Swing Based Applications</title>
         <p>
           Swing applications are those applications that have a lovely graphical
           interface for you to interact with.  When you are done with the
  @@ -26,7 +27,7 @@
           manage the Swing GUI separately, but give your container or its
           ServiceManager to the Swing code to interact with.
         </p>
  -      <s2 title="Extending DefaultContainer">
  +      <section><title>Extending DefaultContainer</title>
           <p>
             If we extend the DefaultContainer, our main method will look pretty
             much the same:
  @@ -83,9 +84,9 @@
   }
             ]]>
           </source>
  -      </s2>
  -      <s2 title="Passing Container to Swing">
  -      </s2>
  -    </s1>
  +      </section>
  +      <section><title>Passing Container to Swing</title>
  +      </section>
  +    </section>
     </body>
   </document>
  
  
  
  1.21      +1 -1      avalon-excalibur/util/build.xml
  
  Index: build.xml
  ===================================================================
  RCS file: /home/cvs/avalon-excalibur/util/build.xml,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- build.xml	29 Jan 2003 14:07:42 -0000	1.20
  +++ build.xml	7 Feb 2003 17:56:32 -0000	1.21
  @@ -346,7 +346,7 @@
   
       <!-- Prepares the documentation directory -->
       <target name="docs" depends="setup-filters" description="Generates the Docs">
  -    <ant antfile="${basedir}/../cocoonbuild.xml"/>
  +    <ant antfile="${basedir}/../forrestbuild.xml"/>
   
         <copy todir="${docs.dir}">
           <fileset dir="${build.docs}">
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org


Mime
View raw message