I am not a committer but think very much this feature is needed for future JMeter and this is a good start.
1 - Great job on building it. I built it and integrated into some of my work already. I have posted some issues. I think there is some work to do before an official release, but would good to have this work started in apache proper. 2 - Definitely need architecture documentation and make sure it becomes very pluggable, especially if someone wants to contribute on the client side only. I like the report-template separation allowing any template to happen. 3 - Requirement for jmeter.save.saveservice.print_field_names=true I understand the need for this when generating the file, but I am run remotely and report locally. I think the parser could be smarter looking for the common field names. I think this becomes a different issue when there are custom fields from plugins vs the common. 4 - Configuration Why not put the configuration with the template instead of in jmeter.properties (or user.properties). The configuration for the Report Generator that is not template or report specific ( ie template dir, temp dir, .. ) should be in jmeter.properties On Tue, Nov 10, 2015 at 3:45 AM, Antonio Gomes Rodrigues <[email protected]> wrote: > Hi, > > I agree with Philippe, all the competitors (LoadRunner, Neoload, Gatling, > SilkPerf, etc...) can generate a nice reporting at the end of the load > test. > > Each time I use another load test tool, I use this feature to analyze the > load test. > > Each time I use JMeter, it's boring because I am forced to use another tool > (QlickView, etc.) to make it > > It will be great to have it in JMeter because it's important (to be > competitive and it's useful) > > Antonio > > > > 2015-11-09 22:21 GMT+01:00 Philippe Mouawad <[email protected]>: > > > Hello, > > As a JMeter commiter I think this feature should be integrated to Core. > > > > Lack of nice reporting in JMeter is no more acceptable nowadays, all > > Commercial and Open Source competitors have reporting now and it's a weak > > point of JMeter. > > > > The code respects JMeter best practices as far as I can tell, there is > > documentation (dev and users) and javadocs. > > > > PS : Note that I am not totally neutral here being a member of Ubik Load > > Pack Team. > > > > Regards > > Philippe > > > > On Fri, Nov 6, 2015 at 11:12 AM, UBIK LOAD PACK < > > [email protected]> wrote: > > > > > Hello, > > > We have completed our UATs for V1 milestone and fixed all bugs and > > > enhancements detected. > > > > > > We released Preview 1.0.0: > > > - > > > > > > https://github.com/ubikloadpack/jmeter/releases/tag/2.14-preview-ubikloapack-1.0.0 > > > > > > Users and Dev team can this way download the bundle and test it, page > > > above mentions all required informations to test, report issues and > see a > > > demo. > > > > > > We think this feature is really needed in JMeter and it has been > > developed > > > to ensure it never impacts load testing, reports being generated at > end. > > > > > > If you look at code there is 0 risk of regression as it's an > additional > > > behaviour that is activated by new command line options. > > > > > > We'll be happy to provide JMeter Team with all requested information > > > regarding design, implementation ... > > > > > > We really hope it will be accepted by the Team. > > > > > > Thanks in advance and kudos for all your work on JMeter. > > > > > > Regards > > > Ubik Load Pack Team. > > > > > > > > > > > > > > > > > > > > > -- Richard Friedman 609.314.0129
