Am 17.11.2015 um 20:06 schrieb UBIK LOAD PACK:
Hello,
Can we start the IP clearance process or is there some step before ?
Don't know, if there are any steps to do, but I didn't find the time to
have a deeper look at the code up to now.
At a glance,
* there seem to be missing license header for the new stuff
* commented out old code, should probably removed before inclusion
* the js.fmkr files seem to pollute the global js-namespace.
* the html.fmkr files contain style-attributes
* since we are obviously targetting modern browsers, the apache logo
could probably be in svg format
* indentation of html.fmkr seems a bit out of place sometimes
Regards,
Felix
Thanks
Regards
On Tuesday, November 10, 2015, Richard Friedman <[email protected]>
wrote:
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]
<javascript:;>>
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]
<javascript:;>>:
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] <javascript:;>> 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
