Yay Apache and licensing issues... It sounds to me like a reporting framework should not be linked to JMeter's gui in any way - it serves no purpose. What is needed is an extendable framework for writing reporting components that take a .jtl file and convert it to whatever report a user wants. Running this tool should be simple and not tied to JMeter itself (though a menu option to run a report on a jtl would be good).
I don't know what form is should take - ready-made xslt scripts (yuck), JasperReport scripts (or whatever - I'm not familiar with Jasper), or something else. Keep in mind a .jtl file can be either an xml or csv format. -Mike On Thu, 2005-08-04 at 11:50 -0400, Peter Lin wrote: > the idea of using jasper reports sounds nice, but not sure about > license issues, since jasperReports uses LGPL license. > > peter > > > On 8/4/05, Joseph Fifield <[EMAIL PROTECTED]> wrote: > > This is basically what I did with xslt to generate the html reports when > > I did the ant task. What about doing something similar to generate > > reports in other formats? This should be relatively straightforward for > > something like JasperReports as the report files are just xml anyway. > > > > Joe > > > > Peter Lin wrote: > > > yeah, I was thinking the same thing. this way, in an automation > > > process, it might run several test plans and save the JTL files to a > > > specific directory. > > > > > > after the tests are done running, jmeter could be called to process > > > the JTL files and output the reports. > > > > > > peter > > > > > > > > > On 8/4/05, sebb <[EMAIL PROTECTED]> wrote: > > > > > >>It would be useful if the Reporters could read existing test logs in > > >>non-GUI mode too - assuming of course that the relevant raw data has > > >>been logged. > > >> > > >>S. > > >>On 04/08/05, Peter Lin <[EMAIL PROTECTED]> wrote: > > >> > > >>>you're right, there probably needs to be a GUI component for creating > > >>>the report settings. the primary difference between the simple data > > >>>writer and report components is the reports would be for statistics. > > >>> > > >>>for example, say an user has an overnight automation process that hits > > >>>a website. if the user wants to generate a detailed report of the > > >>>failures by HTTP response codes, we currently don't support that. if > > >>>the user wants to those stats to be in a pie chart, we also don't > > >>>support that. > > >>> > > >>>I have a need for report automation, so I think it "might" be a good > > >>>idea to have them be separate type of components like > > >>>StatisticalReport components. > > >>> > > >>>peter > > >>> > > >>> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
