You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by Morgan Delagrange <md...@yahoo.com> on 2001/02/23 06:57:17 UTC
Library project reset
Hi all,
Maybe it's time for a reset here? Instead of worrying
so much about other subprojects, why don't we focus on
creating good stand-alone libraries? After all, we
can't force anybody to adopt our libraries if they
don't want to. Even if only some projects adopt our
libraries within their framework, I'd say we've still
made progress and provided more accessible
distributions. Practically every Java project in
Apache (including Struts, Avalon, and Turbine) is
organized at the framework level, and I think it's
time for more discrete packaging.
I propose that we move forward with a dedicated set of
committers in a fashion similar to Taglibs and not
attempt to please every subproject. In fact, trying
to meet everyone's needs simultaneously would probably
lead to disaster. If this is a good idea, our
components will converge with their frameworks in
time.
We've got lots of good ideas, such as more focused
documentation and more minimal and explicit
dependencies. By getting mired in the minutiae, we're
going to lose sight of the single important goal,
which is to produce quality stand-alone components.
How about we pick one or two components, gather some
likely starting candidates for a baseline, and have a
cook-off? Really, if we don't work in a small group,
it's going to be group-vs.-group-vs.-group,
my-framework-is-better-than-your-framework, and
nothing will be accomplished.
- Morgan
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Re: Library project reset
Posted by cm...@yahoo.com.
> 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.
>
Re: Library project reset
Posted by cm...@yahoo.com.
> 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.
>
Re: Library project reset
Posted by Ted Husted <ne...@husted.com>.
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.
Re: Library project reset
Posted by Federico Barbieri <sc...@betaversion.org>.
Morgan Delagrange wrote:
>
> Hi all,
>
> Maybe it's time for a reset here? Instead of worrying
> so much about other subprojects, why don't we focus on
> creating good stand-alone libraries? After all, we
> can't force anybody to adopt our libraries if they
> don't want to. Even if only some projects adopt our
> libraries within their framework, I'd say we've still
> made progress and provided more accessible
> distributions. Practically every Java project in
> Apache (including Struts, Avalon, and Turbine) is
> organized at the framework level, and I think it's
> time for more discrete packaging.
>
> I propose that we move forward with a dedicated set of
> committers in a fashion similar to Taglibs and not
> attempt to please every subproject. In fact, trying
> to meet everyone's needs simultaneously would probably
> lead to disaster. If this is a good idea, our
> components will converge with their frameworks in
> time.
>
> We've got lots of good ideas, such as more focused
> documentation and more minimal and explicit
> dependencies. By getting mired in the minutiae, we're
> going to lose sight of the single important goal,
> which is to produce quality stand-alone components.
>
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off? Really, if we don't work in a small group,
> it's going to be group-vs.-group-vs.-group,
> my-framework-is-better-than-your-framework, and
> nothing will be accomplished.
>
> - Morgan
>
+1000.
I guess we have to
-pick up 2 or 3 components from the list already discussed,
-populate the CVS
-write some kind of spec (what this is supposed to do, APIs etc) from
what's already there and what can be done to make it more generic (wider
users scope)
-maybe propose these spec to an extended group of people for tuning...
During the process we will tune the "library guidelines" in terms of doc
requirements, testing etc.
as test project sounds like connection pool is a good candidate.
Fede
Re: Library project reset
Posted by Ted Husted <ne...@husted.com>.
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.
Re: Library project reset
Posted by Federico Barbieri <sc...@betaversion.org>.
Morgan Delagrange wrote:
>
> Hi all,
>
> Maybe it's time for a reset here? Instead of worrying
> so much about other subprojects, why don't we focus on
> creating good stand-alone libraries? After all, we
> can't force anybody to adopt our libraries if they
> don't want to. Even if only some projects adopt our
> libraries within their framework, I'd say we've still
> made progress and provided more accessible
> distributions. Practically every Java project in
> Apache (including Struts, Avalon, and Turbine) is
> organized at the framework level, and I think it's
> time for more discrete packaging.
>
> I propose that we move forward with a dedicated set of
> committers in a fashion similar to Taglibs and not
> attempt to please every subproject. In fact, trying
> to meet everyone's needs simultaneously would probably
> lead to disaster. If this is a good idea, our
> components will converge with their frameworks in
> time.
>
> We've got lots of good ideas, such as more focused
> documentation and more minimal and explicit
> dependencies. By getting mired in the minutiae, we're
> going to lose sight of the single important goal,
> which is to produce quality stand-alone components.
>
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off? Really, if we don't work in a small group,
> it's going to be group-vs.-group-vs.-group,
> my-framework-is-better-than-your-framework, and
> nothing will be accomplished.
>
> - Morgan
>
+1000.
I guess we have to
-pick up 2 or 3 components from the list already discussed,
-populate the CVS
-write some kind of spec (what this is supposed to do, APIs etc) from
what's already there and what can be done to make it more generic (wider
users scope)
-maybe propose these spec to an extended group of people for tuning...
During the process we will tune the "library guidelines" in terms of doc
requirements, testing etc.
as test project sounds like connection pool is a good candidate.
Fede
Re: Library project reset
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Morgan Delagrange wrote:
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off? Really, if we don't work in a small group,
> it's going to be group-vs.-group-vs.-group,
> my-framework-is-better-than-your-framework, and
> nothing will be accomplished.
Right. We can do more shouting later when we have something to shout
about.
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 :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Library project reset
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Morgan Delagrange wrote:
> How about we pick one or two components, gather some
> likely starting candidates for a baseline, and have a
> cook-off? Really, if we don't work in a small group,
> it's going to be group-vs.-group-vs.-group,
> my-framework-is-better-than-your-framework, and
> nothing will be accomplished.
Right. We can do more shouting later when we have something to shout
about.
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 :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/