yeah I have to agree on all points. Mike and I talked about this. since httpsampler is used by more people and the throughput more than doubled with HTMLParser, I thought it was worth while. I take the responsibility of keeping the two in sync if there are patches and bug fixes. It is more work, but considering the benefit I felt it was worth it. the newest Junit doesn't seem to conflict with any existing code, atleast not when I build it or in eclipse. The two CVS thing shouldn't be a problem, since the current release is stable and works well. next week I plan to profile the old and new (tidy vs htmlparser) and post my findings. peter
"BAZLEY, Sebastian" <[EMAIL PROTECTED]> wrote: Fine by me. [Although the task could be added anyway - it doesn't have to be used.] We should probably update the Junit jar anyway. [But I think we should work towards having the testing code eeparated out, so Junit becomes optional.] Another approach that one might take with problematic licences is to include only the interface code in JMeter CVS, and have the code fail gracefully if the jar is not present at runtime. [I did this with BeanShell.] It is then up to the user to decide whether or not to download the optional jar(s). Since the jar would not need to be provided, I presume this gets round the problem - c.f. isasilk. However, if adding the code to JMeter CVS effectively changes the licence, perhaps that's the way to go, although I'm not happy that there should be two separate CVS versions ... Sebastian -----Original Message----- From: peter lin [mailto:[EMAIL PROTECTED] Sent: 17 October 2003 13:37 To: JMeter Developers List Subject: Re: HTML Parser code - should it be in JMeter CVS? hey sebastian, can we wait on adding the build task for htmlparser. I was going to see what people think about updating the JUnit jar. The reason we didn't just add the jar is HtmlParser uses LGPL license, which is incompatible with Apache license. Therefore I got permission from the htmlparser developers to use it and change the license in the source. If everyone is ok with using the newer JUnit, I can make the update this weekend and test the build task for htmlparser. peter lin "BAZLEY, Sebastian" wrote: Following up my own post: Would it not be possible just to include the HTML Parser code as a pre-compiled jar in the lib directory? I'm not sure what the benefits are in having a local copy of the code, unless the Sourceforge version is no longer being maintained. S. -----Original Message----- From: BAZLEY, Sebastian Sent: 17 October 2003 01:41 To: JMeter Developers List Subject: HTML Parser code Very useful. By the way, the test utilities give compilation errors, as assertFalse() is not defined in junit.jar as currently used with JMeter. Easy enough to solve - replace with assertTrue(), or update junit.jar. Doesn't bother me which is done, so long as the new code does not get included in build.xml until this is resolved. However, a new target could be added so long as it was not invoked by any of the existing ones, especially "dist" which is favoured by Gump. I've updated eclipse.classpath already, but that does not get used automatically. S. --------------------------------------------------------------------- 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] --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search
