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="[EMAIL PROTECTED]"/>
-
</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:[EMAIL PROTECTED]";>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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
