Re: Test Infrastructure Project Proposal
Why not use J2EEUnit for serverside testing ? It is built on top of JUnit. It also is hosted SourceForge. HttpUnit is only appropiate for client side testing. The frameworks are geared for different audiences. In this case J2EE would probably be more appropiate. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta-tools ? Re: Code Sharing Concepts
I'll try again: 1. As someone said, "community is more important than code" 2. I think the real problem here is not "code sharing" - the fact that people are reticent to reuse code developed in other projects is just an effect 3. I think the real problem is that each project has it's own community and commiters, instead of a shared "jakarta community". 4. I think the only way to solve the reuse problem is to make sure that all jakarta commiters are part of the "tools/utils" project. That's my point - I'm not proposing to create ( now ) a repository open to everyone in the world, just to all interested jakarta commiters. Beeing a commiter in one of the projects means more than the fact that you have CVS access and the right to vote - it means you feel part of the project community. If you are commiter in one of the jakarta projects and you are interested in working on any "shared" code, you should automatically be a commiter for the shared piece. My proposal is to create a place where all jakarta commiters have a common interest - the shared tools. If we can't manage this - that means something is broken in the concept of "jakarta community" - and a different solution is needed. But it's worth trying ( starting with few small tools ), and see if we can manage to work togheter. We can have 10 different Pools or StringManagers - in time they'll converge or specialize and cover different niche. There is nothing wrong with having 4 solutions for a test suite, as long as all people working on this are sharing a common repository and community, and the community is open to new code ( even if it's duplicated ) as long as the code is shared. I think all "tools" should be shared - but the code is less important in this case, we should share the community ( by making all jakarta commiters members of the tools project ). Costin [EMAIL PROTECTED] wrote: Again, I don't like the idea of "framework" - i.e. a team managing all tools and releasing them as a whole. It seems what works is the idea of modules ( like CPAN modules ). And the modules should have independent life and evolution. We can tag individual packages for each project that includes it. I don't think anyone has meant to propose that. I have suggested that we create a Jakarta Components Library as a microcosm of the greater project. There would be a core group of Committers (like the PMC) who would act as the overall gatekeepers of the library. Each component in the library would have its own set of Committers, which would usually be the person or persons who wrote the original code, and who has a vested interest in the component. Each component would have its own release schedule and versioning, stable versions and latest builds. Of course, as a convenience, there might be a full library JAR of all the stable versions. If we can get this library to work for our own tools, then, of course, we should look at creating a greater CJAN library. Something like this would be more like CPAN or SourceForge, and be open to all comers. But we should weed our own garden first. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/about/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] Re: Code Sharing Concepts
* DataSource/Database Pool +1 * XML Configuration +1 * Message Resources / i18n +1 * JNDI / Naming * Testing Suites Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Here you have, ;o)
Clay Atkins [EMAIL PROTECTED] wrote: Hi: Check This! DELETE THOSE TWO MESSAGES! THEY CONTAIN A VIRUS IN THE ATTACCHED VBS FILE. Clay Atkins has been already unsubscribed from ALL mailing lists, and I'll take care of mailbombing him privately later on today... Pier -- Pier P. Fumagalli mailto:[EMAIL PROTECTED] The MessageLabs Virus Control Centre discovered a possible virus or unauthorised code (such as a joke program or trojan) in an email sent by you. Please read this whole email carefully. It explains what has happened to your email, which suspected virus has been caught, and what to do if you need help. Some details about the infected message To help identify the email: The message was titled 'Here you have, ;o)' The message date was Mon, 12 Feb 2001 14:04:53 -0600 The message identifier was 01c801c0952f$1033b6c0$[EMAIL PROTECTED] The message recipients were [EMAIL PROTECTED] To help identify the virus: Scanner 3 (NAI Virus Scan) reported the following: /var/qmail/queue/split/0/659954_2MA-OCTET-STREAM_AnnaKournikova.jpg.vbs Found the VBS/SST virus !!! The message was diverted into the virus holding pen on mail server server-22.tower-4.starlabs.net (id 659954_982008144) and will be held for 30 days before being destroyed. What should you do now? If you sent the email from a corporate network, you should first contact your local Helpdesk or System Administrator for advice. They will be able to help you disinfect your workstation. If you sent the email from a personal or home account, you will need to disinfect your computer yourself. To do this you will need an anti-virus program. We suggest using one of the leading industry anti-virus packages such as McAfee, F-Secure or Cybersoft, which cost £15-£30 per copy. Getting more help You may like to read the Support FAQs at http://www.messagelabs.com/support/FAQs.htm These will answer many of the most common queries. If you believe this message to be a false alarm or you require further assistance, you can email MessageLabs Support at:- [EMAIL PROTECTED] or contact MessageLabs Helpdesk by telephone on:- +44 (0) 1452 627766 Please quote the following Virus Pen ID when contacting Support. mail server server-22.tower-4.starlabs.net (id 659954_982008144) _ This message has been checked for all known viruses by the MessageLabs Virus Control Centre. For further information visit http://www.messagelabs.com/stats.asp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Infrastructure Project Proposal
on 2/12/01 12:38 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: "Why didn't I start working with JUnit instead of creating our own testing environment?" No. My statement really is: Why don't you look to see if you can work with the JUnit community to extend JUnit to do what you want. You are missing the important word there: "community". The point being, yet again I repeat myself, instead of creating yet another project to do Unit testing, why don't you work with the JUnit community to extend it to do what you want. In your email you say: "Overall, JUnit feels very small scale" My response is: Why don't you work with the JUnit people so that it doesn't feel very small scale? Again: don't create yet another project because the other one doesn't fit your needs today. Work with existing projects to make them fit your needs. If they don't want you or the license is incompatible, then that is an acceptable reason to fork. thanks, -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ http://java.apache.org/turbine/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Java select statement
Just a uninformed lurker here... There was a thread on the lack of a select statement in Java awhile back. I was told by a more knowledgable colleague (and thus I might have misunderstood him) that JSR 51 may address this problem... http://java.sun.com/aboutJava/communityprocess/jsr/jsr_051_ioapishtml -Ellis Teer -- e_teer, [EMAIL PROTECTED] on 02/12/2001 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta-tools ? Re: Code Sharing Concepts
I'll try again: 1. As someone said, "community is more important than code" 2. I think the real problem here is not "code sharing" - the fact that people are reticent to reuse code developed in other projects is just an effect 3. I think the real problem is that each project has it's own community and commiters, instead of a shared "jakarta community". 4. I think the only way to solve the reuse problem is to make sure that all jakarta commiters are part of the "tools/utils" project. Agreed totally, As i remember the main complaint to this proposal was the different number of committers from one or other project, this can be resolved doing a representative vote ( 1 project 1 vote ) in this repository.. sure this is not perfect but it's possible, a perfectionist is stationary :), We need to learn a lot first we can do plans, we can suppouse, we can observe CPAN, but nobody knows better than ourself what is jakarta now, and much of us are concerned about his future, let's try to build real community now, better than tomorrow, At internet timing decisions only can be hard to take in future, let's go and do it when it's manageable and prepare things to when it become inmanageable:) My 0.02 Eur Saludos , Ignacio J. Ortega That's my point - I'm not proposing to create ( now ) a repository open to everyone in the world, just to all interested jakarta commiters. Beeing a commiter in one of the projects means more than the fact that you have CVS access and the right to vote - it means you feel part of the project community. If you are commiter in one of the jakarta projects and you are interested in working on any "shared" code, you should automatically be a commiter for the shared piece. My proposal is to create a place where all jakarta commiters have a common interest - the shared tools. If we can't manage this - that means something is broken in the concept of "jakarta community" - and a different solution is needed. But it's worth trying ( starting with few small tools ), and see if we can manage to work togheter. We can have 10 different Pools or StringManagers - in time they'll converge or specialize and cover different niche. There is nothing wrong with having 4 solutions for a test suite, as long as all people working on this are sharing a common repository and community, and the community is open to new code ( even if it's duplicated ) as long as the code is shared. I think all "tools" should be shared - but the code is less important in this case, we should share the community ( by making all jakarta commiters members of the tools project ). Costin [EMAIL PROTECTED] wrote: Again, I don't like the idea of "framework" - i.e. a team managing all tools and releasing them as a whole. It seems what works is the idea of modules ( like CPAN modules ). And the modules should have independent life and evolution. We can tag individual packages for each project that includes it. I don't think anyone has meant to propose that. I have suggested that we create a Jakarta Components Library as a microcosm of the greater project. There would be a core group of Committers (like the PMC) who would act as the overall gatekeepers of the library. Each component in the library would have its own set of Committers, which would usually be the person or persons who wrote the original code, and who has a vested interest in the component. Each component would have its own release schedule and versioning, stable versions and latest builds. Of course, as a convenience, there might be a full library JAR of all the stable versions. If we can get this library to work for our own tools, then, of course, we should look at creating a greater CJAN library. Something like this would be more like CPAN or SourceForge, and be open to all comers. But we should weed our own garden first. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/about/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Costin - 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: Test Infrastructure Project Proposal
On Mon, 12 Feb 2001 12:42:38 -0800, Jon Stevens [EMAIL PROTECTED] wrote: on 2/12/01 12:38 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: "Why didn't I start working with JUnit instead of creating our own testing environment?" No. My statement really is: Why don't you look to see if you can work with the JUnit community to extend JUnit to do what you want. You are missing the important word there: "community". The point being, yet again I repeat myself, instead of creating yet another project to do Unit testing, why don't you work with the JUnit community to extend it to do what you want. In your email you say: "Overall, JUnit feels very small scale" My response is: Why don't you work with the JUnit people so that it doesn't feel very small scale? Again: don't create yet another project because the other one doesn't fit your needs today. Work with existing projects to make them fit your needs. If they don't want you or the license is incompatible, then that is an acceptable reason to fork. From what I can get in Shane's message, there is nothing to fork, he already had his ideas and developed his own framework long before JUnit was in the radar screen. The code is not based on JUnit so there's no worry of forking anything. I believe we should look at the merits of his framework before discussing how or whether it can or should be integrated with JUnit. Your approach of one size fits all doesn't always work. Shane, do you have the code in a shape that could be posted on the Web for others to review? I'm very much interested in a framework that has the capabilities you describe. Thanks, -- Ovidiu Predescu [EMAIL PROTECTED] http://orion.nsr.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Infrastructure Project Proposal
* Ovidiu Predescu ([EMAIL PROTECTED]) wrote : I believe we should look at the merits of his framework before discussing how or whether it can or should be integrated with JUnit. Your approach of one size fits all doesn't always work. I totally agree, and as the original 'cause' of this argument, I think we need to make sure we use the best tool for the job. Extreme Programming is something that is very important to me, it's a methodology which I strongly concur with, and I feel that it is a methodology which I feel translates well to the open source ethos. Shane, do you have the code in a shape that could be posted on the Web for others to review? I'm very much interested in a framework that has the capabilities you describe. I would be *very* interested in seeing this. I should point out that I am very keen to get the original concept moving soonish (originally, I wanted to start unit testing cocoon2), but I believe that all the apache projects could benefit from a testing framework, and I am more than happy if this framework is developed within the infrastructure of the Apache community. Shane - if we can see how you've approached the problem, review what you've done to date, and see if it solves the problems we face (testing media-complex projects such as cocoon is, uh, non-trivial) I'd be eternally grateful. Thanks all, Paul -- Paul Russell Email: [EMAIL PROTECTED] Technical Director Tel: +44 (0)20 8553 6622 Luminas Internet Applications Fax: +44 (0)870 28 47489 This is not an official statement or order.Web:www.luminas.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Any James developers here?
Sam Ruby wrote: It looks like Avalon has been steadily deprecating interfaces that James has been depending on. Now James is broken. http://jakarta.apache.org/builds/gump/2001-02-11/james.html Who wants to volunteer to look into it? Standard reason: if one wants to deploy a server solution involving multiple Apache Jakarta subprojects, each of which depend on different point in time snapshots of Avalon, which version of the avalonapi.jar should one put into the classpath first? - Sam Ruby That's exactly why I want to split java.apache.avalon into three CVS! API (design patterns, interfaces, contracts etc. have a very different lifecycle from the framework implementation and it's critical to the health of projects depending on those API to have two development pipeline separated. Most of the org.apache.avalon package is quite stable... it's been stable for more than one year! What keeps changing is the kernel implementation (Phoenix) on wich dependencies are weeker. P.S. Kudos to the Avalon team for deprecating interfaces. Federico - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test Infrastructure Project Proposal
Hi Erich, Kent. There is a discussion going on in the [EMAIL PROTECTED] mailing list that I would like to invite you two to participate in. I am copying a large number of mailing lists as the original e-mail forwarded below has triggered a lot of separate discussions, but I would like to ask that you follow Scott's request and respond only to [EMAIL PROTECTED] - Sam Ruby -- Forwarded by Sam Ruby/Raleigh/IBM on 02/12/2001 04:37 PM --- [EMAIL PROTECTED] on 02/10/2001 04:06:38 PM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Test Infrastructure Project Proposal Ross Burton [EMAIL PROTECTED] wrote: Having spent all day upto my arm pits in bits of cocoon, xerces and xalan, I've come to the conclusion that tracking down bugs in bits of cocoon can be nearly impossible at the moment. How would you guys feel about us starting to use JUnit to run unit tests over cocoon? First, sorry for the large cross-posting. But I wanted to make sure this note is received by a large audience. Replies should be sent only to [EMAIL PROTECTED] (I'm not subscribed to [EMAIL PROTECTED]). Xalan being a project that 1) requires a *lot* of testing, and 2) is sandwiched inbetween Cocoon and Xerces, 3) is dependent on other technologies like BSF, and 4) is used in several other pipeline scenarios, we (i.e. the folks at Lotus who are involved in the Xalan project) have been doing a lot of thinking about this subject. What is happening in the XML/Web world is the integration of a lot of smaller components, plugged together via (hopefully) standard interfaces. This increases the need for unit testing, and integration testing in a big way. In systems such as we are building, robustness is everything, and fragility is becoming an increasing problem. I feel this is probably the most critical issue xml.apache.org and the Jakarta projects are facing, even above performance issues. The days have ended when Xerces can release without testing with Xalan, and Xalan can release without testing with Cocoon, etc. Also, I feel what we are all practising is pretty close to "Extreme Programming" (http://www.extremeprogramming.org/), by our very motto of "release early and often". Extreme programming is very reliant on having a *lot* of tests that are constantly run (see http://www.extremeprogramming.org/rules/unittests.html and http://www.extremeprogramming.org/rules/functionaltests.html). This means that tests must be very fast to create, easy to plug in, easy to have them become part of the perminant acceptence tests, running the tests must be extremely convenient, and diagnosing problems from the reports must also be easy. And when a bug is found by a user, a test should almost always be added to the acceptence tests (http://www.extremeprogramming.org/rules/bugs.html). We have analyzed JUnit and feel it doesn't address our needs, nor the integration testing needs, though we like it's Ant base. I propose a project for testing infrastructure, that covers the needs of unit testing, stress testing, performance testing, negative testing (i.e. testing of error conditions), integration testing, and error logging and reporting. I don't know or care if this is a Jakarta project or an xml.apache.org project. I believe the Jakarta project has been thinking somewhat along these lines? The Xalan project already has a fair amount of infrastructure that we would be happy to contribute. But basically, I think we should start first with requirements, then a schema for reporting (i.e. design the data first), go next to interfaces, and then decide what existing code can be used. Thoughts? Does anyone want to -1 this? If not, where should it live? (I suspect the answer is in Jakarta, next to Ant). What should it be named? What are the next steps? Who should be the founders? And what about C-language integration testing, as well as other languages (which might argue against a home in Jakarta?)? Again, sorry for the large cross-posting, but I think it's time for this issue to get full attention from all the projects. -scott Ross Burton ross.burton@To: [EMAIL PROTECTED] mail.comcc: (bcc: Scott Boag/CAM/Lotus) Sent by: Subject: Re: [C2] Unit testing. ross@itzinter active.com 02/10/2001 09:37 AM Please respond to cocoon-dev Paul Russell wrote: Guys, Having spent all day upto my arm pits in bits of cocoon, xerces and xalan, I've come to the conclusion that tracking down bugs in bits of cocoon can be nearly impossible at the moment. How would you guys feel about us starting to use JUnit to
Anna Kournikova virus (fwd)
FYI, I just got this message that indicates that the virus we just received uses mail client address books to propagate itself. Willie -- Forwarded message -- Date: Mon, 12 Feb 2001 16:46:11 -0500 From: Jean Rogers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Anna Kournikova virus Another new virus has popped up in the SCS environment. Here are the details: 1. The virus uses mail client address books to propagate itself, so you may get the virus in a mail message from someone you know. 2. It is an attachment, so if you do not open it, you are not infected. Simply delete the message. 3. If you got it and you opened the attachment, send mail to [EMAIL PROTECTED] The subject line of the mail might contain the following verbiage: "Here you have, ;o)" "Here you go" "Here is..." "Here you go :-)" The content of the mail might contain: Hi! Check this! Followed by the virus attachment, which is AnnaKournikova.jpg.vbs Jean Rogers SCS Facilities Help Desk Wean 3613 412-268-4231 www.cs.cmu.edu/~help - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anna Kournikova virus (fwd)
Willie Wheeler wrote: FYI, I just got this message that indicates that the virus we just received uses mail client address books to propagate itself. *Microsoft* mail client address books. That's the critical piece... geir Willie -- Forwarded message -- Date: Mon, 12 Feb 2001 16:46:11 -0500 From: Jean Rogers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Anna Kournikova virus Another new virus has popped up in the SCS environment. Here are the details: 1. The virus uses mail client address books to propagate itself, so you may get the virus in a mail message from someone you know. 2. It is an attachment, so if you do not open it, you are not infected. Simply delete the message. 3. If you got it and you opened the attachment, send mail to [EMAIL PROTECTED] The subject line of the mail might contain the following verbiage: "Here you have, ;o)" "Here you go" "Here is..." "Here you go :-)" The content of the mail might contain: Hi! Check this! Followed by the virus attachment, which is AnnaKournikova.jpg.vbs Jean Rogers SCS Facilities Help Desk Wean 3613 412-268-4231 www.cs.cmu.edu/~help - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: On 2/9/2001 at 8:12 AM Sam Ruby wrote: I would suggest that you start with a proposed code base. Going back over the posts, there seem to be at least five clear areas of overlap: * DataSource/Database Pool +1 * XML Configuration +1 geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java select statement
A good java poll/select discussion can be found at: http://developer.java.sun.com/developer/bugParade/bugs/4066781.html - Pat - Original Message - From: "e_teer" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 12, 2001 3:54 PM Subject: Fwd: Java select statement Just a uninformed lurker here... There was a thread on the lack of a select statement in Java awhile back. I was told by a more knowledgable colleague (and thus I might have misunderstood him) that JSR 51 may address this problem... http://java.sun.com/aboutJava/communityprocess/jsr/jsr_051_ioapishtml -Ellis Teer -- e_teer, [EMAIL PROTECTED] on 02/12/2001 _ Do You Yahoo!? Get your free @yahoo.com address at http://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]
