geirm 01/04/02 21:07:06
Added: xdocs beanutils.xml charter.xml contributors.xml
directory.xml index.xml license.xml sandbox.xml
Log:
initial content for generation of site
Revision Changes Path
1.1 jakarta-commons/xdocs/beanutils.xml
Index: beanutils.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Commons</title>
<author email="[EMAIL PROTECTED]">Commons Documentation
Team</author>
</properties>
<body>
<section name="The BeanUtils Component">
<p>
<b>Proposed by :</b> Craig R. McClanahan
</p>
<p>
Most Java developers are used to creating Java classes that conform to the
JavaBeans naming patterns for property getters and setters. It is natural to
then access these methods directly, using calls to the corresponding
<code>getXxx</code> and <code>setXxx</code> methods. However, there are some
occasions where dynamic access to Java object properties (without compiled-in
knowledge of the property getter and setter methods to be called) is needed.
Example use cases include:</p>
<ul>
<li>Building scripting languages that interact with the Java object model
(such as the Bean Scripting Framework).</li>
<li>Building template language processors for web presentation and similar
uses (such as JSP or Velocity).</li>
<li>Building custom tag libraries for JSP and XSP environments (such as Jakarta
Taglibs, Struts, Cocoon).</li>
<li>Consuming XML-based configuration resources (such as Ant build scripts, web
application deployment descriptors, Tomcat's <code>server.xml</code>
file).</li>
</ul>
<p>
The Java language provides <em>Reflection</em> and <em>Introspection</em>
APIs (see the <code>java.lang.reflect</code> and <code>java.beans</code>
packages in the JDK Javadocs). However, these APIs can be quite complex to
understand and utilize. The <em>BeanUtils</em> component provides
easy-to-use wrappers around these capabilities.
</p>
<p>
More please, Craig :)
</p>
<strong>BeanUtils in CVS</strong>
<p>
The BeanUtils component can be found in the Commons CVS online
<a
href="http://jakarta.apache.org/cvsweb/index.cgi/jakarta-commons/beanutils">here</a>.
</p>
</section>
</body>
</document>
1.1 jakarta-commons/xdocs/charter.xml
Index: charter.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Commons</title>
<author email="[EMAIL PROTECTED]">Commons Documentation
Team</author>
</properties>
<body>
<section name="Charter">
<p>
The following charter for Jakarta Commons was approved by the Jakarta Project
Management Committee on March 19, 2001.
</p>
<strong>(0) rationale</strong>
<p>
Apache-Java and Jakarta originally hosted product-based subprojects,
consisting of one major deliverable. The Java language however is
package-based, and most of these products have many useful utilities.
Some products are beginning to break these out so that they can be used
independently. A Jakarta subproject to solely create and maintain
independent packages is proposed to accelerate and guide this process.
</p>
<strong>(1) scope of the subproject</strong>
<p>
The subproject shall create and maintain packages written in the Java
language, intended for use in server-related development, and designed
to be used independently of any larger product or framework.
Each package will be managed in the same manner
as a larger Jakarta product. To further this goal, the subproject
shall also host a workplace for Jakarta committers and a master
index of reusable packages related to Jakarta products.
</p>
<p>
(1.5) interaction with other subprojects
</p>
<p>
(1.5.1) the sandbox
</p>
<p>
The subproject will host a CVS repository available to all Jakarta
committers as a workplace for new packages or other projects.
Before release to the public, code or documentation developed
here must be sponsored by a Jakarta subproject. The sponsoring
subproject(s) will distribute the code or documentation along
with the rest of their codebase.
</p>
<p>
(1.5.2) the directory
</p>
<p>The subproject will also catalog packages and other resources
available to the public related to other Jakarta subprojects and
ASF projects. This will be a dynamic catalog, like Bugzilla and Jyve,
similar in functionality to <a href="http://download.com/">download.com</a>,
<a href="http://cpan.org/">cpan.org</a>, or
<a href="http://sourceforge.net/">SourceForge.net</a>.
New entries may be added by Jakarta committers, developers,
and users. Entries by developers and users will be approved
by a committer before being made public.
</p>
<strong>(2) identify the initial source from which the subproject is to be
populated</strong>
<p>
The initial packages would be based on existing ASF codebases,
including those that provide services for DataSource/Database Pools,
XML Configuration, Message Resources and i18n, JNDI and Naming, and
Testing Suites. The initial committers have agreed to first create and maintain
a Database Connection Pool package, along with related
testing suites and subproject infrastructure.
</p>
<strong>(3) identify the initial Jakarta resources to be created </strong>
<p>
(3.1) mailing list(s)
</p>
<p>
jakarta-commons
</p>
<p>
(3.2) CVS repositories
</p>
<p>
jakarta-commons<br/>
jakarta-commons-sandbox
</p>
<p>
(3.3) Bugzilla
</p>
<p>
program - commons<br/>
components - Web site, Directory, dbcp
</p>
<p>
(3.4) Jyve FAQ (when available)
</p>
<p>commons-general<br/>
commons-dbcp<br/>
commons-sandbox
</p>
<strong>(4) identify the initial set of committers</strong>
<p>
Morgan Delagrange<brh/>
Ted Husted<br/>
Conor MacNeill<br/>
Geir Magnusson Jr.<br/>
Costin Manolache<br/>
Remy Maucherat<br/>
Craig R. McClanahan<br/>
Ignacio J. Ortega<br/>
Rodney Waldhoff<br/>
David Weinrich
</p>
</section>
<section name="guidelines">
<p> Note :
<ul>
<li>
<i>is, has, will, shall, must</i> - required.
</li>
<li>
<i>may, should, are encouraged </i>- optional but recommended.
</li>
</ul>
</p>
<p>
<ol>
<li>
The primary unit of reuse and release is the package.
</li>
<li>
The package library is not a framework but a collection
of components designed to be used independently.
</li>
<li>
Each package must have a clearly defined purpose,
scope, and API -- Do one thing well, and keep your contracts.
</li>
<li>Each package is treated as a product in its own right.
<ol>
<li>Each package has its own status file, release schedule,
version number, QA tests, documentation, mailing list, bug category, and
individual JAR.
</li>
<li>
Each package must clearly specify any external dependencies,
including any other Commons packages, and the earliest JDK version
required.
<ol>
<li>External dependencies on optional and third-party
codebases should be minimized.
</li>
<li>All necessary dependencies must be recorded in the
MANIFEST.MF file of the package JAR, in the manner recommended
in the JDK 1.3 documentation describing 'system extensions'
</li>
</ol>
</li>
<li>
Each package must maintain a list of its active committers in its status
file.
</li>
</ol>
</li>
<li>
The packages should use a standard scheme for versioning,
QA tests, and directory layouts, and a common format for
documentation and Ant build files.
</li>
<li>
The packages should fit within a unified package hierarchy.
</li>
<li>
In general, packages should provide an interface and one or
more implementations of that interface, or implement another
interface already in use.
<ul>
<li>
The packages should have boring functional names.
Implementations may choose more 'exciting' designations.
</li>
</ul>
</li>
<li>
Packages are encouraged to either use JavaBeans as core objects,
a JavaBean-style API, or to provide an optional JavaBean wrapper.
</li>
<li>
External configuration files are discouraged, but if required,
XML format files are preferred for configuration options.
</li>
<li>
Each package will be hosted on its own page on the subproject Web site,
and will also be indexed in a master directory.
</li>
<li>
The subproject directory will also provide a distribution
mechanism, or catalog of packages and related resources.
</li>
<li>
The subproject will also host a top-level 'general' mailing list
in addition to any lists for specific packages.
</li>
<li>The subproject will also provide a single JAR of all stable package releases.
It may also provide a second JAR with a subset of only JDK 1.1 compatible releases. A
gump of nightly builds will also be provided.</li>
<li>Volunteers become committers to this subproject in the same way they are
entered to any Jakarta subproject. Being a committer in another Jakarta subproject is
not a prerequisite.</li>
<li>Each committer has karma to all the packages, but committers are required to
add their name to a package's status file before their first commit to that
package.</li>
<li>The committers shall elect a committee of three committers to provide general
oversight, in the style of the Jakarta PMC.</li>
<li>New packages may be proposed to the Jakarta Commons mailing list. To be
accepted, a package proposal must receive a positive super-majority vote of the
subproject committers. Proposals are to identify the
rationale for the package, its scope, its interaction with other packages and
products, the Commons resources, if any, to be created, the initial source from which
the package is to be created, and the initial set of committers.
<ol>
<li>The whole number of positive votes needed for a super majority is
calculated by dividing the total number of active subproject committers by four,
multiplying by three, and rounding to the nearest whole number (>= .5 rounds
up).</li>
</ol>
</li>
<li>It is expected that the scope of packages may sometimes overlap.</li>
<li>Anyone may propose a new package to the Commons, and list themselves as the
initial committers for the package. The vote on the proposal is then also a vote to
enter new committers to the subproject as needed.</li>
<li>A CVS repository will be available to all Jakarta committers as a workplace
for new packages or other projects.
Before release to the public,
code or documentation developed here must be sponsored by Jakarta subproject.
The sponsoring subproject(s) will distribute the code or documentation along with
the
rest of their codebase.</li>
<li>The subproject catalog will also list packages and resources available to the
public related to other Jakarta subprojects and ASF projects.</li>
<li>As a Jakarta subproject, the Commons adopts all other guidelines and
procedures of Jakarta and the Apache Software Foundation, as they may be amended from
time to time.</li>
</ol>
</p>
</section>
<section name="Example Package Proposal">
<strong>Proposal for Database Connection Pool Package</strong>
<p>(0) rationale</p>
<p>
Many Jakarta products support interaction with a relational database. Creating a new
connection for each user can be time consuming (often requiring multiple seconds of
clock time), in order to perform a database transaction that might take milliseconds.
Opening a connection per user can be unfeasible in a
publicly-hosted Internet application where the number of simultaneous users can be
be very large. Accordingly, developers often wish to share a "pool" of open
connections between all of the application's current users. The number of users
actually performing a request at any given time is usually a very small percentage of
the total number of active users, and during request processing is the only time that
a database connection is required. The application itself logs into the DBMS, and a
handles any user account issues internally.
</p>
<p>There are several Database Connection Pools already available, both within
Jakarta products and elsewhere.
A Commons package would give committers an opportunity to coordinate their efforts
to
create and maintain a efficient, feature-rich package
under the ASF license.
</p>
<p>(1) scope of the package</p>
<p>
The package shall create and maintain a database connection pool package written in
the Java language to be distributed under the ASF license. The package shall be
available as a pseudo-JDBC driver and via a DataSource interface. The package shall
also support multiple logins to multiple database systems, reclamation of stale or
dead connections, testing for valid connections, PreparedStatement pooling, and other
features.</p>
<p>(1.5) interaction with other packages</p>
<p>Subclasses of the package should also be able to :</p>
<ul>
<li>be configured via an external file (e.g. Turbine), and</li>
<li>expose its status, exceptions, or other events to an external logging system
(e.g. Log4)..</li>
</ul>
<p>(2) identify the initial source for the package</p>
<p>The initial codebase was contributed by Rodney Waldhorf from a working project
and can be distributed under the Apache license. The source is available as dbpool.jar
from < <a
href="http://www.webappcabaret.com/rwald/dbcp/">http://www.webappcabaret.com/rwald/dbcp/</a>
></p>
<p>(2.1) identify the base name for the package</p>
<p>org.apache.commons.dbcp</p>
<p>(3) identify any Jakarta-Commons resources to be created</p>
<p>(3.1) mailing list</p>
<p>Until traffic justifies, the package will use the Jakarta-Commons list for
communications.</p>
<p>(3.2) CVS repositories</p>
<p>For the time being, the package will use a root branch of the Jakarta-Commons
CVS.</p>
<p>(3.3) Bugzilla</p>
<p>The package should be listed as a component of under the Jakarta-Commons Bugzilla
entry.</p>
<p>(3.4) Jyve FAQ (when available)</p>
<p>commons-dbcp</p>
<p>(4) identify the initial set of committers to be listed in the Status File.</p>
<p>
Morgan Delagrange<br/>
Geir Magnusson Jr.<br/>
Craig R. McClanahan<br/>
Rodney Waldhoff<br/>
David Weinrich
</p>
</section>
<section name="FAQ">
<p><b>What are the actual requirements for a Commons package?</b></p>
<p>
Most of the guidelines are advisory and meant to describe 'best practices'.
The hard requirements boil down to 'clearly declare your API and dependencies'.
Or, taken from the guidelines:
</p>
<blockquote>
<p>3. Each package <b> must</b> have a clearly defined purpose, scope, and API --
Do one thing well, and keep your contracts.</p>
<p>4.1. Each package <b> must</b> clearly specify any external dependencies,
including any other Commons packages, and the earliest JDK version required.</p>
<p>4.1.2. All necessary dependencies <b> must</b> be recorded in the MANIFEST.MF
file of the package JAR, in the manner recommended in the JDK 1.3 documentation
describing 'system extensions'.</p>
</blockquote>
<p>Of course, the other requirement is that the authors submit a proposal to the
Commons committers for approval.</p>
<p><b>Why not have a separate CVS tree for each package?</b></p>
<p>It's possible that we may, but the decision should be deferred until we have more
packages to manage.</p>
<p>For now, we just ask that a Commons committer enter their name in the Status File
of a package before making their first commit/
</p>
<p><b>Should other Jakarta subprojects move their utility packages to the
Commons?</b></p>
<p>They are welcome to do so. If they would like to experiment with refactoring a
package outside their own CVS tree, they can setup shop in the Commons sandbox. Any
Jakarta committer is entitled to write access to this CVS repository upon request. They
could then decide to propose the package to the Commons, and thereby become
committers to the Commons, or to move it back to their own CVS, and just list it in
the Commons directory where other developers and users can find it.</p>
<p><b>What will be listed in the Commons directory?</b></p>
<p>Any package or other resource that is related to a Jakarta product may be entered
into the directory. This will be a dynamic application, like Bugzilla or Jyve. Users
and developers can complete an online form with their entry, which will be reviewed
by a Commons committer before public release. Jakarta committers may have a higher
level of access so that their entry goes online without review.</p>
<p><b>Why not just enroll all the Jakarta committers in the Commons?</b></p>
<p>If Jakarta adopts an open-door policy for all its subprojects, then of course the
Commons will follow suit.</p>
<p>We do have an open-door policy for the sandbox CVS (jakarta-commons-sandbox). Any
Jakarta committer is entitled to write access to the sandbox upon request, no vote
required, no questions asked. Just subscribe to jakarta-commons-sandbox, and request
authorization.</p>
<p><b>Why not just do this within Avalon, or another existing subproject?</b></p>
<p>Avalon is a large subproject that is being refactored. It's possible that the
charter of one of the ensuing pieces may overlap with the Commons.</p>
<p>The focus of the Commons is squarely and solely on developing packages that can
be reused by multiple products, both within and without Jakarta. To garner the
interest of committers, it is important that the Commons and each of its packages be
perceived as an
independent entity. Since this is a volunteer meritocracy, the perception of
committers is vital. No subproject can succeed without the earnest support of
individual committers.</p>
<p>It is our firm position that the Commons will attract more committers on its own
than if it were aligned with any existing subproject. What "committers will commit to"
has to be the prime consideration. Darwin has been trying to tell us that; it's time
we listened.</p>
</section>
<section name="Resources">
<p>
<ul>
<li><b>Jakarta Guidelines</b></li>
<li>- <a
href="http://jakarta.apache.org/site/guidelines.html">http://jakarta.apache.org/site/guidelines.html</a></li>
<li><b>Code Conventions for the Java Programming Language</b><br/>
- <a
href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html</a></li>
<li><b>Javadoc Tool Home Page</b><br/>
- <a
href="http://java.sun.com/j2se/javadoc/index.html">http://java.sun.com/j2se/javadoc/index.html</a></li>
<li><b>Elements of Java Style - 6. Packaging Conventions</b><br/>
- <a
href="http://www.ambysoft.com/elementsJavaStyle.html">http://www.ambysoft.com/elementsJavaStyle.html</a></li>
</ul>
</p>
<p><b>From the Elements of Java Style - 6. Packaging Conventions</b></p>
<p><i>Rules and Principles only - commentary omitted (<a
href="http://www.amazon.com/exec/obidos/ISBN=0521777682/">buy the book!</a>)</i></p>
<p>104. Place types that are commonly used, changed, and released together, or
mutually dependant on each other, into the same package.</p>
<ul>
<li><i>The Common Reuse Principle</i> - A package consists of classes you reuse
together. If you use one of the classes in the package, you use all of them.</li>
<li><i>The Common Closure Principle</i> - A package consists of classes, all
closed against the same kind of changes. A change that affects the package affects all
the classes in that package</li>
<li><i>The Reuse/Release Equivalence Principle</i> - The unit of reuse is the
unit of release. Effective reuse requires tracking of releases from a change control
system. The package is the effective unit of reuse and release.</li>
<li><i>The Acyclic Dependencies Principle</i> - The dependency structure between
packages must be a direct acyclic graph; there must be no cycles in the dependency
structure.</li>
</ul>
<p>105. Isolate volatile classes and interfaces in separate packages.</p>
<p>106. Avoid making packages that are difficult to change dependent on packages
that are easy to change.</p>
<ul>
<li><i>The Stable Dependencies Principle</i> - The dependencies between packages
should be orientated in the direction of increasing stability. A package should only
depend on packages more stable than it is.</li>
</ul>
<p>107. Maximize abstraction to maximize stability.</p>
<ul>
<li><i>The Stable Abstractions Principle </i>- The stability exhibited by a
package is directly proportional to its level of abstraction. The more abstract a
package is, the most stable it tends to be. The more concrete a package is, the more
unstable
it tends to be.</li>
</ul>
<p>108. Capture high-level design and architecture as stable abstractions
organized into stable packages.</p>
<p><i>For more about these rules, and 103 others - <a
href="http://www.ambysoft.com/elementsJavaStyle.html">get the book</a> - highly
recommended.</i></p>
</section>
</body>
</document>
1.1 jakarta-commons/xdocs/contributors.xml
Index: contributors.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Commons Contributors</title>
<author email="[EMAIL PROTECTED]">Commons Documentation
Team</author>
</properties>
<body>
<section name="Contributors">
<p>
We are the participants in Commons :
</p>
<ul>
<li>Morgan Delagrange</li>
<li>Ted Husted</li>
<li>Conor MacNeill</li>
<li>Geir Magnusson Jr.</li>
<li>Costin Manolache</li>
<li>Remy Maucherat</li>
<li>Craig R. McClanahan</li>
<li>Ignacio J. Ortega</li>
<li>Rodney Waldhoff</li>
<li>David Weinrich</li>
</ul>
<p>
Join us!
</p>
</section>
</body>
</document>
1.1 jakarta-commons/xdocs/directory.xml
Index: directory.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Commons</title>
<author email="[EMAIL PROTECTED]">Commons Documentation
Team</author>
</properties>
<body>
<section name="The Directory">
<p>
The Directory is an online catalog of software and other
resources available throughout the Jakarta community.
</p>
<p>
New entries may be added by Jakarta committers, developers and users.
</p>
<p>
The Directory part of Commons hasn't begun. If you are interested in participating,
let us know.
</p>
</section>
</body>
</document>
1.1 jakarta-commons/xdocs/index.xml
Index: index.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Commons</title>
<author email="[EMAIL PROTECTED]">Commons Documentation Team</author>
</properties>
<body>
<section name="The Jakarta Commons">
<p>
The Commons is a new Jakarta subproject chartered to create and
maintain packages written in the Java language that are intended
for use in server related development.
</p>
<p>
The Commons also is a place for collaboration and sharing, where
developers from throughout the Jakarta community can work together
on projects to be shared by the Jakarta projects. To this end, we
host an unstructured CVS for this work.
</p>
<p>
We welcome participation from all that are interested, at all skill levels.
Coding, documentation and testing are all critical parts of the software
development process. If you are interested in participating in any of
these aspects, please join us!
</p>
</section>
<section name="Current Proposals">
<p>
The following proposals for new Commons projects are currently pending :
</p>
<ul>
<li>
<b>Database Connection Pool Package</b> : Rodney Waldhoff
</li>
<li>
<b>Object Pooling Package</b> : Rodney Waldhoff
</li>
<li>
<b>Collections Package</b> : Rodney Waldhoff
</li>
<li>
<b> Cactus, the renamed J2EEUnit</b> : Vincent Massol
</li>
</ul>
<p>
Please see the jakarta-commons mail list for further details.
</p>
</section>
<section name="Where do I get releases?">
<p>
As we are a new project, we have no releases yet. We are working to gather
existing
code from throughout the Jakarta community to form the component projects,
as well as consider new ones for include from outside Jakarta.
</p>
<p>
The individual components will have independant releases : information will be
posted here.
</p>
</section>
<section name="Where do I get nightly snapshots?">
<p>
Nightly snapshots of the Commons CVS can be found at
<a href="http://jakarta.apache.org/builds/commons/nightly/">here</a>.
</p>
<p>
These are meant to provide easy access to the actual project CVS tree.
As this is our live development workspace, there are
no guarantees as to what you will find there,although we do our best to maintain
a buildable source tree.
</p>
</section>
<section name="How do I contribute, give feedback, fix bugs and so on?">
<p>
The Commons project really needs and appreciates any contributions,
including documentation help, source code and feedback.
</p>
<ul>
<li>
Discussion occurs on the <a
href="http://jakarta.apache.org/getinvolved/mail.html">Commons mailing
list</a>.
</li>
<li>
Access to the CVS <strong>jakarta-commons</strong> repository is available
both
<a
href="http://jakarta.apache.org/cvsweb/index.cgi/jakarta-commons/">online</a>
and with a <a href="http://jakarta.apache.org/getinvolved/cvsindex.html">cvs
client</a>.</li>
</ul>
</section>
</body>
</document>
1.1 jakarta-commons/xdocs/license.xml
Index: license.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Apache Software License</title>
<author email="[EMAIL PROTECTED]">
Commons Documentation Team</author>
</properties>
<body>
<section name="Apache Software License">
<p>
All source and documentation of the Commons project is copyrighted by
the Apache Software Foundation, and made available under the following license :
</p>
<source test=""><![CDATA[
/*
* ====================================================================
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. The end-user documentation included with the redistribution, if
* any, must include the following acknowlegement:
* "This product includes software developed by the
* Apache Software Foundation (http://www.apache.org/)."
* Alternately, this acknowlegement may appear in the software itself,
* if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Commons", and "Apache Software
* Foundation" must not be used to endorse or promote products derived
* from this software without prior written permission. For written
* permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache",
* "Velocity" nor may "Apache" appear in their names without prior
* written permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* ====================================================================
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*
*/
]]></source>
</section>
</body>
</document>
1.1 jakarta-commons/xdocs/sandbox.xml
Index: sandbox.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Commons</title>
<author email="[EMAIL PROTECTED]">Commons Documentation
Team</author>
</properties>
<body>
<section name="The Sandbox">
<p>
The Sandbox is a CVS repository for Commons committers
to function as an open workspace for
sharing and collaboration.
</p>
<p>
Access to the CVS <strong>jakarta-commons-sandbox</strong> repository is available
both
<a
href="http://jakarta.apache.org/cvsweb/index.cgi/jakarta-commons-sandbox/">online</a>
and with a <a href="http://jakarta.apache.org/getinvolved/cvsindex.html">cvs
client</a>.
</p>
<strong>Current Sandbox Happenings</strong>
<p>
Here is a small list of whats going on the sandbox.
</p>
<ul>
<li>Morgan Delagrange : XMLUnit</li>
<li>Vincent Massol : Cactus proposal</li>
</ul>
<p>
Go take a look!
</p>
</section>
</body>
</document>
