Morgan Delagrange wrote:
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off?
At this point, most people seemed to want to start with the JDBC
pool. I also suggested we also work on a testing framework, along
with the support structure.
The poll for that went up yesterday, at this point we have 4
positive votes for that course of action, out of the ten active
participants on this list.
< http://husted.com/about/jakarta/lib003.htm >
Two other participants are apparently abstaining.
--
"Geir Magnusson Jr." wrote:
> Another thing is that Sam Ruby mentioned what he thought might be
> appropriate (I can't find the post now - it was a little while ago), and
> maybe we should review that too and take a hint :)
>Sam Ruby wrote:
> Testing and documentation requirements.
There are testing frameworks breaking out all over Jakarta right now.
One very active initiative is taking place in Struts as part of the
upcoming beta-testing for the 1.0 release (the release plan is now
in-vote). It's important to note that this is a contributor-based
initiative, rather than something the "committers" started, and is now
seeing wide support.
I would suggest that anyone interesting in testing join in on the Struts
initiative now, to see if we can use it as a base for the library
testing requirements. I think people who haven't been involved in Struts
will be very welcome, since they will not have preconceived notions.
After all, we need to test this to be sure it works for newbies. The
rest of us have been doing our own ad-hoc testing for months.
As to documentation requirements for the packages, my first thoughts are
(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
--
Sam's other recent "steering" comments are here:
<
http://www.mail-archive.com/library-dev%40jakarta.apache.org/msg00012.html
>
-T.
