OLD BUSINESS
Subproject Guidelines - 6 +1s out of a possible 11 (eight responding).
First packages - 6 +1s out of a possible 11 (eight responding).
< http://husted.com/about/jakarta/lib003.htm >
NEW BUSINESS
Documentation and testing requirements
As a starting point for documentation requirements, I would suggest the
following:
(0) substantial JavaDocs (of course),
(1) a standard catalog entry, outlining the package's "high concept"
(purpose and scope), prerequisites, release history, mailing list and
archive links, FAQ and Bugzilla links, and active committers
("whoWeAre"),
(2) a developer's guide, that explains how to use the package in more
detail, developer to developer,
(3) a quick-start installation page for people who just want to plug it
in,
(4) obligatory quick-start FAQ,
--
An example of a developer's guide is here:
<
http://jakarta.apache.org/struts/api/org/apache/struts/taglib/bean/package-summary.html#package_description
>
"(1)" would be the foundation for a CJAN type catalog, and might
ultimately land in a database.
--
As to the Web site documentation requirements, my first thoughts are
(0) Mission statement
(1) General guidelines (part (1) of recent poll)
(2) Catalog (collection of (1) above)
(3) Primer (package creation, use, and abuse)
(4) Standards - naming hierarchy, testing requirements; sample directory
layout, build file, documentation
(5) Interactive FAQ (Jyve, if it can be fixed)
(6) Omnibus index to mailing lists, archives, bugzilla, and master list
of committers
--
As to testing requirements, the obvious starting points are Junit,
J2EEUnit, and HttpUnit.
< http://junit.org/ >
< http://j2eeunit.sourceforge.net/ >
< http://sourceforge.net/projects/httpunit >
To the extent possible, we should try an integrate testing with Ant.
This could lead to a gump that not only builds code, but tests it as
well.-)
There's some initial background on this at
<
http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg00481.html
>
-Ted.
