Sounds like we should delay release 2.0 until this is resolved. In that case, I will begin adding the new monitor code i've been working on. peter lin
"BAZLEY, Sebastian" <[EMAIL PROTECTED]> wrote: They may be optional at run-time, but they're currently not optional at build time, and the jars are in CVS. HiRes timer can definitely be removed from CVS. There is some wrapper code that was written separately that might be useful to keep. JS can almost certainly be removed from CVS and zip files without causing too much grief, but we'd need to check the effect at run-time. Tidy can be removed entirely from HTML parsing, but also has some SAX stuff in it that we might need. There are bound to be Apache alternatives. JDom is also used in a few places; not sure how easy it would be to remove it. So I think a bit more work is needed - this may well need to be resolved before the next release... S. -----Original Message----- From: peter lin [mailto:[EMAIL PROTECTED] Sent: 10 March 2004 13:39 To: JMeter Developers List Subject: RE: Clarifying some licensing issues for Apache developers] so looks like were OK for the most part. most of the external jars are optional already. How do we want to treat jars from other sources? Now that we have the regexp and htmlparser, and tidy is optional. removing it from the bin distro should be ok, as long as we let users know in the docs. peter lin "BAZLEY, Sebastian" wrote: Actually, it's the Apache BSF that we use, so it's not a problem. But anyway, JMeter CVS and the zips only USE BSF (and BeanShell, which is not ASF) - it does not include any of the BSF or BeanShell code. This is done using reflection where necessary. In order to build the code that uses BSF/BeanShell, the developer currently has to download the appropriate Jars. In the Gump builds, they are optional dependencies. The end-user only needs to download the jars if they are actually used by their test script. I've assumed that this gets round the limitations in Brian's e-mail, as there's no BSF or BSH jar in CVS or the zips. == It would be possible, but rather tedious/time-consuming/less efficient to take the same approach with the other jars. [BSF and BSH have a very simple API.] One possible solution might be to code skeleton classes for the external APIs; this would allow the calling code to be built stand-alone, and the actual jars would only be needed at run-time. The dummy code would need to use the same package names and class names etc as the real code - would that cause any license problems? There still remains the nuisance value for the end user of having to download multiple jars to get started, but I suppose we could supply a page with the links to the web-sites. Alsp possibly Ant targets to get the code (but what do we need to do about licences?). S. --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you're looking for faster. ___________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___________________________________________________________________________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster.
