RE: [ANNOUNCEMENT] Proposal For Jakarta Sub Project For WebApplic ation Components
If someone is interested in this project, what should they do? -Shawn -Original Message- From: Daniel L. Rall [mailto:[EMAIL PROTECTED] Sent: Thursday, June 23, 2005 12:40 AM To: Jakarta General List Subject: Re: [ANNOUNCEMENT] Proposal For Jakarta Sub Project For WebApplication Components On Wed, 2005-06-22 at 16:11 -0700, Martin Cooper wrote: On Wed, 22 Jun 2005, robert burrell donkin wrote: i considered posting this to one or more of the announcement lists in an attempt to widen the audience but i didn't feel confident that it would be appropriate or wise. opinions? IMO, it doesn't need to go to announcements lists at this point. People who are only on those lists are likely interested only in things that have become real. When (if) the subproject is created, it might be more appropriate, but I don't feel a proposal is right for [EMAIL PROTECTED] I did, however, forward the message to taglibs-dev and taglibs-user, since they may end up with a vested interest in this. I sent it over to Web Services as well. - 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: [Jakarta Wiki] Update of CreatingCommonsForWebComponents by FelipeLeme
On Thu, 2005-06-23 at 00:38 -0300, Felipe Leme wrote: I also fixed the alphabetic order of the existing proposals (but accidently typed enter before adding that comment). thanks - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANNOUNCEMENT] Proposal For Jakarta Sub Project For WebApplication Components
On Thu, 2005-06-23 at 09:45 -0400, Bernard, Shawn wrote: If someone is interested in this project, what should they do? you've already taken the first step: signing up to this list and joining in :) at the moment, this is just a proposal. for this to get any further, there are some tangible things that need to happen such as choosing a name and creating a charter. there are also intangible things like bootstrapping a community. the jakarta committers will need a name and a charter as well as a community to be convinced of the viability. right now, we need community support in developing (in more concrete terms) exactly what this new subproject should be and how it should be organised. the final charter should be an expression of these ideas. take a look at the documents on the wiki and post improvements and criticisms (at the moment, they are just a starting point: copies of the current jakarta commons charter). (sign up and) add new linked documents containing anything you think might help (ideas for components, perhaps or best practices). think of names or come up with reasons why a particular name should be picked (or not picked). the wiki should provide bootstrap documentation for the subproject. join in the discussions. in other words: get involved in the best way you see fit. - 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 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: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote: Apache Wiki wrote: Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments or post to [http://jakarta.apache.org/site/mail.html General At Jakarta]. OK, here I am posting :-) I'd like to suggest 2 things: 1.We prefereably use Maven for the builds, as it helps a lot handling the dependencies (if we stick to Ant, we should at least use Ivy or M2 Ant stuff for dependency management). For instance, I haven't applied some patches to the Jakarta Taglibs because my computers are not set for building them anymore (and I don't have the time/patience to fix it). jakarta commons is agnostic (but uses maven for the website). i'd recommend official agnosticism with unofficial encouragement to maven. it is a good idea to provide ant scripts generated by maven in SVN. 2.Regarding the Jakarta Taglibs, we should create the new taglibs from scratch. I mean, of course we should reuse the code, but we better do some refactoring first (for instance, eliminating redundant taglibs, defining a role for TLD names, etc...) - the current Jakarta Taglibs would then be frozen in time. IMHO it would probably be more convenient to maintain these frozen taglibs (from an official perspective) within the new subproject. with subversion, it's really nice and easy to have cool directory structures... 3.What about the Standard Taglibs? Should it be part of this new project or should it be a separate project. The reasoning here is that, because that sub-project provide the codebase for JSTL's implementation (and maybe other JSR taglibs in the future as well, such as the Web Services taglib), its development activities/cycles might be different from the non-standard ones (we could even try to apply the TCK on such projects in the future, for instance). if the new subproject is anything like the commons then each component will have it's own development rhythm. it might be easier to raise extra hands when needed for these efforts if these share the same infrastructure (mailing lists, subproject organization and so on). opinions? - 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: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 2005-06-23 at 00:52 -0300, Felipe Leme wrote: Felipe Leme wrote: I'd like to suggest 2 things: ... 3 Damn, beaten by the ENTER key again :-( shades of monty python's flying circus ;) - robert - 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: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
robert burrell donkin wrote: if the new subproject is anything like the commons then each component will have it's own development rhythm. I think this is a cogent point... if the idea is that this is like a Commons project, than I have to ask the question: why not just have a few new Commons projects, as was my original proposal? I originally started by suggesting a Commons Filters, because I had some filters I wanted to contribute. So far I think we've brainstormed something like 4-6 sort of sub-packages of this... If they are going to develop to their own rhythm as you say, then why not make each a Commons project, where there already largely is the infrastructure (in the larger sense) build up? That would seem to me the path of least (or at least lower) resistance, and maybe even a more appropriate fit. It's a question of what the vision is of course... if everyone is thinking along the commons lines anyway, why not just do it in Commons? Frank - 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: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 2005-06-23 at 17:55 -0400, Frank W. Zammetti wrote: robert burrell donkin wrote: if the new subproject is anything like the commons then each component will have it's own development rhythm. I think this is a cogent point... if the idea is that this is like a Commons project, than I have to ask the question: why not just have a few new Commons projects, as was my original proposal? The relevant questions are: * what percentage of the existing commons developers are interested in working on web components * what percentage of the prospective web developers are interested in participating in other commons projects * what percentage of users and interested in both web and normal commons projects. If the answer to any of these is high then the benefits of a combined community outweigh the nuisance of excessive emails, overly-large subproject lists and general distraction. I would guess the critical threshold to be about 25% - but I don't think that will be reached, ie I believe that less than 25% of existing commons committers would be interested in web commons components of the sort proposed. Therefore having such components in the existing commons will just annoy people without having any significant benefits (other than allowing this startup hassle for web commons to be skipped). Already we have people (both developers and users) agitating for separate per-component mail lists due to the volume of emails in commons. Some people have stated that they refuse to subscribe or be part of the community while there is a shared list. I would hate to see separate lists, but they have a point - there is an upper limit to the amount of mail people can handle (esp. people on dial-up connections; filtering by mail subject doesn't reduce the bandwidth needed to download all the mails). There is also the issue of community size. Commons has a couple of dozen regular committers, which means we all recognise each other's names. That's quite important I think, and brings some sense of team membership. Diluting this with another dozen developers (I hope web commons will grow to that size!) may change that sense of community (esp. if we don't have many interests in common). And likewise for new web commons committers - I think the sense of a team will be stronger with a separate project/mail-list etc. I admit it's all guesswork and a little crystal-ball-gazing. If web-commons is a failure, ie only a couple of projects get off the ground, then the existing commons would be a better home. But I hope that's not the case - there does seem to be a reasonable number of ideas and people willing to push them forward. Regards, Simon - 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]
[Jakarta Wiki] Trivial Update of SubProjectProposals by RahulAkolkar
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta/SubProjectProposals The comment on the change is: Corrected typo -- This is a space for development of new sub project proposals. It's really intended for the collaborative development of proposals that enjoy the support (in principle) of Jakarta committers. If you're not a Jakarta committer and would like to start a new project please subscribe to [http://jakarta.apache.org/site/mail.html General At Jakarta] and post there for comments before changing this page. Please research the subject carefully: very few proposals for new subprojects are accepted by Jakarta. - Anyone with an interest is encouraged to contribute by editing the wiki (you'll need to sign up first) and by posting comments to [http://jakarta.apache.org/site/mail.html General At Jakarta]. Discuss is encouraged on the mailing list and on request for comment pages. Please think before changing the draft pages (you may be reverted ;). + Anyone with an interest is encouraged to contribute by editing the wiki (you'll need to sign up first) and by posting comments to [http://jakarta.apache.org/site/mail.html General At Jakarta]. Discussions are encouraged on the mailing list and on request for comment pages. Please think before changing the draft pages (you may be reverted ;). * CreatingCommonsForWebComponents - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 23 Jun 2005, robert burrell donkin wrote: On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote: Apache Wiki wrote: Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments or post to [http://jakarta.apache.org/site/mail.html General At Jakarta]. OK, here I am posting :-) 3.What about the Standard Taglibs? Should it be part of this new project or should it be a separate project. The reasoning here is that, because that sub-project provide the codebase for JSTL's implementation (and maybe other JSR taglibs in the future as well, such as the Web Services taglib), its development activities/cycles might be different from the non-standard ones (we could even try to apply the TCK on such projects in the future, for instance). if the new subproject is anything like the commons then each component will have it's own development rhythm. it might be easier to raise extra hands when needed for these efforts if these share the same infrastructure (mailing lists, subproject organization and so on). opinions? My vote is for the active Taglibs to roll into the web component subproject, but for the Standard/JSTL taglib to move to Jakarta subproject status. Taglibs-user is dominated by JSTL questions and the JSTL committers don't have any obvious overlap with the other taglib committers (that I've noticed). Also in terms of codebase, Standard is the relative behemoth. Lastly it has a much higher profile than other parts of web-component-subproject will have and as a spec implementation it has a different set of issues to deal with. Hen - 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]
[svn] Alexandria: migrate or archive?
I can't remember, are we going to migrate Alexandria over to SVN, or treat it like jakarta-site, jakarta-site-old and other obviously dead modules. If we want to migrate it, does anyone mind me just going ahead and doing so? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [svn] Alexandria: migrate or archive?
On Fri, 2005-06-24 at 01:35 -0400, Henri Yandell wrote: I can't remember, are we going to migrate Alexandria over to SVN, or treat it like jakarta-site, jakarta-site-old and other obviously dead modules. If we want to migrate it, does anyone mind me just going ahead and doing so? I'm in favour of migrating it. There may well be stuff that people want to go back and look into over the next few years. That will be difficult when Apache no longer provides CVS access The site stuff is different; there's no obvious reason for looking at the history of any of that, or retrieving any old versions. Please go ahead. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
