db-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rwaldh...@apache.org
Subject cvs commit: db-commons/xdocs/stylesheets project.xml
Date Mon, 10 Mar 2003 01:19:52 GMT
rwaldhoff    2003/03/09 17:19:52

  Added:       xdocs    charter.xml
               xdocs/stylesheets project.xml
  initial import
  - basic site nav
  - charter
  - maven build (site gen) files
  Revision  Changes    Path
  1.1                  db-commons/xdocs/charter.xml
  Index: charter.xml
  <?xml version="1.0"?>
  $Header: /home/cvs/db-commons/xdocs/charter.xml,v 1.1 2003/03/10 01:19:52 rwaldhoff Exp
  <author email="commons-dev@db.apache.org">DB Commons Documentation Team</author>
  <section name="Status">
  The charter for the DB Commons subproject of the 
  Apache DB project was approved by the Apache DB PMC 
  in February of 2003.
  <section name="Charter">
  <subsection name="(0) Rationale">
  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:
  <ol type="a">
  <li>create a space for small database oriented libraries in languages
  including but not limited to Java.</li>
  <li>foster a community of database oriented library developers. 
  (Currently the database focused components of Jakarta Commons are
  developed and maintained by a relatively small subset of the Jakarta Commons
  <li>encourage the development and extraction of reusable database related  
  components within other Apache DB subprojects.</li>
  <li>encourage the use of reusable database related components
  within other Apache DB subprojects and within the Apache DB community as 
  a whole.</li>
  <subsection name="(1) Scope">
  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.
  <subsection name="(1.5) Interaction with Other Subprojects">
  Other projects and subprojects are encouraged but 
  not required to contribute to and use the libraries developed
  within the DB Commons subproject.
  <subsection name="(1.5.1) The Sandbox">
  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. 
  <subsection name="(2) Initial Source">
  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.
  <subsection name="(3) Initial DB Resources to be Created">
  <subsection name="(3.1) Mailing Lists">
  <dd>the development discussion list</dd>
  <dd>the user discussion list</dd>
  <dt><i>component specific lists</i></dt>
  <dd>as activity dictates</dd>
  <subsection name="(3.2) Source Repositories">
  <subsection name="(3.3) Defect Tracking System">
  Within the defect tracking system, 
  a "db-commons" category, with one "general" sub-category,
  and one sub-category per component/library.
  <subsection name="(3.4) Web Site">
  The subproject will create an maintain a web site available
  at <code>http://db.apache.org/commons/</code>, and will 
  be integrated into the existing Maven reactor based build.
  <subsection name="(4) Initial Committers">
  <li>Steven Caswell</li>
  <li>Geir Magnusson Jr.</li>
  <li>Craig McClanahan</li>
  <li>John McNally</li>
  <li>Martin Poeschl</li>
  <li>Glenn Nielsen</li>
  <li>Daniel Rall</li>
  <li>James Strachan</li>
  <li>Rodney Waldhoff</li>
  <li>David Weinrich</li>
  <li>Henri Yandell</li>
  <li>Jason van Zyl</li>
  <section name="Guidelines">
  <li>The expressions "IS", "HAS", "WILL", and "MUST" indicate guidelines 
  that are required.</li>
  <li>The expressions "may", "should", and "are encouraged" indicate guidelines that

  are optional but recommended.</li>
  <li>The primary unit of reuse <b>IS</b> the primary unit of release. Within
  guidelines, we refer to this unit as a "component".</li>
  <li>The subproject <b>IS</b> a collection of components designed 
  to be used independently, not a framework.</li>
  <li>Each component <b>MUST</b> have a clearly defined purpose, scope,
and API -- Do 
  one thing well, and keep your contracts.</li>
  <li>Each component <b>IS</b> treated as a product in its own right.
  <li>Each component <b>HAS</b> its own status file, release schedule, version
  QA tests, documentation, defect category, and distribution.</li>
  <li>Each component <b>MUST</b> clearly specify any external dependencies,
  any other Commons components and external libraries.</li>
  <li>Each component <b>MUST</b> maintain a list of its active committers
in its 
  status file or other resource as determined by the DB Commons committers.</li>
  <li>External dependencies on optional and third-party codebases should be 
  <li>The components should use a standard scheme for versioning, QA tests, and 
  directory layouts, and a common format for documentation and build scripts.</li>
  <li>Where appropriate, the components should fit within a unified package 
  or namespace hierarchy.</li>
  <li>In general, components should provide an interface and one or more 
  implementations of that interface, or implement another interface already in 
  <li>Each component <b>WILL</b> be hosted on its own directory on the subproject
Web site, 
  and <b>WILL</b> also be indexed in a master directory or listing.</li>
  <li>The subproject <b>WILL</b> provide a catalog of components and related
  <li>The subproject <b>WILL</b> also host a top-level 'general' mailing
list in addition 
  to any lists for specific components.</li>
  <li>The subproject may provide distribution "bundles" that combine 
  several individual components into a single artifact.</li>
  <li>Volunteers <b>MUST</b> become committers to the DB Commons subproject
in the same 
  way they are entered to any Apache DB subproject. Being a committer in another 
  DB subproject is not a prerequisite.</li>
  <li>Each committer <b>HAS</b> karma to all the components, but committers
are required 
  to add their name to a package's status file before their first commit to that 
  <li>New components <b>MUST</b> be proposed to the DB Commons developer
mailing list. 
  To be accepted, a component proposal <b>MUST</b> receive majority approval of
the subproject
  committers. Proposals <b>MUST</b> identify the rationale for the component,
its scope, its 
  interaction with other components and products, the Commons resources, if any, to be 
  created, the initial source from which the component is to be created (together
  with a statement that this code may be distributed under an ASF license), the coding 
  conventions used for the component (if any) and the initial set of committers.
  (As stated in the Apache DB guidelines, an action requiring majority approval must 
  receive at least 3 binding +1 votes and more +1 votes than -1 votes.)</li>
  <li>It is expected that the scope of components may sometimes overlap.</li>
  <li>Anyone may propose a new component to the Commons, and list themselves as the

  initial committers. The vote on the proposal is then also a 
  vote to enter new committers to the subproject as needed.</li>
  <li>A CVS repository <b>WILL</b> be available to all Apache DB committers
as a workplace 
  for new components or other projects.  Before release to the public, code or 
  documentation developed here <b>MUST</b> 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.</li>
  <li>Each Commons component should use an internally consistent and documented
  coding style. When the source code for a component originates in a
  pre-existing code base outside of Commons, the coding style of that code
  base may be retained at the discretion of the component committers.</li>
  <li>Component developers are strongly encouraged to adhere to the following design
  <!-- "component cohesion" -->
  <dt>The Release/Reuse Equivalence Principle (REP)</dt>
  <dd>The unit of release should be equivalent to the unit of reuse. 
  (Also see the CRP).</dd>
  <dt>The Common Closure Principle (CCP)</dt>
  <dd>The artifacts within a component should be closed against the
  same kinds of change.  A change the affects one artifact in a component should
  be likely to affect them all.</dd>
  <dt>The Common Reuse Principle (CRP)</dt>
  <dd>The artifacts within a component should be (re)used together. A client that 
  uses one artifact in a component should be likely use them all.
  (Also see the REP.)</dd>
  <!-- "component coupling" -->
  <dt>The Acyclic Dependencies Principle (ADP)</dt>
  <dd>There should be no cycles within the dependency graph.</dd>
  <dt>The Stable Dependencies Principle (SDP)</dt>
  <dd>A component should only depend upon components at least
  as stable as the component itself.</dd>
  <dt>The Stable Abstractions Principle (SAP)</dt>
  <dd>A component should contain as many stable abstractions as
  possible, and these should be isolated from the artifacts 
  that are likely to change.</dd>
  <!-- "artifact design" -->
  <dt>The Open Closed Principle (OCP)</dt>
  <dd>An artifact should open for extension but closed for
  modification. In other words, it should be depend possible
  to alter the behavior of an artifact without modifying its
  <dt>The Liskov Substitution Principle (LSP)</dt>
  <dd>An instance of a derived type should be able to replace any 
  instance of its parent.  In other words, subclasses should
  adhere to the contracts of their parents, so that clients of the
  base class function equally well when provided with an instance
  of some class derived from that base.</dd>
  <dt>The Interface Segregation Principle (ISP)</dt>
  <dd>An artifact should depend upon the smallest possible interface.  
  Prefer many specific interfaces to a single monolithic one.</dd>
  <dt>The Dependency Inversion Principle (DIP)</dt>
  <dd>An artifact should depend abstract interfaces rather than
  concrete implementations.</dd>
  See <a href="http://www.c2.com/cgi/wiki?OoDesignPriciples">http://www.c2.com/cgi/wiki?OoDesignPriciples</a>
  <a href="http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF">many</a>

  <a href="http://isbn.nu/0136291554">other</a> 
  <a href="http://isbn.nu/0521777682">sources</a> 
  for additional information.
  <li>As an Apache DB subproject, the Commons adopts all other guidelines and 
  procedures of the DB project and the Apache Software Foundation, as they may 
  be amended from time to time.</li>
  <section name="Example Package Proposal">
  This is simply an example.  It is not a formal proposal, let alone a binding one.
  <strong>Proposal for Mock JDBC Objects Component</strong>
  <p>(0) rationale</p>
  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 [1]. 
  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.
  [1] See <a href="http://www.mockobjects.com/endotesting.html">http://www.mockobjects.com/endotesting.html</a>
  <p>(1) scope of the component</p>
  The component shall create and maintain a collection of "mock" JDBC objects to be distributed
  the ASF license, supporting unit testing of JDBC based or derived applications using an
  The component should be extensible so that clients that require additional "mock" functionality
  are able to add it.
  <p>(1.5) interaction with other components</p>
  <p>It is expected, but certainly not required, that other DB Commons components will
  advantage of this component.</p>
  <p>(2) identify the initial source for the component</p>
  <p>The initial codebase was developed within the Jakarta Commons DBCP component, 
  and further developed within the Jakarta Commons Sandbox under the DbUtils component.</p>
  <p>(2.1) identify the base name for the component</p>
  <p>(2.2) identify the coding conventions for this component</p>
  <p>The code follows the standard Sun code conventions.</p>
  <p>(3) identify any DB Commons resources to be created</p>
  <p>(3.1) mailing list</p>
  <p>Until traffic justifies, the component will use the general DB Commons lists for
  <p>(3.2) CVS repositories</p>
  <p>For the time being, the component will use a <code>mockjdbc</code>
branch of the DB-Commons CVS.</p>
  <p>(3.3) Bugzilla</p>
  <p>The component should be listed as a component of the DB Commons Bugzilla entry.</p>
  <p>(3.4) Jyve FAQ (when available)</p>
  <p>(4) identify the initial set of committers to be listed in the Status File.</p>
  Steven Caswell<br/>
  Rodney Waldhoff<br/>
  Henri Yandell
  1.1                  db-commons/xdocs/stylesheets/project.xml
  Index: project.xml
  <?xml version="1.0"?>
  $Header: /home/cvs/db-commons/xdocs/stylesheets/project.xml,v 1.1 2003/03/10 01:19:52 rwaldhoff
Exp $
  <project name="DB Commons" href="http://db.apache.org/commons">
    <title>DB Commons</title>
      <menu name="Home">
        <item name="Apache DB Project"       href="http://db.apache.org/" />
        <item name="DB Commons Project"      href="/index.html" />
      <menu name="Project Information">
        <item name="Mailing Lists"           href="/mail-lists.html" />
        <item name="Who We Are"              href="/team-list.html" />
      <menu name="Project Documents">
        <item name="Charter and Guidelines"  href="/charter.html" />

View raw message