Martin Cooper wrote:
+1 to just one dev and one user list, shared for all components, a la
Jakarta Commons.
Me too...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Sat, 2005-07-02 at 14:33 -0400, Martin Cooper wrote:
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
4.1 in the guidelines repeats the error that I thought was fixed in the
j-c guidelines saying that each package has
On Sat, 2005-07-02 at 12:27 -0700, Phil Steitz wrote:
Martin Cooper wrote:
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
snip
Interpreted literally, 17 goes against standard practice in jakarta (or
apache, to my
robert burrell donkin wrote:
snip/
Agreed. After a little more discussion, we should rewrite this.
+1
anyone feel like jumping volunteering to come up with a draft?
Working on this now...
Phil
-
To unsubscribe,
On 6/25/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
Rahul Akolkar wrote:
is boils down to the question: does this subproject need it's own
sandbox or will neophyte components start in the jakarta commons
sandbox?
+1 for sandbox (non-binding)
Its slightly hard to imagine anything
On 6/25/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
this has proved impractical in the jakarta commons. i propose we drop
point 12.
12. The subproject will also provide a single JAR of all stable package
releases. It may also provide a second JAR with a
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
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
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
snip
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
Martin Cooper wrote:
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
snip
Interpreted literally, 17 goes against standard practice in jakarta (or
apache, to my knowledge, other than in the incubator). I would
recommend that
Rahul Akolkar wrote:
is boils down to the question: does this subproject need it's own
sandbox or will neophyte components start in the jakarta commons
sandbox?
+1 for sandbox (non-binding)
Its slightly hard to imagine anything otherwise, but maybe I'm just
used to seeing how commons and
robert burrell donkin wrote:
this has proved impractical in the jakarta commons. i propose we drop
point 12.
12. The subproject will also provide a single JAR of all stable package
releases. It may also provide a second JAR with a subset of only JDK 1.1
compatible releases. A gump of nightly
robert burrell donkin wrote:
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
9 or somewhere else should speak to J2EE or other external config
requirments, which should be fine, even encouraged in some cases
is 9 needed? are any configuration guidelines needed?
if they are then i
Stephen Colebourne wrote:
robert burrell donkin wrote:
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
9 or somewhere else should speak to J2EE or other external config
requirments, which should be fine, even encouraged in some cases
is 9 needed? are any configuration guidelines
I would love to see a very light weight WebDAV servlet which could be
taken from Tomcat.
Oliver
On 6/24/05, Henri Yandell [EMAIL PROTECTED] wrote:
Just looking within Jakarta, the following all jump out as initial code:
http://svn.apache.org/repos/asf/jakarta/commons/sandbox/servlet/ has a
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
snip
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 ;-)
everything borrowed, in fact. not that it'll stay that way for long...
A couple of things
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
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.
it was intentional in
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
9 or somewhere else should speak to J2EE or other external config
requirments, which should be fine, even encouraged in some cases
is 9 needed? are any configuration guidelines needed?
if they are then i agree that they should encourage
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
snip
Don't know what kind of goo 12 would result in or who would use such a
thing ;-)
this has proved impractical in the jakarta commons. i propose we drop
point 12.
- robert
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
snip
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
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
snip
I guess 18 refers to the sandbox? I do not understand what the intent
of this is.
is boils down to the question: does this subproject need it's own
sandbox or will neophyte components start in the jakarta commons
sandbox?
- robert
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
snip
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
In reading through this all, I have a concern that it will be difficult
for any outside code to come in. Indeed it has proven difficult for
many people I have spoken to to get code into any Commons project
(although I myself had some things accepted, so clearly it is not
impossible).
What
I'm not sure I understand #12... is it talking about providing a JAR of
a release for archival purposes?
I would like to see this project adopt the packaging scheme my own Java
Web Parts project has in that each actual Java package is JAR'd
separately. That way a developer can easily pick
I'm not sure I understand #12... is it talking about providing a JAR of
a release for archival purposes?
I would like to see this project adopt the packaging scheme my own Java
Web Parts project has in that each actual Java package is JAR'd
separately. That way a developer can easily pick and
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
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
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
snip
Don't know what kind of goo 12 would result in or who would use such a
thing ;-)
this has proved impractical in the jakarta commons. i propose we drop
point 12.
-
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
snip
I guess 18 refers to the sandbox? I do not understand what the intent
of this is.
is boils down to the question: does this subproject need it's own
sandbox or will
On Fri, 17 Jun 2005, 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
Just looking within Jakarta, the following all jump out as initial code:
http://svn.apache.org/repos/asf/jakarta/commons/sandbox/servlet/ has a
couple of classes (as you know :) ).
Taglibs of course, I estimate half a dozen to ten taglibs.
Commons FileUploa.
Commons Http
Frank W. Zammetti wrote:
In reading through this all, I have a concern that it will be difficult
for any outside code to come in. Indeed it has proven difficult for
many people I have spoken to to get code into any Commons project
(although I myself had some things accepted, so clearly it is
Frank W. Zammetti wrote:
I'm not sure I understand #12... is it talking about providing a JAR of
a release for archival purposes?
I think that in the early (actually as recently as a year or so ago)
days of Jakarta Commons, a combo jar was produced that included *all*
of the commons
On Sun, 2005-06-19 at 15:34 -0400, Frank W. Zammetti wrote:
robert burrell donkin wrote:
web parts is a good name.
I thought so... that's why I chose it ;)
trademarks are of particular importance for
the ASF but it's also important to do the right thing ethically. i
wouldn't be
robert burrell donkin wrote:
that's understandable but is likely to cause wrinkles in the approval
process. a subproject needs a name and a charter before it can be
approved. no guarantees could be offered since accepting new committers
is something that sould be delegated to the new community.
Can we please separate the two different topics being discussed here?
The original purpose of this discussion was to see if there is general
concensus that a Webapp Commons (or whatever name we end up with) is a
good idea. If we think it is, then we need to develop a charter, come up
with a
I'll step back and let you guys get it off the ground then...
However, the one point that I believe to be very relevant at this
junction, in light of what Robert has said about a name being required
up-front, is that I may not be willing to give up the Java Web Parts
name. Since that was one
On Wed, 2005-06-22 at 16:53 -0400, Frank W. Zammetti wrote:
I'll step back and let you guys get it off the ground then...
no one's asking you to step back :)
the reason why this discussion was moved to this forum was to encourage
people to get involved with the discussion and help to shape the
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
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
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
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
Java Web Parts is the name of the SF project I began that is exactly
what is being described here. Not that I have a trademark on it or
anything, and besides, I don't have enough lawyers to trademark common
words, like oh, I don't know, Windows?!? :)
Incidentally, I was one of the people
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
41 matches
Mail list logo
