Jordi Salvat i Alabart wrote: [snip]
2/ ContributionsIf there is not already one we should find consensus on a code styleguide. With different code formattings it is hard to colaborate in a team. I had this kind of discussion with different teams and usally you take the Sun styleguide and then it is a question of how much spaces to use for indentation and where to place opening braces, at the end of the line or the beginning of the next line. After that we could add a checkstyle target to the build file so everybody can check if the sources conform to the styleguide before committing changes to cvs.
We want to encourage the people who use JMeter to contribute. I believe the best way to do this is to make things easy for them. In my opinion, there's some technical aspects of JMeter which place a too high threshold on this. The relationship between GUI and test elements and this Avalon configuration stuff were the most important for me. Poor JavaDoc documentation is another. Absence of nightly builds is probably the worse. Even sloppy indenting contributes to the difficulties. Is there any non-technical issues we should address on this matter?
3/ Long-term development planI have lots of post-it notes here on my desk with ideas for improvements and new features I collected while using JMeter, reading postings in the user list and doing the refactorings I'm working on at the moment. Here is a small selection:
We lack a long-term development plan. JMeter is still far from being a mature product, yet its development is mainly driven by bug-fixing and small functional enhancements. At the very least, we need to agree on a loose high-level end-user requirement list [I think I already have a document of this kind somewhere -- the one I used to select JMeter among other tools quite a few months ago].
- make the workbench a real workbench where you create/record and test your tests and move them to your test plan as soon as they are working. This requires the possibility to run a single samplers/controller/thread group to check if your tests are working.
- "Server Sets" - it is very annoying at the moment to run your test plan against different servers (maintain different test plans or change the server variables manually each time you run a test). Therefore Server Sets: you define a test plan-global list of servers used in your tests, e.g. HTTPServer1, HTTPServer2, FTPServer. The samplers just hold the logical name of the server to use, e. g. HTTPServer1 for a HTTP request. A server set holds the concreate configuration for each server in the list. This way it is easy to maintain different configurations of test servers and you just select the server set you wish to use in a combo box before running the tests.
- make the xml format more readable for users. Sometimes I would like to change things in the xml because it takes 10 mouse clicks in the GUI to change a http request parameter somewhere deep in the tree. And if the format is readable you could even write your test plan without the JMeter GUI by just using an xml editor. I think this would be a cool feature for the JMeter power user.
- make remote testing easier to use. There are lots of postings in the user list from users who have problems to get their distributed JMeter servers up and running, and most of the problems are related to RMI and rmiregistry stuff. Perhaps we should think about not to use RMI but to do the communication between the JMeter master and the distributed agents on our own. It should be not too difficult to send serialized Java objects over a socket, and the user would just have to start JMeter in server mode. No RMI and rmiregistry he has never before heard of.
Oliver
smime.p7s
Description: S/MIME Cryptographic Signature
