rwaldhoff    01/08/16 17:33:05

  Modified:    xdocs    charter.xml
  Log:
  fix <br> between Morgan's and Ted's names
  fix spelling of Waldhoff in example proposal
  
  Revision  Changes    Path
  1.3       +52 -52    jakarta-commons/xdocs/charter.xml
  
  Index: charter.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-commons/xdocs/charter.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- charter.xml       2001/04/03 04:28:32     1.2
  +++ charter.xml       2001/08/17 00:33:05     1.3
  @@ -19,23 +19,23 @@
   <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. 
  +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 
  +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. 
  +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 
  +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>
   
  @@ -48,11 +48,11 @@
   </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 
  +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 
  +subproject(s) will distribute the code or documentation along
   with the rest of their codebase.
   </p>
   
  @@ -60,13 +60,13 @@
   (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, 
  +<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>
  @@ -75,11 +75,11 @@
   <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 
  +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 
  +a Database Connection Pool package, along with related
   testing suites and subproject infrastructure.
   </p>
   
  @@ -122,7 +122,7 @@
   
   <strong>(4) identify the initial set of committers</strong>
   <p>
  -Morgan Delagrange<brh/>
  +Morgan Delagrange<br/>
   Ted Husted<br/>
   Conor MacNeill<br/>
   Geir Magnusson Jr.<br/>
  @@ -156,30 +156,30 @@
     </li>
   
     <li>
  -     The package library is not a framework but a collection 
  +     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, 
  +     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, 
  +      <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 
  +        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 
  +          <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 
  +          <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>
  @@ -190,42 +190,42 @@
       </ol>
     </li>
     <li>
  -     The packages should use a standard scheme for versioning, 
  -     QA tests, and directory layouts, and a common format for 
  +     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 
  +     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. 
  +      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, 
  +    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, 
  +      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, 
  +     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 
  +      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 
  +       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>
  @@ -242,7 +242,7 @@
     <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. 
  + 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>
  @@ -262,8 +262,8 @@
   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 
  +<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>
  @@ -280,7 +280,7 @@
       <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 &lt; <a 
href="http://www.webappcabaret.com/rwald/dbcp/";>http://www.webappcabaret.com/rwald/dbcp/</a>
 &gt;</p>
  +<p>The initial codebase was contributed by Rodney Waldhoff from a working project 
and can be distributed under the Apache license. The source is available as dbpool.jar 
from &lt; <a 
href="http://www.webappcabaret.com/rwald/dbcp/";>http://www.webappcabaret.com/rwald/dbcp/</a>
 &gt;</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>
  @@ -307,13 +307,13 @@
   <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'. 
  +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 -- 
  +<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>
  
  
  

Reply via email to