Re: mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Martin Cooper wrote: +1 to just one dev and one user list, shared for all components, a la Jakarta Commons. Me too... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On Sat, 2005-07-02 at 14:33 -0400, Martin Cooper wrote: On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: 4.1 in the guidelines repeats the error that I thought was fixed in the j-c guidelines saying that each package has 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On Sat, 2005-07-02 at 12:27 -0700, Phil Steitz wrote: Martin Cooper wrote: On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip Interpreted literally, 17 goes against standard practice in jakarta (or apache, to my 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/25/05, Stephen Colebourne [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: is boils down to the question: does this subproject need it's own sandbox or will neophyte components start in the jakarta commons sandbox? +1 for sandbox (non-binding) Its slightly hard to imagine anything 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/25/05, Stephen Colebourne [EMAIL PROTECTED] wrote: robert burrell donkin wrote: this has proved impractical in the jakarta commons. i propose we drop point 12. 12. The subproject will also provide a single JAR of all stable package releases. It may also provide a second JAR with a 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: 4.1 in the guidelines repeats the error that I thought was fixed in the j-c guidelines saying that each package has its own mailing list. If that is intentional, I think that 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip Interpreted literally, 17 goes against standard practice in jakarta (or apache, to my knowledge, other than in the incubator). I would recommend that new packages 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Martin Cooper wrote: On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip Interpreted literally, 17 goes against standard practice in jakarta (or apache, to my knowledge, other than in the incubator). I would recommend that 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration files [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration files [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
I would love to see a very light weight WebDAV servlet which could be taken from Tomcat. Oliver On 6/24/05, Henri Yandell [EMAIL PROTECTED] wrote: Just looking within Jakarta, the following all jump out as initial code: http://svn.apache.org/repos/asf/jakarta/commons/sandbox/servlet/ has a 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
configuration files [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: 4.1 in the guidelines repeats the error that I thought was fixed in the j-c guidelines saying that each package has its own mailing list. If that is intentional, I think that 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip Don't know what kind of goo 12 would result in or who would use such a thing ;-) this has proved impractical in the jakarta commons. i propose we drop point 12. - 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: snip I guess 18 refers to the sandbox? I do not understand what the intent of this is. is boils down to the question: does this subproject need it's own sandbox or will 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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 [EMAIL PROTECTED], so might be worth contacting. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
Stephen Colebourne wrote: robert burrell donkin wrote: there have been a number of long running threads in the commons discussing the possibility of commons components for use in web applications. the consensus emerged that it would be best if a new subproject with a structure similar to the commons was created for components intended for use in web applications. opinions, please! I am in favour of this, although whether I would be able to spare much time is debatable. I am also in favor, also not likely to have much time to contribute. Here are some comments on the draft charter. It is nice to see so much borrowed from the (at least I think) successful j-c model ;-) A couple of things should be changed, though, IMHO. First in the scope statement intended for use in server-related development could be narrowed to web application development Uniformly change CVS to SVN (I assume! :) 4.1 in the guidelines repeats the error that I thought was fixed in the j-c guidelines saying that each package has its own mailing list. If that is intentional, I think that is a *bad* idea, especially to start. 4.2 should probably reference JSP/Servlet spec level requirements as well as JDK requirements +1 to bullet under 7 :-) 9 or somewhere else should speak to J2EE or other external config requirments, which should be fine, even encouraged in some cases Don't like the many little lists implied by 11 -- dev + user works fine in j-c (I know some disagree, but I personally view this as the key to the health of j-c) Don't know what kind of goo 12 would result in or who would use such a thing ;-) Interpreted literally, 17 goes against standard practice in jakarta (or apache, to my knowledge, other than in the incubator). I would recommend that new packages require existing committers to support them. I would at least recommend changing Anyone to Any apache committer. If an individual has already contributed enough to be voted in as a committer, then that should be done in a separate VOTE. I guess 18 refers to the sandbox? I do not understand what the intent of this is. One final thing to think about. I know lots of apache people are opposed to umbrella projects for lots of reasons, one of which is the fragmentation and abandonment that can result. We have certainly not been immune to that in j-c. Two things that have been critical to keeping us going have been 1) a relatively small (changing over time) set of key contributors who look after multiple components and 2) some large internal customers (tomcat, struts, maven et al) whose committers jump in to push things along as needed. This project would be starting without the large internal customers. It would probably be a good idea, therefore, to start with a narrower, rather than broader scope, so that the fledgling community would not get fragmented too quickly and the key contributors could emerge. Just a thought. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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 signature.asc Description: This is a digitally signed message part
