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]
robert burrell donkin wrote:
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, e-mail: [
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:
> >>
> >>
> >>
> >>>Interpreted literally, 17 goes against standard practice in jakarta (or
>
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 p
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:
Interpreted literally, 17 goes against standard practice in jakarta (or
apache, to my knowledge, other than in the incubator). I would
recommend that new
On 6/23/05, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
>
>
>
> > Interpreted literally, 17 goes against standard practice in jakarta (or
> > apache, to my knowledge, other than in the incubator). I would
> > recommend that new packag
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 th
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
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
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 nee
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 agre
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
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 tagli
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/
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 compone
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 n
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
(http://svn.apache
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 stru
On 6/23/05, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
>
>
>
> > 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 o
On 6/23/05, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
>
>
>
> > 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 1
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 th
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 ch
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
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 is
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
> 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
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
> 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:
> 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 recom
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
> 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
--8<---
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:
> 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:
> 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 s
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
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 co
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
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
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 na
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.
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
> > wou
First of all, happy Father's Day to all my fellow male parental units
out there... hope you got to sleep in... I didn't :(
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 impo
On Fri, 2005-06-17 at 19:38 -0400, Frank W. Zammetti wrote:
> 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 d
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 invo
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
compon
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 ap
43 matches
Mail list logo
