Re: Apache CVS (was Re: Lessons Learned)
please post this question to the right list (http://jakarta.apache.org/site/mail.html). FWIW i have used JMeter for web testing though (depending on your needs) cactus (http://jakarta.apache.org/cactus) may be more suitable. - robert On 14 Dec 2004, at 22:58, Jim Amini wrote: Hi, Has anyone used Jmeter for web testing? Please respond if you have used this tool or you know how to use it. Thanks, Jim. -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 2:57 PM To: Jakarta General List Subject: Re: Apache CVS (was Re: Lessons Learned) On 13 Dec 2004, at 22:20, Richard Bair wrote: Thanks everyone for your insight! Related to this, I have a question regarding the organizational structure of CVS. I noticed that cvs.apache.org has, predictably, a different package for all of the top-level projects, and even sub-projects (although all of the commons-components are considered components and not sub-projects, hence the lack of any of the components at this top level). I also noticed that each of the websites is listed as [projectname]-site. I'm certainly not the worlds foremost expert at CVS, so I naturally assume that since apache is laid out this way that this must a great way to lay out a project its sub-projects in CVS. Is this so? What are the pros/cons to doing it this way, as opposed to a true tree structure? I assume it has something to do with the way CVS does things. (though it is the conventional way to lay out CVS projects) i suspect that this organization grew rather than being planned. (though it may well be easier to manage permissions with this structure.) we're moving to subversion and there have been quite a few discussions about the best ways of laying our repositories recently. if you can use subversion, seriously consider using it. the way our subversion repository is laid out is a little different. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache CVS (was Re: Lessons Learned)
we're moving to subversion and there have been quite a few discussions about the best ways of laying our repositories recently. if you can use subversion, seriously consider using it. the way our subversion repository is laid out is a little different. - robert Hmm... I have been thinking about subversion. Collabnet is doing our hosting, so moving to subversion instead of cvs *shouldn't* be a big deal from a technical standpoint. I don't know how well supported subversion is via IDE's and the like. I assume there is a good web client for subversion as well? How is apache changing its layout for subversion? I'll check the archives for this list and see what is mentioned, are there any other good resources for seeing how Jakarta is going to use subversion? Thanks Richard __ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new sandbox projects
On Wed, 15 Dec 2004, Torsten Curdt wrote: Hey, folks! Hey Torsten, Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... Any Apache committer can have sandbox karma just for the asking. I factored out our javaflow (java continuations) implementation and a java compiler interface (jci) featuring a compiling classloader. Any opinions on hosting that at jakarta commons? Or should we keep that stuff under our umbrella? These sound good to me. I would be +1 for having these in the Commons sandbox. -- Martin Cooper cheers -- Torsten - 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: Apache CVS (was Re: Lessons Learned)
Richard, The IDE most people seem to talk about most (Eclipse) has a plugin called Subclipse (search for it on Tigris). It works, but it isn't as well supported as CVS. For example, the synchronize perspective doesn't work yet. But, tool support is a which comes first? problem, as more projects move towards Subversion, more widely used IDEs will support it out-of-the-box (but, who gets software in a box these days?). As far as Jakarta's eventual move to Subversion, you can see the start here: http://svn.apache.org/repos/asf/jakarta/ I believe the plan is to have a directory per subproject. Below that, structure will depend on what an individual subproject needs. But, there are some tricky questions to answer especially in subprojects with multiple artifacts. Take jakarta commons as an example. We still haven't decided where our trunk, tags, and branches will go. Tim -Original Message- From: Richard Bair [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 5:37 PM To: Jakarta General List Subject: Re: Apache CVS (was Re: Lessons Learned) we're moving to subversion and there have been quite a few discussions about the best ways of laying our repositories recently. if you can use subversion, seriously consider using it. the way our subversion repository is laid out is a little different. - robert Hmm... I have been thinking about subversion. Collabnet is doing our hosting, so moving to subversion instead of cvs *shouldn't* be a big deal from a technical standpoint. I don't know how well supported subversion is via IDE's and the like. I assume there is a good web client for subversion as well? How is apache changing its layout for subversion? I'll check the archives for this list and see what is mentioned, are there any other good resources for seeing how Jakarta is going to use subversion? Thanks Richard __ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.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: Lessons Learned
On 13 Dec 2004, at 01:04, Felipe Leme wrote: On Sun, 2004-12-12 at 21:15, robert burrell donkin wrote: though committing a few risky patches in the hope of recruiting a new committer might seem like a good plan, there are definite drawbacks. I agree. I didn't mean that all patches, but they should at least be 'acknowledged'. Even a comment like 'this patch seems great, but I do not have time to carefully analyze it right now' would be better than simply ignoring it. i'd agree with this. though i find it is often very difficult to achieve :( flamewars are rarer in bugzilla and it can save time in the long run (like next release time) to give a good reason why a patch won't be applied (especially when it's a design reason). a request for additional work from the patcher is also worth noting (if this is what's stopping the patch being applied). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache CVS (was Re: Lessons Learned)
On 13 Dec 2004, at 22:20, Richard Bair wrote: Thanks everyone for your insight! Related to this, I have a question regarding the organizational structure of CVS. I noticed that cvs.apache.org has, predictably, a different package for all of the top-level projects, and even sub-projects (although all of the commons-components are considered components and not sub-projects, hence the lack of any of the components at this top level). I also noticed that each of the websites is listed as [projectname]-site. I'm certainly not the worlds foremost expert at CVS, so I naturally assume that since apache is laid out this way that this must a great way to lay out a project its sub-projects in CVS. Is this so? What are the pros/cons to doing it this way, as opposed to a true tree structure? I assume it has something to do with the way CVS does things. (though it is the conventional way to lay out CVS projects) i suspect that this organization grew rather than being planned. (though it may well be easier to manage permissions with this structure.) we're moving to subversion and there have been quite a few discussions about the best ways of laying our repositories recently. if you can use subversion, seriously consider using it. the way our subversion repository is laid out is a little different. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache CVS (was Re: Lessons Learned)
Hi, Has anyone used Jmeter for web testing? Please respond if you have used this tool or you know how to use it. Thanks, Jim. -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 2:57 PM To: Jakarta General List Subject: Re: Apache CVS (was Re: Lessons Learned) On 13 Dec 2004, at 22:20, Richard Bair wrote: Thanks everyone for your insight! Related to this, I have a question regarding the organizational structure of CVS. I noticed that cvs.apache.org has, predictably, a different package for all of the top-level projects, and even sub-projects (although all of the commons-components are considered components and not sub-projects, hence the lack of any of the components at this top level). I also noticed that each of the websites is listed as [projectname]-site. I'm certainly not the worlds foremost expert at CVS, so I naturally assume that since apache is laid out this way that this must a great way to lay out a project its sub-projects in CVS. Is this so? What are the pros/cons to doing it this way, as opposed to a true tree structure? I assume it has something to do with the way CVS does things. (though it is the conventional way to lay out CVS projects) i suspect that this organization grew rather than being planned. (though it may well be easier to manage permissions with this structure.) we're moving to subversion and there have been quite a few discussions about the best ways of laying our repositories recently. if you can use subversion, seriously consider using it. the way our subversion repository is laid out is a little different. - 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]
new sandbox projects
Hey, folks! Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... I factored out our javaflow (java continuations) implementation and a java compiler interface (jci) featuring a compiling classloader. Any opinions on hosting that at jakarta commons? Or should we keep that stuff under our umbrella? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new sandbox projects
On Tue, 14 Dec 2004, Martin Cooper wrote: On Wed, 15 Dec 2004, Torsten Curdt wrote: Over at cocoon we have some code that might be worth sharing on jakarta commons. So I was wondering if the sandbox is open to any committer or only to jakarta committers? (which I am not) I heard different stories... Any Apache committer can have sandbox karma just for the asking. The only complication is that the committer will need to get the jakarta unix group, so it'll take us a little bit longer to add karma. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
