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" <[EMAIL PROTECTED]> 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.
