Stephen Colebourne wrote:
robert burrell donkin wrote:
there have been a number of long running threads in the commons
discussing the possibility of commons components for use in web
applications. the consensus emerged that it would be best if a new
subproject with a structure similar to the commons was created for
components intended for use in web applications.
opinions, please!
I am in favour of this, although whether I would be able to spare much
time is debatable.
I am also in favor, also not likely to have much time to contribute.
Here are some comments on the draft charter.
It is nice to see so much borrowed from the (at least I think)
successful j-c model ;-)
A couple of things should be changed, though, IMHO.
First in the scope statement "intended for use in server-related
development" could be narrowed to "web application development"
Uniformly change CVS to SVN (I assume! :)
4.1 in the guidelines repeats the error that I thought was fixed in the
j-c guidelines saying that each package has its own mailing list. If
that is intentional, I think that is a *bad* idea, especially to start.
4.2 should probably reference JSP/Servlet spec level requirements as
well as JDK requirements
+1 to bullet under 7 :-)
9 or somewhere else should speak to J2EE or other external config
requirments, which should be fine, even encouraged in some cases
Don't like the many little lists implied by 11 -- dev + user works fine
in j-c (I know some disagree, but I personally view this as the key to
the health of j-c)
Don't know what kind of goo 12 would result in or who would use such a
thing ;-)
Interpreted literally, 17 goes against standard practice in jakarta (or
apache, to my knowledge, other than in the incubator). I would
recommend that new packages require existing committers to support them.
I would at least recommend changing "Anyone" to "Any apache committer."
If an individual has already contributed enough to be voted in as a
committer, then that should be done in a separate VOTE.
I guess 18 refers to the sandbox? I do not understand what the intent
of this is.
One final thing to think about. I know lots of apache people are
opposed to "umbrella projects" for lots of reasons, one of which is the
fragmentation and abandonment that can result. We have certainly not
been immune to that in j-c. Two things that have been critical to
keeping us going have been 1) a relatively small (changing over time)
set of key contributors who look after multiple components and 2) some
"large internal customers" (tomcat, struts, maven et al) whose
committers jump in to push things along as needed. This project would
be starting without the "large internal customers." It would probably
be a good idea, therefore, to start with a narrower, rather than broader
scope, so that the fledgling community would not get fragmented too
quickly and the "key contributors" could emerge. Just a thought.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
