...

• Use Java 1.5 for building, but only require 1.4 for running. Is this easy to do? Can it be done in Eclipse?
• Look into warnings when compiling code, some deprecated code should be replaced
• Currently, Apache Avalon seems to be used for logging. Avalon seems to have stalled, should we move to log4j ?
  • I looked into adding a GUI / dialog for "Help->View log" to easily view the jmeter log file from the application itself.
    • Seems to be some open source tools available for log4j which does that out of the box.
  • Would we gain functionality by moving to log4j ?
  • Alternatively, move to Commons Logging (as used by HttpClient currently)
  • Or perhaps SL4J - http://www.slf4j.org/
  • What are the risks with continuing to use Avalon, if Avalon is not maintained anymore ?

  • Wiki Markup

    Remark: Http{{`Components project is considering migrating Http}}`Client 4.0 branch off Commons Logging to another logging framework as Commons Logging currently appears unmaintained and the prospects of its further development remain unclear. \[Does it need any development? sebb\] It may be worthwhile to ensure both projects use the same logging framework / compatible logging frameworks. \[Agreed: sebb\]

• Upgrade to httpclient4 ? httpclient4 is still only in Alpha. Should / could we have one sampler class using httpclient3 and one httpclient4 ?
• Remove some code in HTTPSampler, which is there fore workaround for httpclient3.0 bug, which has been fixed in httpclient3.1
• Reorganise documentation
  • component_reference is getting much too big. This will require changes to the help system.
  • sort functions and component ref into more logical order (currently chronological)
  • perhaps use separate XML files for each item, included by main pages ?
  • Could we then add a "Help" button to each GUI element, which would bring up the correct help in the browser ?
  • or extend the existing help menu to load just the individual page.
  • If there are combined and individual help pages, there would probably need to be two copies. Maybe simplest just to split component reference by element type; keep current page as an index into the subsections
  • Help could perhaps be extended to allow loading of linked pages (but one would probably not want to allow external links to be loaded). There is some code in View Tree that might help here.
• Re-write ClassFinder:
  • needs general tidyup / javadoc
  • cache results - same classes may be requested multiple times
  • find a way to scan the classes without needing to load them:
    • BCEL, or
    • perhaps use a pre-generated list of class names in a file which is regenerated if any jar files change (MD5)
• TestBean:
  • prepare is probably called too often; can it be done once per test?
  • need some more GUI types - eg. table
  • would be nice to be able to enable/disable fields depending on what else is selected - e.g. JDBC parameters only needed for prepared statements
  • ensure drop-down list size big enough for all entries (within limits!)
• move from Bugzilla to JIRA? More flexible, (but attachments a bit more awkward at present?)
• Change control logic so it does not use Exceptions for normal situations
• Can we add Beanshell jar to the distribution? If so, then some BeanShell elements could be simplified. License is either SPL or LGPL, but versions are not stated; not clear if allowed.
  • According to http://people.apache.org/~cliffs/3party.html, we can include libraries in binary form if licensed under SPL
  • The http://www.beanshell.org/license.html states it is dual licensed under SPL/LGPL
  • We should probably email the author of BeanShell and check if he could be more precise on the licensing on the web page ?
• JMS GUIs should be loadable without needing JMS jars (needs an extra level of indirection, as is done by JMS Publisher) or as below.
• How to handle Gui elements that depend on optional jars:
  • should these be displayable, even though the jars are missing? Convenient for creating and viewing test pans, but not so useful at run-time - should the test plan be allowed to run?
  • or should they be omitted as at present? - this is confusing at build time.
  • or perhaps generate a dummy entry in the list, with a message to say the jar is missing? his would be tricky, as the class is needed to retrieve the name and the menu category. Perhaps the way to do it is to handle it in the GUI by catching the errors, and changing the name or screen comment? May be tedious to do.
• Sort test tree according to JMeter processing order? This should probably be a separate action, as it would be confusing for the tree to change as it was editted!
• Re-order HTTP request defaults fields to be like sampler
  • Protocol
  • Host Port
  • Path
  • Encoding
• introduce Generic HTTP Sampler which can do either Java or HttpClient or ...
  • could be new sampler GUI with new underlying test elements
  • but it would be nice if existing test plans were converted into the new sampler. Looked at this a while back, but got stuck with XStream aliasing, which has to be one-to-one at present. However, the code change to SaveService to remove the class loading should make it possible to have multiple aliases for a single class. That might be sufficient, otherwise we'll need a suitable converter.
  • I think the GUI should just contain a dropdown "Client implementation", with values like "Java JRE", "HTTPClient 3.1", "HTTPClient 4.0" etc.
• Improve "org.apache.jmeter.JMeter" class by removing the hack in "ListenToTest", which causes JMeter to always sleep 5 seconds before exiting when run in batch
  • I think this relates to how threads are closed and lingering samples are handled. How is it solved in the "GUI" mode ?
• GUI code refactor
  • there are various table implementations, could they be combined?
  • perhaps the table models could also be combined?
• Add SVN revision number to version? (already added to Manifests)

• Wiki Markup
  Consider migration to Maven2 as a build tool for JMeter. This should help simply dependency management and facilitate the use of JMeter for automatic load testing / integration into tools like \[http://maven.apache.org/continuum/ Continuum\]

  • Maven 1 was tried a couple of years ago, and seemed incompatible with the JMeter directory layout and multiple jars; hopefully Maven 2 is more flexible.
• Consider renaming ThreadGroup as JMeterThreadGroup Thread{{`Group as JMeter}}ThreadGroup - or UserGroup ? - to avoid confusion with java.lang.ThreadGroup Thread`Group
• Documentation refers to threads and/or users in different places; replace by users - or users(threads) - everywhere?
• Test elements need access to Thread{{`Group and Test}}`Plan for co-ordinating counts etc per-group and per-plan. Not much distinction is currently made between per-group and per-plan.
  

Release strategy

Only JMeter committers should change this section, though others may comment.

...