The report dashboard uses the same output directory for each report. This is a big nuisance
What do you propose ? Setting it to the configured property with a suffix like -yyyymmddHHmmss where date is the date of start of test ? Thanks
The directory name could be derived from the csv file name. That would be better than nothing. A timestamp would be overkill, as repeat reports would generate new versions unnecessarily. Or I suppose you could use the source file name plus a hash of the contents? That could be optional - I suspect it's enough to just use the file name.
I documented in docs/usermanual/generating-dashboard.html how generating to a particular repository can be done using : -Jjmeter.reportgenerator.exporter.html.property.output_dir=<Path to output folder> Closing it.
Although that allows the user to avoid overwriting the previous output, it's not exactly user-friendly. If the feature is to be of any use, it needs to work without needing a hack like this. We're going to get a lot of annoyed users (and many queries on the lists) if the code is released as is.
Hi Sebb, I propose to add -o option for output directory. Is it ok for you ? Thanks
That's marginally better than having to define a property (which can already be done on the command line), but still does not make the feature easy to use. Also there are already an lot of CLI options; do we really want another one?
I don't think feature is hard to use with last updates to documentation. My colleagues have been using it (the one that generates on demand, not after run) without any help. I don't see why this additional option would make it harder, I personally think that it's ok as is, but if we need to make it clearer, we have a tool that generates a report,I suppose user can guess that they must tell the tool where to generate Furthermore, since the fix to options display, they run jmeter -h and they get all the required information. If there is a field to improve, it would be to switch from old avalon CLI classes to new commons-cli to make command line options more readable by having more than 1 character. So unless you have a better idea, either we keep it as is, or I add this additional option. Regards
(In reply to Philippe Mouawad from comment #7) > I don't think feature is hard to use with last updates to documentation. That's because you know it well. > My colleagues have been using it (the one that generates on demand, not > after run) without any help. They are colleagues, so have probably seen you running it. > I don't see why this additional option would make it harder, I personally > think that it's ok as is, but if we need to make it clearer, we have a tool > that generates a report,I suppose user can guess that they must tell the > tool where to generate I did not say that the additional option would make it harder, but it won't make it any easier. > Furthermore, since the fix to options display, they run jmeter -h and they > get all the required information. > > If there is a field to improve, it would be to switch from old avalon CLI > classes to new commons-cli to make command line options more readable by > having more than 1 character. The problem is the sheer number of options, not their verbosity. > > So unless you have a better idea, either we keep it as is, or I add this > additional option. I already suggested creating the directory name from the csv file name. > Regards
(In reply to Sebb from comment #8) > (In reply to Philippe Mouawad from comment #7) > > I don't think feature is hard to use with last updates to documentation. > > That's because you know it well. > > > My colleagues have been using it (the one that generates on demand, not > > after run) without any help. > > They are colleagues, so have probably seen you running it. No :-) > > > I don't see why this additional option would make it harder, I personally > > think that it's ok as is, but if we need to make it clearer, we have a tool > > that generates a report,I suppose user can guess that they must tell the > > tool where to generate > > I did not say that the additional option would make it harder, but it won't > make it any easier. The name will be much easier to write: -o <Path to output folder> vs -Jjmeter.reportgenerator.exporter.html.property.output_dir=<Path to output folder> And it will be display when running: - jmeter -h > > Furthermore, since the fix to options display, they run jmeter -h and they > > get all the required information. > > > > If there is a field to improve, it would be to switch from old avalon CLI > > classes to new commons-cli to make command line options more readable by > > having more than 1 character. > > The problem is the sheer number of options, not their verbosity. > > > > > So unless you have a better idea, either we keep it as is, or I add this > > additional option. > > I already suggested creating the directory name from the csv file name. I don't see how it solves the problem. For example, in my usual configuration, the file names always has the same name, so I would end up overwriting it. I find it also counter intuitive. I personally prefer the output option. > > > Regards
(In reply to Philippe Mouawad from comment #9) > (In reply to Sebb from comment #8) > > (In reply to Philippe Mouawad from comment #7) > > I did not say that the additional option would make it harder, but it won't > > make it any easier. > > The name will be much easier to write: > -o <Path to output folder> > vs > -Jjmeter.reportgenerator.exporter.html.property.output_dir=<Path to output > folder> Yes, -o is easier than -J. But both are harder than not having to specify the directory at all. And you have to remember to do it. > I don't see how it solves the problem. Remember that this is a new feature; people are likely to have lots of CSV files that they want to convert. Do they really want to have to specify both the CSV name and the directory name? > For example, in my usual configuration, the file names always has the same > name, so I would end up overwriting it. In which case you have already overwritten the CSV file. In any case it's more flexible than always overwriting the report. == Now if the default name were derived from the CSV file (rather than being fixed), your existing property hack would allow you to rename it to anything you wanted. You would be no worse off. But at least others would not accidentally overwrite their reports because they omitted to define the dir name
Author: pmouawad Date: Mon Feb 29 20:57:32 2016 New Revision: 1732944 URL: http://svn.apache.org/viewvc?rev=1732944&view=rev Log: Bug 58986 - Report/Dashboard reuses the same output directory Bugzilla Id: 58986 Modified: jmeter/trunk/bin/jmeter.properties jmeter/trunk/src/core/org/apache/jmeter/JMeter.java jmeter/trunk/src/core/org/apache/jmeter/report/dashboard/HtmlTemplateExporter.java jmeter/trunk/xdocs/changes.xml jmeter/trunk/xdocs/usermanual/generating-dashboard.xml
Author: pmouawad Date: Mon Feb 29 21:18:55 2016 New Revision: 1732948 URL: http://svn.apache.org/viewvc?rev=1732948&view=rev Log: Bug 58986 - Report/Dashboard reuses the same output directory Take into account sebb note on dev mailing list: "- The precedence is wrong; command line options should always override property definitions." Bugzilla Id: 58986 Modified: jmeter/trunk/src/core/org/apache/jmeter/report/dashboard/HtmlTemplateExporter.java Author: pmouawad Date: Mon Feb 29 21:20:59 2016 New Revision: 1732949 URL: http://svn.apache.org/viewvc?rev=1732949&view=rev Log: Bug 58986 - Report/Dashboard reuses the same output directory Take into account sebb note on dev mailing list: "- The precedence is wrong; command line options should always override property definitions." Bugzilla Id: 58986 Modified: jmeter/trunk/bin/jmeter.properties
Author: pmouawad Date: Mon Feb 29 21:37:12 2016 New Revision: 1732951 URL: http://svn.apache.org/viewvc?rev=1732951&view=rev Log: Bug 58986 - Report/Dashboard reuses the same output directory Document new command line option Bugzilla Id: 58986 Modified: jmeter/trunk/xdocs/usermanual/get-started.xml
-g option silently overrides -l, -r, -R. They don't make sense together, but the user should be warned.
(In reply to Sebb from comment #14) > -g option silently overrides -l, -r, -R. > > They don't make sense together, but the user should be warned. Note: just noticed that the CLI parser can do this; I'm working on fixing this.
(In reply to Sebb from comment #15) > (In reply to Sebb from comment #14) > > -g option silently overrides -l, -r, -R. > > > > They don't make sense together, but the user should be warned. > > Note: just noticed that the CLI parser can do this; I'm working on fixing > this. There are other options that ought to be checked against each other; raised Bug 59091 to deal with them all together.
Closing as you opened Bug 59091
I don't think this is quite fixed. There are two aspects: The standalone command-line looks like this: jmeter -n -g <log file> -o <Path to output folder> There is really no need for the -n option. The other aspect which I think is still an issue is that the output directory should be derived from the log file (but still allowing an override). This would be much simpler for the user: jmeter -g <log file>
It can be in a 3.1 Let's see how users receive it. I don't find your proposal very intuitive and if user uses always the same output file, how do you proceed ?
We've already discussed that. At present if the -o flag is omitted, ALL output goes to the same directory, regardless of input file name. At least if the default output file is derived from the input file name, the user will only need to provide the output name if they redo the test. Whereas with the existing code, the -o flag is pretty much mandatory if one is working with multiple input files. === I think there's another problem. If the -o flag is omitted, the output always goes to report-output/ There is no check to see if anything is being overwritten. Whereas with -o, the target directory has to be empty or non-existent. This is inconsistent. [Note: if the name is derived from the input file, my intention was to do the same checks] At present it's awkward to convert lots of existing files, and far too easy to lose the output.
I suggest the following: - I add the check of emptyness to default folder for 3.0 - You close this one and open a new Bugzilla with your idea that we delay to 3.1 This way we can close this one and progress on 3.0 release. Thanks
Author: pmouawad Date: Sun Mar 20 13:24:14 2016 New Revision: 1735879 URL: http://svn.apache.org/viewvc?rev=1735879&view=rev Log: Bug 58986 - Report/Dashboard reuses the same output directory Factor in JOrphanUtils the check for output folder and make it more readable and complete Add the check in both HtmlTemplateExporter and JMeter as per sebb request Bugzilla Id: 58986 Modified: jmeter/trunk/src/core/org/apache/jmeter/JMeter.java jmeter/trunk/src/core/org/apache/jmeter/report/dashboard/HtmlTemplateExporter.java jmeter/trunk/src/jorphan/org/apache/jorphan/util/JOrphanUtils.java
(In reply to Sebb from comment #18) > I don't think this is quite fixed. > > There are two aspects: > > The standalone command-line looks like this: > > jmeter -n -g <log file> -o <Path to output folder> > > There is really no need for the -n option. > > The other aspect which I think is still an issue is that the output > directory should be derived from the log file (but still allowing an > override). > > This would be much simpler for the user: > > jmeter -g <log file> URL: http://svn.apache.org/viewvc?rev=1735914&view=rev Log: Report/Dashboard reuses the same output directory No need for -n option when running generator only (-g) Bugzilla Id: 58986 Modified: jmeter/trunk/src/core/org/apache/jmeter/JMeter.java jmeter/trunk/xdocs/usermanual/generating-dashboard.xml
Author: pmouawad Date: Sat Apr 2 08:45:33 2016 New Revision: 1737472 URL: http://svn.apache.org/viewvc?rev=1737472&view=rev Log: Report/Dashboard reuses the same output directory Fix regression introduced by commit r1735914, the output folder was no more read for -g option Bugzilla Id: 58986 Modified: jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/3824