I'm subscribing to the board mailing list to see what's going on. In the meantime, I suggest we figure out what our strategy will be for removing the binaries and helping end users get them. There are some various options, not necessarily exclusive:
1. Adopt Maven to help with grabbing dependencies 2. Write Ant tasks to download various dependencies 3. Document jars, urls, and instructions 4. In any case, each component must have its dependencies documented 5. Make an auto-update feature within JMeter to go grab jars on first startup if jmeter determines it doesn't have what it needs, or on component's first use. 6. Distribute JMeter binaries at sourceforge 7. ? Does anyone know about licensing problems with helping users download jars? If the user does it manually, we don't seem to have to do much (ie the mail api's). If we code an ant task to grab it, does that imply some responsibility for Apache to inform the user of license issues? -Mike On Wed, 2004-03-10 at 09:31, peter lin wrote: > 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 youre looking for faster. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
