The charter for the DB Commons subproject of the Apache DB project was approved by the Apache DB PMC in February of 2003.
The Apache community's experience with the Jakarta Commons subproject has demonstrated the value and viability of a subproject devoted to a constellation of small, focused, and reusable libraries rather than a single, often monolithic, development artifact.
While several database related libraries have been created within the scope of the Jakarta Commons subproject, we believe the creation of a DB-specific commons subproject will:
The subproject shall create and maintain focused library components, intended for use in database related development and designed to be used independently of any larger product or framework. DB Commons components may be implemented in any programming language and may support any database related technology. Each component will be managed in the same manner as a larger Apache product.
The DB Commons subproject shall also host a shared workspace (a "sandbox") for Apache DB committers.
Other projects and subprojects are encouraged but not required to contribute to and use the libraries developed within the DB Commons subproject.
The subproject will host a CVS repository available to all DB committers as a workplace for new libraries or other projects. Before release to the public, code or documentation developed here must be sponsored by (and moved to) a DB subproject (including but not limited to the DB Commons subproject), or to the oversight of some other Apache PMC.
The initial components are to be based on existing ASF codebases, including those that may be extracted from existing Apache DB subprojects and database related components found in Jakarta Commons and elsewhere. Migration of any new or existing libraries to DB Commons would of course require approval from the "sponsoring" community, as well as the DB Commons committers.
Within the defect tracking system, a "db-commons" category, with one "general" sub-category, and one sub-category per component/library.
The subproject will create an maintain a web site available
http://db.apache.org/commons/, and will
be integrated into the existing Maven reactor based build.
This is simply an example. It is not a formal proposal, let alone a binding one.Proposal for Mock JDBC Objects Component
Many DB projects and DB Commons components rely upon Java's JDBC API. The JDK defines an interface for this API, but does not (and realistically, probably can not) provide a standard or base implementation of this interface. Hence it can be difficult to develop test suites for JDBC-based components without a full-blown JDBC (i.e., relational database) implementation.
One popular alternative to "functional" testing using an external system (in our case, a relational database) is known as a "Mock Objects" or "Endo-Testing" approach . Using Mock Objects, rather than building a full implementation of the external system, we build just enough functionality to validate the code being tested. For example, when testing a connection pooling system, we don't really need to be able to execute an arbitrary SQL statement, we simply need some DataSource from which can obtain some Connection. Most of the underlying database functionality is unimportant to the connection pool.
The availability of an extensible collection of "mock" JDBC objects under an ASF license will support the development and testing of a number of JDBC related and JDBC based components, within DB Commons, with the Apache DB project, and within the Java development community as a whole.
 See http://www.mockobjects.com/endotesting.html
(1) scope of the component
The component shall create and maintain a collection of "mock" JDBC objects to be distributed under the ASF license, supporting unit testing of JDBC based or derived applications using an endo-testing approach.
The component should be extensible so that clients that require additional "mock" functionality are able to add it.
(1.5) interaction with other components
It is expected, but certainly not required, that other DB Commons components will take advantage of this component.
(2) identify the initial source for the component
The initial codebase was developed within the Jakarta Commons DBCP component, and further developed within the Jakarta Commons Sandbox under the DbUtils component.
(2.1) identify the base name for the component
(2.2) identify the coding conventions for this component
The code follows the standard Sun code conventions.
(3) identify any DB Commons resources to be created
(3.1) mailing list
Until traffic justifies, the component will use the general DB Commons lists for communications.
(3.2) CVS repositories
For the time being, the component will use a
mockjdbc branch of the DB-Commons CVS.
The component should be listed as a component of the DB Commons Bugzilla entry.
(3.4) Jyve FAQ (when available)
(4) identify the initial set of committers to be listed in the Status File.