> 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.
I am interested in the last 2.
Regarding the testing framework - I don't know what will be the schedule,
tomcat3.3 needs it _now_, so development on the <gtest> will continue
inside tomcat. If we create the library CVS I'll ask tomcat-dev to move
the gtest in a library sub-project ( if the library rules will allow it
) and try to merge it with whatever testing frameworks will be
contributed.
( the <gtest> in 3.3 is just a way to
describe requests and expected responses in xml - using ant as a driver to
execute the script, and a taglib to do it from a web page. There are few
hundred tests using it, but with a small XSL we can change it to whatever
DTD will be used in the shared framework - if similar capabilities will
exist ).
Regarding the build framework - I would like to help, but after
tomcat-3.3Beta.
Costin
>
> 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.
>
