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 < <a href="http://www.webappcabaret.com/rwald/dbcp/">http://www.webappcabaret.com/rwald/dbcp/</a> ></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 < <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> @@ -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>