You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by robert burrell donkin <rd...@apache.org> on 2005/06/16 23:53:50 UTC
[PROPOSAL] subproject that's a home for bricks reusable in java
web applications
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!
in particular:
a charter needs to be developed (based on the commons one)
a name needs to found
(feel free to start new threads on these topics)
some debate has already started on various lists (pmc, commons-dev,
taglibs) but all are invited to consolidate the discussions onto this
list...
- robert
Re: [PROPOSAL] subproject that's a home for bricks reusable in
java web applications
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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 sub
project. consider staying and doing that.
it's important to understand that there's a distinction between
importing existing code into apache (which would mean incubation to
build a community, educate committers and ensure there were no legal
issues) and collaborating in the development of new code covering
similar ground.
i can think of (at least) one example of a Jakarta Commons committer who
developed open source libraries covering similar ground. the apache
contributions were new code and so the question of importing code does
not arise.
> 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 of the suggestions, I think that is a relevant
> point. And since mere similarity of names was mentioned by someone as
> well, it is that much more relevant.
fine (feel free to remove any names you're not happy with from the wiki)
> Martin Cooper wrote:
> > Can we please separate the two different topics being discussed here?
+1
we need to start some new threads with better subjects...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in java
web applications
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 of the suggestions, I think that is a relevant
point. And since mere similarity of names was mentioned by someone as
well, it is that much more relevant.
Frank
Martin Cooper wrote:
> 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 name, and officially make the proposal to the PMC. We also need
> to discuss other aspects, such as whether or not we want to follow the
> Jakarta Commons model, with separate Proper and Sandbox components.
>
> Once we've got to that point, we can have discussions about the various
> sources from which code might be contributed. Some of those will be from
> inside of Jakarta, or other ASF projects, and some might be from
> external sources. IMHO, the discussion of potential external sources and
> potential new ASF committers is premature at this point. I think we need
> to get off the ground first.
>
> Finally, I'll point out that any substantive contributions would need to
> come in through the incubator. That being the case, we're not in any
> position to make judgements or promises, here and now, about what can be
> brought in and / or who may or may not become committers on the new
> subproject.
>
> (Frank, I am *not* trying to shut you out. I'm simply trying to get the
> new subproject off the ground without complicating things by discussing
> external elements prematurely.)
>
> --
> Martin Cooper
>
>
> On Wed, 22 Jun 2005, Frank W. Zammetti wrote:
>
>> 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.
>>
>>
>> I definitely see the conundrum.
>>
>> You touched on something too that I hadn't even brought up directly...
>> If I'm going to give up the name, and end my project and contribute
>> all the code I've written, I don't think it is unreasonable to ask to
>> be a committer on the new Jakarta project.
>>
>> I may be mistaken, but I thought part of the approval process is a
>> list of initial committers? I thought I had seen that at one point on
>> the new project proposal paperwork. If so, I'd say that could take
>> care of this part of things because I could be named a committer
>> initially, then everything else as far as names and initial code goes
>> falls in to place pretty easily.
>>
>>> anyone have any opinions about this?
>>
>>
>> If the above isn't true, one possible suggestion is to proceed with a
>> contingent name... The contingency being the community accepting me as
>> a committer. There would still be a name in reserve if that should
>> not happen.
>>
>> I hope I'm not coming across like an a**hole here trying to worm my
>> way in... I believe what I'm saying is reasonable, if anyone disagrees
>> please feel free to tell me so.
>>
>>> if you could leave it a little while before changing the name of your
>>> project to WP4J, that might give us some time to prepare the documents
>>> in...
>>
>>
>> I actually didn't mean I would change my project name... In my mind,
>> there are three possible paths here...
>>
>> One is that the Jakarta project takes my name, and my projects ends
>> and all the code is contributed. Two is that the Jakarta project
>> takes a completely different name and I still end my project and
>> contribute all the code. Third is that my project continues as-is and
>> the Jakarta project takes a completely different name.
>>
>> There is the fourth option of me changing my proejects' name and
>> keeping in separate, but that presents problems for me at this point
>> so I wouldn't be especially inclined to do that. I suppose I wouldn't
>> rule it completely out, but it would definitely be last on my list.
>>
>> Frank
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in java
web applications
Posted by Martin Cooper <ma...@apache.org>.
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 name, and officially make the proposal to the PMC. We also need to
discuss other aspects, such as whether or not we want to follow the
Jakarta Commons model, with separate Proper and Sandbox components.
Once we've got to that point, we can have discussions about the various
sources from which code might be contributed. Some of those will be from
inside of Jakarta, or other ASF projects, and some might be from external
sources. IMHO, the discussion of potential external sources and potential
new ASF committers is premature at this point. I think we need to get off
the ground first.
Finally, I'll point out that any substantive contributions would need to
come in through the incubator. That being the case, we're not in any
position to make judgements or promises, here and now, about what can be
brought in and / or who may or may not become committers on the new
subproject.
(Frank, I am *not* trying to shut you out. I'm simply trying to get the
new subproject off the ground without complicating things by discussing
external elements prematurely.)
--
Martin Cooper
On Wed, 22 Jun 2005, Frank W. Zammetti wrote:
> 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.
>
> I definitely see the conundrum.
>
> You touched on something too that I hadn't even brought up directly... If I'm
> going to give up the name, and end my project and contribute all the code
> I've written, I don't think it is unreasonable to ask to be a committer on
> the new Jakarta project.
>
> I may be mistaken, but I thought part of the approval process is a list of
> initial committers? I thought I had seen that at one point on the new
> project proposal paperwork. If so, I'd say that could take care of this part
> of things because I could be named a committer initially, then everything
> else as far as names and initial code goes falls in to place pretty easily.
>
>> anyone have any opinions about this?
>
> If the above isn't true, one possible suggestion is to proceed with a
> contingent name... The contingency being the community accepting me as a
> committer. There would still be a name in reserve if that should not happen.
>
> I hope I'm not coming across like an a**hole here trying to worm my way in...
> I believe what I'm saying is reasonable, if anyone disagrees please feel free
> to tell me so.
>
>> if you could leave it a little while before changing the name of your
>> project to WP4J, that might give us some time to prepare the documents
>> in...
>
> I actually didn't mean I would change my project name... In my mind, there
> are three possible paths here...
>
> One is that the Jakarta project takes my name, and my projects ends and all
> the code is contributed. Two is that the Jakarta project takes a completely
> different name and I still end my project and contribute all the code. Third
> is that my project continues as-is and the Jakarta project takes a completely
> different name.
>
> There is the fourth option of me changing my proejects' name and keeping in
> separate, but that presents problems for me at this point so I wouldn't be
> especially inclined to do that. I suppose I wouldn't rule it completely out,
> but it would definitely be last on my list.
>
> Frank
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in java
web applications
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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.
I definitely see the conundrum.
You touched on something too that I hadn't even brought up directly...
If I'm going to give up the name, and end my project and contribute all
the code I've written, I don't think it is unreasonable to ask to be a
committer on the new Jakarta project.
I may be mistaken, but I thought part of the approval process is a list
of initial committers? I thought I had seen that at one point on the
new project proposal paperwork. If so, I'd say that could take care of
this part of things because I could be named a committer initially, then
everything else as far as names and initial code goes falls in to place
pretty easily.
> anyone have any opinions about this?
If the above isn't true, one possible suggestion is to proceed with a
contingent name... The contingency being the community accepting me as a
committer. There would still be a name in reserve if that should not
happen.
I hope I'm not coming across like an a**hole here trying to worm my way
in... I believe what I'm saying is reasonable, if anyone disagrees
please feel free to tell me so.
> if you could leave it a little while before changing the name of your
> project to WP4J, that might give us some time to prepare the documents
> in...
I actually didn't mean I would change my project name... In my mind,
there are three possible paths here...
One is that the Jakarta project takes my name, and my projects ends and
all the code is contributed. Two is that the Jakarta project takes a
completely different name and I still end my project and contribute all
the code. Third is that my project continues as-is and the Jakarta
project takes a completely different name.
There is the fourth option of me changing my proejects' name and keeping
in separate, but that presents problems for me at this point so I
wouldn't be especially inclined to do that. I suppose I wouldn't rule
it completely out, but it would definitely be last on my list.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: [PROPOSAL] subproject that's a home for bricks reusablein java web applications
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Or Jakarta Web Parts For Java, or JWP4J, which has the benefit of
> > being what I am now (JWP) with 4J appended. I for one like it!
> that sounds good to me too.
> anyone else have an opinion?
I believe that the PRC wants an Apache branding, but check.
Sorry for short reply, but my computer is literally in the process of dying
for the second time in a month (after repair), and I'm quickly posting this
before shutting down. I'll be offline for at least a few days.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable
in java web applications
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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 happy to see a jakarta subproject take the name of a related
> > open source project against the wishes of those involved in that
> > project.
>
> It might be worth noting that this weekend marked the first actual
> release of my project... granted it's a pre-alpha release, but a release
> none the less. I am still interested in collapsing my project into this
> new Jakarta sub-project, hence my participation in this discussion... if
> that happens, Jakarta Web Parts sounds good to me, I'd have no problem
> closing down my project and passing the name along. If my project
> remains separate though, I'd prefer to not have to change my name :)
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.
anyone have any opinions about this?
> > web parts appears to in use by dot net. not sure whether anyone holds
> > trademarks. FWIW AIUI sun are opposed to names such as java web parts
> > (trademark reasons): they believe it should be web parts for java
> > (WP4J).
>
> Well, if it is part of .Net, then maybe I have to change mine anyway :)
> In any case, I actually very much like the Sun approach here, although
> I'm not sure I know why! Web Parts For Java (WP4J) sounds pretty
> good... although JWP is a shorter abbreviation ;)
if you could leave it a little while before changing the name of your
project to WP4J, that might give us some time to prepare the documents
in...
> > in any case, the official name would be jakarta web parts (or jakarta
> > web bricks). if a consensus emerges then the pmc could probably check
> > out the legal side.
>
> Or Jakarta Web Parts For Java, or JWP4J, which has the benefit of being
> what I am now (JWP) with 4J appended. I for one like it!
that sounds good to me too.
anyone else have an opinion?
> > this leads to the question: what's the best way to develop the charter?
> >
> > i've been contemplating using the wiki to store a working draft whilst
> > debating content on this list. opinions?
>
> That seems reasonable to me... In fact, what might be nice is to have a
> link off the Wiki page labeled Request For Comments... that way people
> can post their ideas to that without the possibility of missing anything
> on the mailing list, and without changing the content outright... I'm
> sure we all have our filters set up and we all try to manually filter as
> well, and I for one can't say I've never missed something I would have
> been interested in.
that sounds like a good plan.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in java
web applications
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 important to do the right thing ethically. i
> wouldn't be happy to see a jakarta subproject take the name of a related
> open source project against the wishes of those involved in that
> project.
It might be worth noting that this weekend marked the first actual
release of my project... granted it's a pre-alpha release, but a release
none the less. I am still interested in collapsing my project into this
new Jakarta sub-project, hence my participation in this discussion... if
that happens, Jakarta Web Parts sounds good to me, I'd have no problem
closing down my project and passing the name along. If my project
remains separate though, I'd prefer to not have to change my name :)
> web parts appears to in use by dot net. not sure whether anyone holds
> trademarks. FWIW AIUI sun are opposed to names such as java web parts
> (trademark reasons): they believe it should be web parts for java
> (WP4J).
Well, if it is part of .Net, then maybe I have to change mine anyway :)
In any case, I actually very much like the Sun approach here, although
I'm not sure I know why! Web Parts For Java (WP4J) sounds pretty
good... although JWP is a shorter abbreviation ;)
> in any case, the official name would be jakarta web parts (or jakarta
> web bricks). if a consensus emerges then the pmc could probably check
> out the legal side.
Or Jakarta Web Parts For Java, or JWP4J, which has the benefit of being
what I am now (JWP) with 4J appended. I for one like it!
> the new subproject would need a charter. development of the charter is
> required before the subproject could start. the vision will be embedded
> in the charter so it's subject to development by the community but
> (personally speaking) i had in mind something very similar.
Glad to hear it! If everyone else is thinking along the same lines I'd
say I'm into it as well.
> this leads to the question: what's the best way to develop the charter?
>
> i've been contemplating using the wiki to store a working draft whilst
> debating content on this list. opinions?
That seems reasonable to me... In fact, what might be nice is to have a
link off the Wiki page labeled Request For Comments... that way people
can post their ideas to that without the possibility of missing anything
on the mailing list, and without changing the content outright... I'm
sure we all have our filters set up and we all try to manually filter as
well, and I for one can't say I've never missed something I would have
been interested in.
> - robert
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in
java web applications
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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 don't know, Windows?!? :)
web parts is a good name. trademarks are of particular importance for
the ASF but it's also important to do the right thing ethically. i
wouldn't be happy to see a jakarta subproject take the name of a related
open source project against the wishes of those involved in that
project.
web parts appears to in use by dot net. not sure whether anyone holds
trademarks. FWIW AIUI sun are opposed to names such as java web parts
(trademark reasons): they believe it should be web parts for java
(WP4J).
maybe web bricks might be a possible alternative (but this name is also
already used by a web site).
in any case, the official name would be jakarta web parts (or jakarta
web bricks). if a consensus emerges then the pmc could probably check
out the legal side.
> Incidentally, I was one of the people involved in those threads
> discussing this idea... I could be persuaded to fold my work into this
> subproject, but I would like to see that the consensus on direction is
> similar to what I've done. Perhaps I should briefly describe my project...
>
> It is what we are discussing here: a repository for small, generally
> independent components of interest to general Java webapp developers.
> It consists of a number of packages including Filters, Servlets,
> Taglibs, Request (general request-related utilities), Response (general
> response-related utilities and Session (I think you see the pattern!).
> Right now I have 3 filters, 1 servlet and some miscellaneous code in the
> other packages... There will likely be more after tonight in CVS.
>
> In fact, the only packages with nothing at this point is the Response
> and Taglib packages.
>
> I have a list of over a dozen things I intend to build over the next few
> weeks. Also included in all this is a single webapp that demonstrates
> and tests all components. Some others have expressed interest in
> contributing as well and I am awaiting their code to add.
>
> Each of these packages gets JARed separately, so a developer can pick
> and choose as they see fit. Cross-package dependencies are to be
> frowned upon, unless it is an absolute necessity. Also, external
> dependencies are to be kept to a minimum.
>
> Again, since I originally made a proposal for a Commons Filters project
> and just expanded on that in starting Java Web Parts, I would still have
> interest in working with Jakarta instead. There is definite benefit to
> doing that. But I would have to believe the vision for the project is
> in line, at least mostly, with what I had planned. But if finding
> people to do the work is what is needed to get such a project off the
> ground at Jakarta, I'm here, I'm willing and have in fact already begun
> the work in essence.
the new subproject would need a charter. development of the charter is
required before the subproject could start. the vision will be embedded
in the charter so it's subject to development by the community but
(personally speaking) i had in mind something very similar.
anyone else have any radically different ideas?
this leads to the question: what's the best way to develop the charter?
i've been contemplating using the wiki to store a working draft whilst
debating content on this list. opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in java
web applications
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 involved in those threads
discussing this idea... I could be persuaded to fold my work into this
subproject, but I would like to see that the consensus on direction is
similar to what I've done. Perhaps I should briefly describe my project...
It is what we are discussing here: a repository for small, generally
independent components of interest to general Java webapp developers.
It consists of a number of packages including Filters, Servlets,
Taglibs, Request (general request-related utilities), Response (general
response-related utilities and Session (I think you see the pattern!).
Right now I have 3 filters, 1 servlet and some miscellaneous code in the
other packages... There will likely be more after tonight in CVS.
In fact, the only packages with nothing at this point is the Response
and Taglib packages.
I have a list of over a dozen things I intend to build over the next few
weeks. Also included in all this is a single webapp that demonstrates
and tests all components. Some others have expressed interest in
contributing as well and I am awaiting their code to add.
Each of these packages gets JARed separately, so a developer can pick
and choose as they see fit. Cross-package dependencies are to be
frowned upon, unless it is an absolute necessity. Also, external
dependencies are to be kept to a minimum.
Again, since I originally made a proposal for a Commons Filters project
and just expanded on that in starting Java Web Parts, I would still have
interest in working with Jakarta instead. There is definite benefit to
doing that. But I would have to believe the vision for the project is
in line, at least mostly, with what I had planned. But if finding
people to do the work is what is needed to get such a project off the
ground at Jakarta, I'm here, I'm willing and have in fact already begun
the work in essence.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
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.
>
> In particular, I think that a browser recognition component would be an
> example of something that would fit well in this location.
>
> Perhaps named webparts?
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in
java web applications
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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 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.
good points
it's clear to me that there needs to be sufficient interest from
developers with free time for this subproject to be viable
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Posted by Rahul Akolkar <ra...@gmail.com>.
On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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 is a *bad* idea, especially to start.
>
> it was intentional in as much as it was a copy of the jakarta commons
> charter :)
>
> > 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)
>
> i agree. just dev and user lists.
>
> in jakarta commons, the common mailing lists hold together the single
> community. i'd like to see just one mailing list with components using
> prefixing (as per jakarta commons). i'd like to see changes to the draft
> so that it's clear that this will be the arrangement.
>
> opinions?
+1 (non-binding)
In conjunction to the points stated above, I see this as the key value
add to the Taglibs community (if Taglibs indeed decides to join in).
In my opinion, separate mailing lists will make this a harder sell to
Taglibs.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: mailing lists for components [WAS Re: [PROPOSAL] subproject that's
a home for bricks reusable in java web applications]
Posted by Felipe Leme <ja...@felipeal.net>.
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: mailing lists for components [WAS Re: [PROPOSAL] subproject
that's a home for bricks reusable in java web applications]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-07-02 at 14:33 -0400, Martin Cooper wrote:
> On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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 is a *bad* idea, especially to start.
> >
> > it was intentional in as much as it was a copy of the jakarta commons
> > charter :)
> >
> > > 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)
> >
> > i agree. just dev and user lists.
> >
> > in jakarta commons, the common mailing lists hold together the single
> > community. i'd like to see just one mailing list with components using
> > prefixing (as per jakarta commons). i'd like to see changes to the draft
> > so that it's clear that this will be the arrangement.
> >
> > opinions?
>
> +1 to just one dev and one user list, shared for all components, a la
> Jakarta Commons.
i think we've established a consensus on this. any objections to
amending the draft appropriately?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Posted by Martin Cooper <mf...@gmail.com>.
On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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 is a *bad* idea, especially to start.
>
> it was intentional in as much as it was a copy of the jakarta commons
> charter :)
>
> > 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)
>
> i agree. just dev and user lists.
>
> in jakarta commons, the common mailing lists hold together the single
> community. i'd like to see just one mailing list with components using
> prefixing (as per jakarta commons). i'd like to see changes to the draft
> so that it's clear that this will be the arrangement.
>
> opinions?
+1 to just one dev and one user list, shared for all components, a la
Jakarta Commons.
--
Martin Cooper
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
mailing lists for components [WAS Re: [PROPOSAL] subproject that's
a home for bricks reusable in java web applications]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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 as much as it was a copy of the jakarta commons
charter :)
> 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)
i agree. just dev and user lists.
in jakarta commons, the common mailing lists hold together the single
community. i'd like to see just one mailing list with components using
prefixing (as per jakarta commons). i'd like to see changes to the draft
so that it's clear that this will be the arrangement.
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: configuration files [WAS Re: [PROPOSAL] subproject that's a home
for bricks reusable in java web applications]
Posted by Phil Steitz <ph...@steitz.com>.
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 needed?
>>
>> if they are then i agree that they should encourage specification
>> compliance. would a general statement about specification compliance be
>> better?
>
>
> Its not needed. The charter should be as simple as possible.
+1 -- after thinking about it some more, I don't think it is wise to
limit things or to reference J2EE or other specs in the charter.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: configuration files [WAS Re: [PROPOSAL] subproject that's a home
for bricks reusable in java web applications]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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 agree that they should encourage specification
> compliance. would a general statement about specification compliance be
> better?
Its not needed. The charter should be as simple as possible.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
configuration files [WAS Re: [PROPOSAL] subproject that's a home
for bricks reusable in java web applications]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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 specification
compliance. would a general statement about specification compliance be
better?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a
home for bricks reusable in java web applications]
Posted by Phil Steitz <ph...@steitz.com>.
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 components (or at least the most commonly used ones), so
that you could just deploy one jar and get them all. As robert points
out below, internal and external dependencies and conflicts made that
impractical, so, despite this reference in the charter, we no longer
produce such a thing.
>
> 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 choose which parts
> they want to use.
+1
Phil
>
> I mention that because depending on what #12 really is talking about,
> that could conflict with that idea. I'm not sure.
>
> Frank
>
> robert burrell donkin 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.
>>
>> - robert
>>
>> --8<-----------------------------------------------------------
>> [ ] +1 Get rid!
>> [ ] -1 Keep it (please give a reason...)
>> --------------------------------------------------------------
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a
home for bricks reusable in java web applications]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 choose which parts
they want to use.
I mention that because depending on what #12 really is talking about,
that could conflict with that idea. I'm not sure.
Frank
robert burrell donkin 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.
>
> - robert
>
> --8<-----------------------------------------------------------
> [ ] +1 Get rid!
> [ ] -1 Keep it (please give a reason...)
> --------------------------------------------------------------
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a
home for bricks reusable in java web applications]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 choose which parts
they want to use.
I mention that because depending on what #12 really is talking about,
that could conflict with that idea. I'm not sure.
Frank
robert burrell donkin 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.
>
> - robert
>
> --8<-----------------------------------------------------------
> [ ] +1 Get rid!
> [ ] -1 Keep it (please give a reason...)
> --------------------------------------------------------------
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Posted by Rahul Akolkar <ra...@gmail.com>.
On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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.
>
> - robert
>
> --8<-----------------------------------------------------------
> [ ] +1 Get rid!
> [ ] -1 Keep it (please give a reason...)
> --------------------------------------------------------------
+1 (non-binding)
I think each "component" (i.e. bullet in the examples in the Preamble)
should be at the liberty to decide how they get packaged/distributed.
For example, servlets and filters (two components) may choose to have
one library, but one component, Taglibs (again, if it joins), may have
multiple jars (as it does today). I think removing 12 rightfully
delays these decisions :-)
On 6/23/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
<snip/>
> I mention that because depending on what #12 really is talking about,
> that could conflict with that idea. I'm not sure.
I think the implication of 12 conflicts your view.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [RESULT][POLL] drop point 12
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
+1
- robert
On Mon, 2005-07-04 at 02:16 -0400, Henri Yandell wrote:
> We should do the same on Commons at some point. Throw out the ones that
> seem dead.
>
> Hen
>
> On Sun, 3 Jul 2005, robert burrell donkin wrote:
>
> > i count 4 +1's
> >
> > the consensus seems to be in favour of removal so that's what i'm going
> > to do.
> >
> > i propose to leave retain the number by noting those that have been
> > deleted (rather than removing them).
> >
> > - robert
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [RESULT][POLL] drop point 12
Posted by Henri Yandell <ba...@generationjava.com>.
We should do the same on Commons at some point. Throw out the ones that
seem dead.
Hen
On Sun, 3 Jul 2005, robert burrell donkin wrote:
> i count 4 +1's
>
> the consensus seems to be in favour of removal so that's what i'm going
> to do.
>
> i propose to leave retain the number by noting those that have been
> deleted (rather than removing them).
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
[RESULT][POLL] drop point 12
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
i count 4 +1's
the consensus seems to be in favour of removal so that's what i'm going
to do.
i propose to leave retain the number by noting those that have been
deleted (rather than removing them).
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Posted by Martin Cooper <mf...@gmail.com>.
On 6/25/05, Stephen Colebourne <sc...@btopenworld.com> 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 subset of only JDK 1.1
> compatible releases. A gump of nightly builds will also be provided."
>
> >
> > --8<-----------------------------------------------------------
> > [X] +1 Get rid!
> > [ ] -1 Keep it (please give a reason...)
> > --------------------------------------------------------------
>
> One jar didn't work for commons, no reason to expect it will here.
+1. Let's ditch it.
--
Martin Cooper
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a
home for bricks reusable in java web applications]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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 builds will also be provided."
>
> --8<-----------------------------------------------------------
> [X] +1 Get rid!
> [ ] -1 Keep it (please give a reason...)
> --------------------------------------------------------------
One jar didn't work for commons, no reason to expect it will here.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
[POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home
for bricks reusable in java web applications]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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
--8<-----------------------------------------------------------
[ ] +1 Get rid!
[ ] -1 Keep it (please give a reason...)
--------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in
java web applications
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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 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 ;-)
the text is the jakarta commons charter :)
but it's just a starting point: hopefully it'll stimulate some
discussion and people can start to move to forward...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in
java web applications
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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 should be changed, though, IMHO.
i'm sure there are few more than that ;)
i've decided to chop phil's good reply up into bits so that items
requiring more discussion can get their own threads...
> First in the scope statement "intended for use in server-related
> development" could be narrowed to "web application development"
+1
> Uniformly change CVS to SVN (I assume! :)
+1
<snip>
> 4.2 should probably reference JSP/Servlet spec level requirements as
> well as JDK requirements
+1
>
> +1 to bullet under 7 :-)
++1
> Don't know what kind of goo 12 would result in or who would use such a
> thing ;-)
+1
i'm all for removing 12. this proved just too difficult to coordinate.
unless anyone feels the need to -1 any of these, someone should go ahead
and make these changes...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Posted by Martin Cooper <mf...@gmail.com>.
On 6/25/05, Stephen Colebourne <sc...@btopenworld.com> 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 otherwise, but maybe I'm just
> > used to seeing how commons and taglibs work. If Taglibs join, we have
> > a bunch of Taglibs in sandbox, they will need to be housed somewhere,
> > and I don't see them migrating to commons sandbox ;-) Right?
>
> Yes, +1 to a sandbox. Although it can create issues, I think has more
> benefits than downsides.
+1
--
Martin Cooper
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks
reusable in java web applications]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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 taglibs work. If Taglibs join, we have
> a bunch of Taglibs in sandbox, they will need to be housed somewhere,
> and I don't see them migrating to commons sandbox ;-) Right?
Yes, +1 to a sandbox. Although it can create issues, I think has more
benefits than downsides.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Posted by Rahul Akolkar <ra...@gmail.com>.
On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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 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 taglibs work. If Taglibs join, we have
a bunch of Taglibs in sandbox, they will need to be housed somewhere,
and I don't see them migrating to commons sandbox ;-) Right?
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Posted by Oliver Zeigermann <ol...@gmail.com>.
I would love to see a very light weight WebDAV servlet which could be
taken from Tomcat.
Oliver
On 6/24/05, Henri Yandell <ba...@generationjava.com> 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
> couple of classes (as you know :) ).
>
> Taglibs of course, I estimate half a dozen to ten taglibs.
>
> Commons FileUploa.
>
> Commons Http
> (http://svn.apache.org/repos/asf/jakarta/commons/sandbox/http/trunk/src/java/org/apache/commons/http/)
> which contains a browser detector class.
>
> Commons Filters.
>
> Hen
>
> On Thu, 23 Jun 2005, 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 not impossible).
> >
> > What is the general feeling in terms of where the code comprising this
> > package will come from? At least, the largest portion of it? Is the idea to
> > take parts of other Jakarta and/or Apache projects as the source material, or
> > is it to put more of an emphasis on outside contributions? The former sounds
> > much more like the current Jakarta Commons concept, the later is something
> > else.
> >
> > As someone who would like to contribute, I wouldn't want to see anything that
> > makes that more difficult embraced. Just curious what everyone else is
> > thinking...
> >
> > Frank
> >
> > robert burrell donkin 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 neophyte components start in the jakarta commons
> >> sandbox?
> >>
> >> - robert
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: general-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks
reusable in java web applications]
Posted by Henri Yandell <ba...@generationjava.com>.
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.org/repos/asf/jakarta/commons/sandbox/http/trunk/src/java/org/apache/commons/http/)
which contains a browser detector class.
Commons Filters.
Hen
On Thu, 23 Jun 2005, 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 not impossible).
>
> What is the general feeling in terms of where the code comprising this
> package will come from? At least, the largest portion of it? Is the idea to
> take parts of other Jakarta and/or Apache projects as the source material, or
> is it to put more of an emphasis on outside contributions? The former sounds
> much more like the current Jakarta Commons concept, the later is something
> else.
>
> As someone who would like to contribute, I wouldn't want to see anything that
> makes that more difficult embraced. Just curious what everyone else is
> thinking...
>
> Frank
>
> robert burrell donkin 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 neophyte components start in the jakarta commons
>> sandbox?
>>
>> - robert
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks
reusable in java web applications]
Posted by Phil Steitz <ph...@steitz.com>.
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 not
> impossible).
This should be discussed on commons-dev if people really think it is an
issue. Maintaining scope boundaries and quality is a key concern there
(as it should be in the proposed project as well, IMHO), but *many*
patches do get applied.
>
> What is the general feeling in terms of where the code comprising this
> package will come from? At least, the largest portion of it?
The majority of the code should be developed collaboratively by the
community, using the mailing list, Wiki, svn and issue tracker (Bugzilla
or Jira) to discuss ideas and manage patches. Any significant
contribution that is not developed within apache would have to go
through the incubator before being integrated.
<snip/>
>> is boils down to the question: does this subproject need it's own
>> sandbox or will neophyte components start in the jakarta commons
>> sandbox?
I would not recommend reusing the j-c sandbox and I am not sure that I
like the "start components in the sandbox" approach that we use there.
Too many abandoned components that people start to use (and depend on)
despite disclaimers. With the ease of branching in svn, I am not sure
if a sandbox is really needed any more. In any case, I would not
recommend repeating the j-c practice of "incubating" new subprojects in
the sandbox. Just my HO.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks
reusable in java web applications]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 the general feeling in terms of where the code comprising this
package will come from? At least, the largest portion of it? Is the
idea to take parts of other Jakarta and/or Apache projects as the source
material, or is it to put more of an emphasis on outside contributions?
The former sounds much more like the current Jakarta Commons concept,
the later is something else.
As someone who would like to contribute, I wouldn't want to see anything
that makes that more difficult embraced. Just curious what everyone
else is thinking...
Frank
robert burrell donkin 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 neophyte components start in the jakarta commons
> sandbox?
>
> - robert
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks
reusable in java web applications]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for
bricks reusable in java web applications]
Posted by Phil Steitz <ph...@steitz.com>.
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, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components [WAS Re: [PROPOSAL] subproject that's a home
for bricks reusable in java web applications]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-07-02 at 12:27 -0700, Phil Steitz wrote:
> Martin Cooper wrote:
> > On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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 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.
> >>
> >>this certainly doesn't reflect the current practise in the jakarta
> >>commons. though anyone can propose a new component, they really won't
> >>have any chance of winning a VOTE unless they have the support of
> >>existing committers.
> >>
> >>there is also the issue of the incubator: any new component bringing
> >>code from outside apache would need to be incubated.
> >
> >
> > We have a few different scenarios here, I believe.
> >
> > 1) A new component is proposed, with no existing code to back it up.
> > I'm not sure that this has ever happened in Jakarta Commons, or is
> > likely to happen in the new subproject, so frankly I don't much care
> > about how that would work. ;-)
> >
> > 2) A new component is proposed by an existing Apache committer. This
> > will almost certainly be backed up by code in the sandbox.
> > Historically, in Jakarta Commons, there hasn't so much been a
> > proposal, but rather a new project materialises in the sandbox. This
> > has, in part, been responsible for dregs that lie around forever. This
> > could be handled through the "after 6 months" vote that has been
> > mentioned in another thread.
> >
> > 3) A new component is proposed by a non-committer. Code to back up
> > such a proposal would necessarily be coming from somewhere else. This
> > is a situation in which the component should, I believe, come in
> > through the incubator. The incubation process would resolve the
> > questions of committers, etc., before the component lands in the new
> > subproject. (I want to emphasise here, for the folks that might be
> > concerned about this, that incubation need not be an onerous process,
> > and can happen rather quickly, if conditions are right.)
> >
> > I would suggest that we come up with wording in the charter to reflect
> > these scenarios, rather than trying to crib from the Jakarta Commons
> > charter in this instance.
>
> Agreed. After a little more discussion, we should rewrite this.
+1
anyone feel like jumping volunteering to come up with a draft?
> FWIW, I did NOT mean to suggest that only committers could *suggest* projects,
> only that to actually get one *started*, support from ideally more than
> one committer is required. I think the following is also possible,
> since at least one j-c component started this way:
>
> 4) A new component is proposed by a (some) non-committer(s). One or
> more existing committers are interested in working on the component.
> The initial code base is built up incrementally in the sandbox from
> patches contributed by community members. This is more or less the way
> we started commons-math. The initial code base was contributed
> incrementally, with patches discussed, reviewed and in some cases
> refactored before being committed. I don't see anything wrong with this,
> nor requiring a trip through the incubator.
+1
but i think that this can be covered as a subcase of the sandbox route.
the key factor is that the code is original.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for
bricks reusable in java web applications]
Posted by Phil Steitz <ph...@steitz.com>.
Martin Cooper wrote:
> On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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 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.
>>
>>this certainly doesn't reflect the current practise in the jakarta
>>commons. though anyone can propose a new component, they really won't
>>have any chance of winning a VOTE unless they have the support of
>>existing committers.
>>
>>there is also the issue of the incubator: any new component bringing
>>code from outside apache would need to be incubated.
>
>
> We have a few different scenarios here, I believe.
>
> 1) A new component is proposed, with no existing code to back it up.
> I'm not sure that this has ever happened in Jakarta Commons, or is
> likely to happen in the new subproject, so frankly I don't much care
> about how that would work. ;-)
>
> 2) A new component is proposed by an existing Apache committer. This
> will almost certainly be backed up by code in the sandbox.
> Historically, in Jakarta Commons, there hasn't so much been a
> proposal, but rather a new project materialises in the sandbox. This
> has, in part, been responsible for dregs that lie around forever. This
> could be handled through the "after 6 months" vote that has been
> mentioned in another thread.
>
> 3) A new component is proposed by a non-committer. Code to back up
> such a proposal would necessarily be coming from somewhere else. This
> is a situation in which the component should, I believe, come in
> through the incubator. The incubation process would resolve the
> questions of committers, etc., before the component lands in the new
> subproject. (I want to emphasise here, for the folks that might be
> concerned about this, that incubation need not be an onerous process,
> and can happen rather quickly, if conditions are right.)
>
> I would suggest that we come up with wording in the charter to reflect
> these scenarios, rather than trying to crib from the Jakarta Commons
> charter in this instance.
Agreed. After a little more discussion, we should rewrite this. FWIW, I
did NOT mean to suggest that only committers could *suggest* projects,
only that to actually get one *started*, support from ideally more than
one committer is required. I think the following is also possible,
since at least one j-c component started this way:
4) A new component is proposed by a (some) non-committer(s). One or
more existing committers are interested in working on the component.
The initial code base is built up incrementally in the sandbox from
patches contributed by community members. This is more or less the way
we started commons-math. The initial code base was contributed
incrementally, with patches discussed, reviewed and in some cases
refactored before being committed. I don't see anything wrong with this,
nor requiring a trip through the incubator.
Phil
>
>
>>is 19 needed in addition to 15?
>
>
> This seems to be a different topic entirely, but my vote would be yes,
> because 15 relates only to the proposal, while 19 relates to the
> component as it exists, and is developed, within the subproject.
+1 - different topic and one of the charming features of j-c that
should, IMHO, be carried over.
>
> --
> Martin Cooper
>
>
>
>>- robert
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by Steven Caswell <st...@gmail.com>.
+1
On 7/5/05, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> there doesn't see any enthusiasm for those new ideas and no objections
> to phil's draft. i think we should go ahead and make the changes
> suggested by phil.
>
> - robert
>
> On Sun, 2005-07-03 at 22:39 +0100, robert burrell donkin wrote:
> > On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote:
> > > Here is a stab at replacement text for 15, 17 and 18.
> >
> > great :)
> >
> > looks good but threw up some ideas...
> >
> > > 15-1 Any member of the community may propose a new package. To be
> > > accepted, a package proposal must receive majority approval of the
> > > subproject committers and at least one committer must volunteer to serve
> > > as an initial package team member. Proposals should identify the
> > > rationale for the package, its scope, its interaction with other
> > > packages and products, the <insert-subproject-name> resources, if any,
> > > to be created, the initial source from which the package is to be
> > > created, and the sponsoring committers.
> > >
> > > 15-2 The subproject will maintain an svn repository, referred to as the
> > > <i>sandbox</i>, as a workplace for new packages. Once approved, new
> > > packages must all begin in the sandbox. Any apache committer may
> > > contribute code directly to the sandbox and this code may form the
> > > initial source for new packages. Code from existing apache projects
> > > can, with the support of the contributing projects, also be imported
> > > directly into the sandbox. Finally, patches contributed incrementally
> > > by community members may be committed to the sandox by a subproject
> > > committer. If the initial source for a new package is from outside of
> > > apache, the new package must be brought into apache via the apache
> > > incubator.
> >
> > not sure but wonder whether we might need to tightening this last
> > sentence so that it can't be read as implying that having only a portion
> > of the initial source from external sources is ok. opinions?
> >
> > > 15-3 A majority vote among subproject commiters is required to
> > > "graduate" a package from the "sandbox" to become a proper package. Only
> > > proper packages may make releases. If a package remains in the sandbox
> > > for more than six months, a majority vote will be required to prevent
> > > its being archived from svn and removed from the subproject web site and
> > > any other public locations (e.g. nightly or continuous integration
> > > builds). Proper packages may not release code with dependencies on
> > > sandbox packages.
> >
> > 1. i wonder whether it'd be better to have bi-annual reviews to simplify
> > administration. in january, review all sandbox components which were
> > created before the previous july. could run them as a single vote.
> >
> > 2. i wonder whether we actually need to remove them from svn: just could
> > copy them into an archive directory.
> >
> > - robert
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Steven Caswell
steven.caswell@gmail.com
Take back the web - http://www.mozilla.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by Phil Steitz <ph...@steitz.com>.
robert burrell donkin wrote:
> there doesn't see any enthusiasm for those new ideas and no objections
> to phil's draft. i think we should go ahead and make the changes
> suggested by phil.
I went ahead and updated, making some small changes to (hopefully)
address the points above. I marked the items to be replaced as "DELETED"
and added the replacement items at the end. Given that the discussion
has referenced item numbers, I did not want to mess up the numbering.
We can reorder as appropriate when the music stops.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
there doesn't see any enthusiasm for those new ideas and no objections
to phil's draft. i think we should go ahead and make the changes
suggested by phil.
- robert
On Sun, 2005-07-03 at 22:39 +0100, robert burrell donkin wrote:
> On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote:
> > Here is a stab at replacement text for 15, 17 and 18.
>
> great :)
>
> looks good but threw up some ideas...
>
> > 15-1 Any member of the community may propose a new package. To be
> > accepted, a package proposal must receive majority approval of the
> > subproject committers and at least one committer must volunteer to serve
> > as an initial package team member. Proposals should identify the
> > rationale for the package, its scope, its interaction with other
> > packages and products, the <insert-subproject-name> resources, if any,
> > to be created, the initial source from which the package is to be
> > created, and the sponsoring committers.
> >
> > 15-2 The subproject will maintain an svn repository, referred to as the
> > <i>sandbox</i>, as a workplace for new packages. Once approved, new
> > packages must all begin in the sandbox. Any apache committer may
> > contribute code directly to the sandbox and this code may form the
> > initial source for new packages. Code from existing apache projects
> > can, with the support of the contributing projects, also be imported
> > directly into the sandbox. Finally, patches contributed incrementally
> > by community members may be committed to the sandox by a subproject
> > committer. If the initial source for a new package is from outside of
> > apache, the new package must be brought into apache via the apache
> > incubator.
>
> not sure but wonder whether we might need to tightening this last
> sentence so that it can't be read as implying that having only a portion
> of the initial source from external sources is ok. opinions?
>
> > 15-3 A majority vote among subproject commiters is required to
> > "graduate" a package from the "sandbox" to become a proper package. Only
> > proper packages may make releases. If a package remains in the sandbox
> > for more than six months, a majority vote will be required to prevent
> > its being archived from svn and removed from the subproject web site and
> > any other public locations (e.g. nightly or continuous integration
> > builds). Proper packages may not release code with dependencies on
> > sandbox packages.
>
> 1. i wonder whether it'd be better to have bi-annual reviews to simplify
> administration. in january, review all sandbox components which were
> created before the previous july. could run them as a single vote.
>
> 2. i wonder whether we actually need to remove them from svn: just could
> copy them into an archive directory.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote:
> Here is a stab at replacement text for 15, 17 and 18.
great :)
looks good but threw up some ideas...
> 15-1 Any member of the community may propose a new package. To be
> accepted, a package proposal must receive majority approval of the
> subproject committers and at least one committer must volunteer to serve
> as an initial package team member. Proposals should identify the
> rationale for the package, its scope, its interaction with other
> packages and products, the <insert-subproject-name> resources, if any,
> to be created, the initial source from which the package is to be
> created, and the sponsoring committers.
>
> 15-2 The subproject will maintain an svn repository, referred to as the
> <i>sandbox</i>, as a workplace for new packages. Once approved, new
> packages must all begin in the sandbox. Any apache committer may
> contribute code directly to the sandbox and this code may form the
> initial source for new packages. Code from existing apache projects
> can, with the support of the contributing projects, also be imported
> directly into the sandbox. Finally, patches contributed incrementally
> by community members may be committed to the sandox by a subproject
> committer. If the initial source for a new package is from outside of
> apache, the new package must be brought into apache via the apache
> incubator.
not sure but wonder whether we might need to tightening this last
sentence so that it can't be read as implying that having only a portion
of the initial source from external sources is ok. opinions?
> 15-3 A majority vote among subproject commiters is required to
> "graduate" a package from the "sandbox" to become a proper package. Only
> proper packages may make releases. If a package remains in the sandbox
> for more than six months, a majority vote will be required to prevent
> its being archived from svn and removed from the subproject web site and
> any other public locations (e.g. nightly or continuous integration
> builds). Proper packages may not release code with dependencies on
> sandbox packages.
1. i wonder whether it'd be better to have bi-annual reviews to simplify
administration. in january, review all sandbox components which were
created before the previous july. could run them as a single vote.
2. i wonder whether we actually need to remove them from svn: just could
copy them into an archive directory.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by Phil Steitz <ph...@steitz.com>.
Here is a stab at replacement text for 15, 17 and 18.
15-1 Any member of the community may propose a new package. To be
accepted, a package proposal must receive majority approval of the
subproject committers and at least one committer must volunteer to serve
as an initial package team member. Proposals should identify the
rationale for the package, its scope, its interaction with other
packages and products, the <insert-subproject-name> resources, if any,
to be created, the initial source from which the package is to be
created, and the sponsoring committers.
15-2 The subproject will maintain an svn repository, referred to as the
<i>sandbox</i>, as a workplace for new packages. Once approved, new
packages must all begin in the sandbox. Any apache committer may
contribute code directly to the sandbox and this code may form the
initial source for new packages. Code from existing apache projects
can, with the support of the contributing projects, also be imported
directly into the sandbox. Finally, patches contributed incrementally
by community members may be committed to the sandox by a subproject
committer. If the initial source for a new package is from outside of
apache, the new package must be brought into apache via the apache
incubator.
15-3 A majority vote among subproject commiters is required to
"graduate" a package from the "sandbox" to become a proper package. Only
proper packages may make releases. If a package remains in the sandbox
for more than six months, a majority vote will be required to prevent
its being archived from svn and removed from the subproject web site and
any other public locations (e.g. nightly or continuous integration
builds). Proper packages may not release code with dependencies on
sandbox packages.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-07-02 at 14:52 -0400, Martin Cooper wrote:
> On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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 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.
> >
> > this certainly doesn't reflect the current practise in the jakarta
> > commons. though anyone can propose a new component, they really won't
> > have any chance of winning a VOTE unless they have the support of
> > existing committers.
> >
> > there is also the issue of the incubator: any new component bringing
> > code from outside apache would need to be incubated.
>
> We have a few different scenarios here, I believe.
>
> 1) A new component is proposed, with no existing code to back it up.
> I'm not sure that this has ever happened in Jakarta Commons, or is
> likely to happen in the new subproject, so frankly I don't much care
> about how that would work. ;-)
yep. vaporware can take care of itself :)
> 2) A new component is proposed by an existing Apache committer. This
> will almost certainly be backed up by code in the sandbox.
> Historically, in Jakarta Commons, there hasn't so much been a
> proposal, but rather a new project materialises in the sandbox. This
> has, in part, been responsible for dregs that lie around forever. This
> could be handled through the "after 6 months" vote that has been
> mentioned in another thread.
then at some time later, a promotion vote is held.
> 3) A new component is proposed by a non-committer. Code to back up
> such a proposal would necessarily be coming from somewhere else. This
> is a situation in which the component should, I believe, come in
> through the incubator. The incubation process would resolve the
> questions of committers, etc., before the component lands in the new
> subproject. (I want to emphasise here, for the folks that might be
> concerned about this, that incubation need not be an onerous process,
> and can happen rather quickly, if conditions are right.)
+1
> I would suggest that we come up with wording in the charter to reflect
> these scenarios, rather than trying to crib from the Jakarta Commons
> charter in this instance.
+1
maybe the whole sandbox issue should have it's own subsection detailing
how the sandbox is to work and how promotion should work.
> > is 19 needed in addition to 15?
>
> This seems to be a different topic entirely, but my vote would be yes,
> because 15 relates only to the proposal, while 19 relates to the
> component as it exists, and is developed, within the subproject.
sorry: meant 17
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Posted by Martin Cooper <mf...@gmail.com>.
On 6/23/05, robert burrell donkin <ro...@blueyonder.co.uk> 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 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.
>
> this certainly doesn't reflect the current practise in the jakarta
> commons. though anyone can propose a new component, they really won't
> have any chance of winning a VOTE unless they have the support of
> existing committers.
>
> there is also the issue of the incubator: any new component bringing
> code from outside apache would need to be incubated.
We have a few different scenarios here, I believe.
1) A new component is proposed, with no existing code to back it up.
I'm not sure that this has ever happened in Jakarta Commons, or is
likely to happen in the new subproject, so frankly I don't much care
about how that would work. ;-)
2) A new component is proposed by an existing Apache committer. This
will almost certainly be backed up by code in the sandbox.
Historically, in Jakarta Commons, there hasn't so much been a
proposal, but rather a new project materialises in the sandbox. This
has, in part, been responsible for dregs that lie around forever. This
could be handled through the "after 6 months" vote that has been
mentioned in another thread.
3) A new component is proposed by a non-committer. Code to back up
such a proposal would necessarily be coming from somewhere else. This
is a situation in which the component should, I believe, come in
through the incubator. The incubation process would resolve the
questions of committers, etc., before the component lands in the new
subproject. (I want to emphasise here, for the folks that might be
concerned about this, that incubation need not be an onerous process,
and can happen rather quickly, if conditions are right.)
I would suggest that we come up with wording in the charter to reflect
these scenarios, rather than trying to crib from the Jakarta Commons
charter in this instance.
> is 19 needed in addition to 15?
This seems to be a different topic entirely, but my vote would be yes,
because 15 relates only to the proposal, while 19 relates to the
component as it exists, and is developed, within the subproject.
--
Martin Cooper
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
new components [WAS Re: [PROPOSAL] subproject that's a home for
bricks reusable in java web applications]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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 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.
this certainly doesn't reflect the current practise in the jakarta
commons. though anyone can propose a new component, they really won't
have any chance of winning a VOTE unless they have the support of
existing committers.
there is also the issue of the incubator: any new component bringing
code from outside apache would need to be incubated.
is 19 needed in addition to 15?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in java
web applications
Posted by Phil Steitz <ph...@steitz.com>.
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in java
web applications
Posted by Henri Yandell <ba...@generationjava.com>.
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 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.
>
> In particular, I think that a browser recognition component would be an
> example of something that would fit well in this location.
Lance Lavandowska had a browser component which a long time back was
mooted for Commons I think. He's becoming a part of the ASF via
Roller@Incubator, so might be worth contacting.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] subproject that's a home for bricks reusable in java
web applications
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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.
In particular, I think that a browser recognition component would be an
example of something that would fit well in this location.
Perhaps named webparts?
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org