[Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

Hey sebb,

mike and I were just chatting about some enhancements to JMeter. I was
thinking, it might be nice to be able to run jmeter in console mode
and have it dump out graphs or statistics. My thought was to do the
following.

1. create a new type of component called Report
2. there would be an Abstract class for it
3. it would behave similar to a listener, except minus the GUI part.
4. there would be two base output types: text and png
5. any statistics would be passed to the output type, which generates
the file or image


what do you think?

peter

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[sebb <se...@gmail.com>]

On 04/08/05, Michael Stover <ms...@apache.org> wrote:
> 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).
> 

Agreed.

However it would be useful to extend JMeter to add more output to the
JTL files for the reporting system to then use. Someone has already
asked for sampleData size to be logged; there are no doubt other items
that could be included.

Not sure if it would be possible to do this other than by adding more
code to the output methods each time a new field is required.

> 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.
> 

We use Perl for summarising the CSV files.

> 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

I've been steadily working on the reporting component the last few
days. I was thinking of making an interface named ReportWriter and
have an abstract base implementation like the rest of jmeter.

public interface ReportWriter
public abstract class AbstractReportWriter

some other random thoughts about writing reports.

1. is it desirable to have the reportWriters use external
header/footer files? if so what the preferred embodiment?

2. I was thinking HTML reports should support the ability to use a
server side include, like .shtml. What do people think?

3. the kind of report designers I was thinking of would provide to
basic format at the start: CSV and html

4. A report could have multiple summary tables and charts. For
example, say I want one chart of all the max, min, average times and a
second table for error rate, req/sec and kb/sec.

peter lin

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

that's definitely a good thing to do. in either case, I still don't
know which way is better to go. it seems like the guys who start
jcharts are also apache guys.


peter


On 8/8/05, sebb <se...@gmail.com> wrote:
> I don't see why we can't include the link in the JMeter documentation.
> 
> We already do this for BeanShell, I think.
> 
> S.
> On 08/08/05, Michael Stover <ms...@apache.org> wrote:
> > Couldn't we have a page on the wiki or somewhere that provided a list of
> > links to the third-party jars JMeter can use optionally?  Maybe it's not
> > allowed to link directly to the jar file, but surely we can link to a
> > download page of BSF, BSH, JCharts, JSSE, JavaMail, etc?
> >
> > -Mike
> >
> > On Mon, 2005-08-08 at 13:31 -0400, Peter Lin wrote:
> > > right, but I would like to avoid asking users to download yet another
> > > jar lib. seems like such  a hassle for users to have to go find the
> > > jar file and download it.
> > >
> > > perhaps this would be better as a sourceforge project that just plugs
> > > in to jmeter or reuses jmeter components.
> > >
> > > peter
> > >
> > >
> > > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > > I'm not saying we should not write code to use JCharts, just that we
> > > > should not distribute the jar.
> > > >
> > > > For example, the BeanShell jar is optional, but the code exists to use it.
> > > > Likewise we don't (can't) redistribute mail.jar and activation.jar.
> > > >
> > > > Needs a bit of care to ensure that the code behaves sensibly if the
> > > > jar is missing at run-time, but otherwise is not all that difficult.
> > > >
> > > > Any JMeter code that uses JCharts should be in a separate jar if not
> > > > application anyway.
> > > >
> > > > S.
> > > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > in that case, would it be better to write our own chart/graph ?
> > > > >
> > > > >
> > > > > peter
> > > > >
> > > > > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > > > > I can't see any benefit of including JCharts in the JMeter zips or CVS
> > > > > > - if people want to use it, they can download the jar for themselves,
> > > > > > and be sure of getting the latest.
> > > > > >
> > > > > > We should just provide any necessary instructions, eg in the extras directory.
> > > > > >
> > > > > > S.
> > > > > >
> > > > > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > > that's a good point. I didn't think that far. I suppose we can always
> > > > > > > have 2 downloads:
> > > > > > >
> > > > > > > 1. jmeter normal
> > > > > > > 2. jmeter with reporting
> > > > > > >
> > > > > > > of course, this assumes I do a decent job on the reporting component
> > > > > > > and people actually want to use it. I think jcharts uses apache style
> > > > > > > license, but I'll make sure.
> > > > > > >
> > > > > > > peter
> > > > > > >
> > > > > > >
> > > > > > > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > > > > > > Agreed we can't at present include LGPL jars in JMeter distributions.
> > > > > > > >
> > > > > > > > Even with JCharts, I wonder whether the jar should be included with
> > > > > > > > JMeter, as not everyone will need the functionality.
> > > > > > > >
> > > > > > > > S.
> > > > > > > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > > > > Since JasperReports is LGPL, we can't really use it. I took a look
> > > > > > > > > around and it looks like jcharts provides some good functionality.
> > > > > > > > >
> > > > > > > > > http://jcharts.sourceforge.net/
> > > > > > > > >
> > > > > > > > > I already started working on the GUI and framework part of it. Most of
> > > > > > > > > the design tries to stay close to current JMeter design patterns and
> > > > > > > > > conventions. I plan to check something into CVS HEAD at the end of the
> > > > > > > > > week. Should I check it into the new Subversion instead?
> > > > > > > > >
> > > > > > > > > peter
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 8/4/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > > > > > I was think to write/configure the report settings.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > peter
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > > > > I'm not sure what the point of the gui is.  Although it's nice to show a
> > > > > > > > > > > report gui, there are other tools for that.  I'm thinking these report
> > > > > > > > > > > generators are essentially creating output for
> > > > > > > > > > > excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> > > > > > > > > > > gui in JMeter could assist to control command-line parameters to the
> > > > > > > > > > > report generator, but that's it, IMO.
> > > > > > > > > > >
> > > > > > > > > > > I just don't want to get JMeter into the business of being report
> > > > > > > > > > > viewing software.
> > > > > > > > > > >
> > > > > > > > > > > -Mike
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > > > > > > > > > > > JCharts uses apache style license, so we can use that for the charts
> > > > > > > > > > > > and graphs. in terms of reports, it might be nice to have a separate
> > > > > > > > > > > > reporting GUI. Though I was thinking of taking the easy way out and
> > > > > > > > > > > > have it be a normal jmeter plugin that loads in the same gui
> > > > > > > > > > > >
> > > > > > > > > > > > peter
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > > > > > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[sebb <se...@gmail.com>]

I don't see why we can't include the link in the JMeter documentation. 

We already do this for BeanShell, I think.

S.
On 08/08/05, Michael Stover <ms...@apache.org> wrote:
> Couldn't we have a page on the wiki or somewhere that provided a list of
> links to the third-party jars JMeter can use optionally?  Maybe it's not
> allowed to link directly to the jar file, but surely we can link to a
> download page of BSF, BSH, JCharts, JSSE, JavaMail, etc?
> 
> -Mike
> 
> On Mon, 2005-08-08 at 13:31 -0400, Peter Lin wrote:
> > right, but I would like to avoid asking users to download yet another
> > jar lib. seems like such  a hassle for users to have to go find the
> > jar file and download it.
> >
> > perhaps this would be better as a sourceforge project that just plugs
> > in to jmeter or reuses jmeter components.
> >
> > peter
> >
> >
> > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > I'm not saying we should not write code to use JCharts, just that we
> > > should not distribute the jar.
> > >
> > > For example, the BeanShell jar is optional, but the code exists to use it.
> > > Likewise we don't (can't) redistribute mail.jar and activation.jar.
> > >
> > > Needs a bit of care to ensure that the code behaves sensibly if the
> > > jar is missing at run-time, but otherwise is not all that difficult.
> > >
> > > Any JMeter code that uses JCharts should be in a separate jar if not
> > > application anyway.
> > >
> > > S.
> > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > in that case, would it be better to write our own chart/graph ?
> > > >
> > > >
> > > > peter
> > > >
> > > > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > > > I can't see any benefit of including JCharts in the JMeter zips or CVS
> > > > > - if people want to use it, they can download the jar for themselves,
> > > > > and be sure of getting the latest.
> > > > >
> > > > > We should just provide any necessary instructions, eg in the extras directory.
> > > > >
> > > > > S.
> > > > >
> > > > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > that's a good point. I didn't think that far. I suppose we can always
> > > > > > have 2 downloads:
> > > > > >
> > > > > > 1. jmeter normal
> > > > > > 2. jmeter with reporting
> > > > > >
> > > > > > of course, this assumes I do a decent job on the reporting component
> > > > > > and people actually want to use it. I think jcharts uses apache style
> > > > > > license, but I'll make sure.
> > > > > >
> > > > > > peter
> > > > > >
> > > > > >
> > > > > > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > > > > > Agreed we can't at present include LGPL jars in JMeter distributions.
> > > > > > >
> > > > > > > Even with JCharts, I wonder whether the jar should be included with
> > > > > > > JMeter, as not everyone will need the functionality.
> > > > > > >
> > > > > > > S.
> > > > > > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > > > Since JasperReports is LGPL, we can't really use it. I took a look
> > > > > > > > around and it looks like jcharts provides some good functionality.
> > > > > > > >
> > > > > > > > http://jcharts.sourceforge.net/
> > > > > > > >
> > > > > > > > I already started working on the GUI and framework part of it. Most of
> > > > > > > > the design tries to stay close to current JMeter design patterns and
> > > > > > > > conventions. I plan to check something into CVS HEAD at the end of the
> > > > > > > > week. Should I check it into the new Subversion instead?
> > > > > > > >
> > > > > > > > peter
> > > > > > > >
> > > > > > > >
> > > > > > > > On 8/4/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > > > > I was think to write/configure the report settings.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > peter
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > > > I'm not sure what the point of the gui is.  Although it's nice to show a
> > > > > > > > > > report gui, there are other tools for that.  I'm thinking these report
> > > > > > > > > > generators are essentially creating output for
> > > > > > > > > > excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> > > > > > > > > > gui in JMeter could assist to control command-line parameters to the
> > > > > > > > > > report generator, but that's it, IMO.
> > > > > > > > > >
> > > > > > > > > > I just don't want to get JMeter into the business of being report
> > > > > > > > > > viewing software.
> > > > > > > > > >
> > > > > > > > > > -Mike
> > > > > > > > > >
> > > > > > > > > > On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > > > > > > > > > > JCharts uses apache style license, so we can use that for the charts
> > > > > > > > > > > and graphs. in terms of reports, it might be nice to have a separate
> > > > > > > > > > > reporting GUI. Though I was thinking of taking the easy way out and
> > > > > > > > > > > have it be a normal jmeter plugin that loads in the same gui
> > > > > > > > > > >
> > > > > > > > > > > peter
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > > > > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Michael Stover <ms...@apache.org>]

Couldn't we have a page on the wiki or somewhere that provided a list of
links to the third-party jars JMeter can use optionally?  Maybe it's not
allowed to link directly to the jar file, but surely we can link to a
download page of BSF, BSH, JCharts, JSSE, JavaMail, etc?

-Mike

On Mon, 2005-08-08 at 13:31 -0400, Peter Lin wrote:
> right, but I would like to avoid asking users to download yet another
> jar lib. seems like such  a hassle for users to have to go find the
> jar file and download it.
> 
> perhaps this would be better as a sourceforge project that just plugs
> in to jmeter or reuses jmeter components.
> 
> peter
> 
> 
> On 8/8/05, sebb <se...@gmail.com> wrote:
> > I'm not saying we should not write code to use JCharts, just that we
> > should not distribute the jar.
> > 
> > For example, the BeanShell jar is optional, but the code exists to use it.
> > Likewise we don't (can't) redistribute mail.jar and activation.jar.
> > 
> > Needs a bit of care to ensure that the code behaves sensibly if the
> > jar is missing at run-time, but otherwise is not all that difficult.
> > 
> > Any JMeter code that uses JCharts should be in a separate jar if not
> > application anyway.
> > 
> > S.
> > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > in that case, would it be better to write our own chart/graph ?
> > >
> > >
> > > peter
> > >
> > > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > > I can't see any benefit of including JCharts in the JMeter zips or CVS
> > > > - if people want to use it, they can download the jar for themselves,
> > > > and be sure of getting the latest.
> > > >
> > > > We should just provide any necessary instructions, eg in the extras directory.
> > > >
> > > > S.
> > > >
> > > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > that's a good point. I didn't think that far. I suppose we can always
> > > > > have 2 downloads:
> > > > >
> > > > > 1. jmeter normal
> > > > > 2. jmeter with reporting
> > > > >
> > > > > of course, this assumes I do a decent job on the reporting component
> > > > > and people actually want to use it. I think jcharts uses apache style
> > > > > license, but I'll make sure.
> > > > >
> > > > > peter
> > > > >
> > > > >
> > > > > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > > > > Agreed we can't at present include LGPL jars in JMeter distributions.
> > > > > >
> > > > > > Even with JCharts, I wonder whether the jar should be included with
> > > > > > JMeter, as not everyone will need the functionality.
> > > > > >
> > > > > > S.
> > > > > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > > Since JasperReports is LGPL, we can't really use it. I took a look
> > > > > > > around and it looks like jcharts provides some good functionality.
> > > > > > >
> > > > > > > http://jcharts.sourceforge.net/
> > > > > > >
> > > > > > > I already started working on the GUI and framework part of it. Most of
> > > > > > > the design tries to stay close to current JMeter design patterns and
> > > > > > > conventions. I plan to check something into CVS HEAD at the end of the
> > > > > > > week. Should I check it into the new Subversion instead?
> > > > > > >
> > > > > > > peter
> > > > > > >
> > > > > > >
> > > > > > > On 8/4/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > > > I was think to write/configure the report settings.
> > > > > > > >
> > > > > > > >
> > > > > > > > peter
> > > > > > > >
> > > > > > > >
> > > > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > > I'm not sure what the point of the gui is.  Although it's nice to show a
> > > > > > > > > report gui, there are other tools for that.  I'm thinking these report
> > > > > > > > > generators are essentially creating output for
> > > > > > > > > excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> > > > > > > > > gui in JMeter could assist to control command-line parameters to the
> > > > > > > > > report generator, but that's it, IMO.
> > > > > > > > >
> > > > > > > > > I just don't want to get JMeter into the business of being report
> > > > > > > > > viewing software.
> > > > > > > > >
> > > > > > > > > -Mike
> > > > > > > > >
> > > > > > > > > On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > > > > > > > > > JCharts uses apache style license, so we can use that for the charts
> > > > > > > > > > and graphs. in terms of reports, it might be nice to have a separate
> > > > > > > > > > reporting GUI. Though I was thinking of taking the easy way out and
> > > > > > > > > > have it be a normal jmeter plugin that loads in the same gui
> > > > > > > > > >
> > > > > > > > > > peter
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > > > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

right, but I would like to avoid asking users to download yet another
jar lib. seems like such  a hassle for users to have to go find the
jar file and download it.

perhaps this would be better as a sourceforge project that just plugs
in to jmeter or reuses jmeter components.

peter


On 8/8/05, sebb <se...@gmail.com> wrote:
> I'm not saying we should not write code to use JCharts, just that we
> should not distribute the jar.
> 
> For example, the BeanShell jar is optional, but the code exists to use it.
> Likewise we don't (can't) redistribute mail.jar and activation.jar.
> 
> Needs a bit of care to ensure that the code behaves sensibly if the
> jar is missing at run-time, but otherwise is not all that difficult.
> 
> Any JMeter code that uses JCharts should be in a separate jar if not
> application anyway.
> 
> S.
> On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > in that case, would it be better to write our own chart/graph ?
> >
> >
> > peter
> >
> > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > I can't see any benefit of including JCharts in the JMeter zips or CVS
> > > - if people want to use it, they can download the jar for themselves,
> > > and be sure of getting the latest.
> > >
> > > We should just provide any necessary instructions, eg in the extras directory.
> > >
> > > S.
> > >
> > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > that's a good point. I didn't think that far. I suppose we can always
> > > > have 2 downloads:
> > > >
> > > > 1. jmeter normal
> > > > 2. jmeter with reporting
> > > >
> > > > of course, this assumes I do a decent job on the reporting component
> > > > and people actually want to use it. I think jcharts uses apache style
> > > > license, but I'll make sure.
> > > >
> > > > peter
> > > >
> > > >
> > > > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > > > Agreed we can't at present include LGPL jars in JMeter distributions.
> > > > >
> > > > > Even with JCharts, I wonder whether the jar should be included with
> > > > > JMeter, as not everyone will need the functionality.
> > > > >
> > > > > S.
> > > > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > Since JasperReports is LGPL, we can't really use it. I took a look
> > > > > > around and it looks like jcharts provides some good functionality.
> > > > > >
> > > > > > http://jcharts.sourceforge.net/
> > > > > >
> > > > > > I already started working on the GUI and framework part of it. Most of
> > > > > > the design tries to stay close to current JMeter design patterns and
> > > > > > conventions. I plan to check something into CVS HEAD at the end of the
> > > > > > week. Should I check it into the new Subversion instead?
> > > > > >
> > > > > > peter
> > > > > >
> > > > > >
> > > > > > On 8/4/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > > I was think to write/configure the report settings.
> > > > > > >
> > > > > > >
> > > > > > > peter
> > > > > > >
> > > > > > >
> > > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > I'm not sure what the point of the gui is.  Although it's nice to show a
> > > > > > > > report gui, there are other tools for that.  I'm thinking these report
> > > > > > > > generators are essentially creating output for
> > > > > > > > excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> > > > > > > > gui in JMeter could assist to control command-line parameters to the
> > > > > > > > report generator, but that's it, IMO.
> > > > > > > >
> > > > > > > > I just don't want to get JMeter into the business of being report
> > > > > > > > viewing software.
> > > > > > > >
> > > > > > > > -Mike
> > > > > > > >
> > > > > > > > On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > > > > > > > > JCharts uses apache style license, so we can use that for the charts
> > > > > > > > > and graphs. in terms of reports, it might be nice to have a separate
> > > > > > > > > reporting GUI. Though I was thinking of taking the easy way out and
> > > > > > > > > have it be a normal jmeter plugin that loads in the same gui
> > > > > > > > >
> > > > > > > > > peter
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[sebb <se...@gmail.com>]

I'm not saying we should not write code to use JCharts, just that we
should not distribute the jar.

For example, the BeanShell jar is optional, but the code exists to use it.
Likewise we don't (can't) redistribute mail.jar and activation.jar.

Needs a bit of care to ensure that the code behaves sensibly if the
jar is missing at run-time, but otherwise is not all that difficult.

Any JMeter code that uses JCharts should be in a separate jar if not
application anyway.

S.
On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> in that case, would it be better to write our own chart/graph ?
> 
> 
> peter
> 
> On 8/8/05, sebb <se...@gmail.com> wrote:
> > I can't see any benefit of including JCharts in the JMeter zips or CVS
> > - if people want to use it, they can download the jar for themselves,
> > and be sure of getting the latest.
> >
> > We should just provide any necessary instructions, eg in the extras directory.
> >
> > S.
> >
> > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > that's a good point. I didn't think that far. I suppose we can always
> > > have 2 downloads:
> > >
> > > 1. jmeter normal
> > > 2. jmeter with reporting
> > >
> > > of course, this assumes I do a decent job on the reporting component
> > > and people actually want to use it. I think jcharts uses apache style
> > > license, but I'll make sure.
> > >
> > > peter
> > >
> > >
> > > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > > Agreed we can't at present include LGPL jars in JMeter distributions.
> > > >
> > > > Even with JCharts, I wonder whether the jar should be included with
> > > > JMeter, as not everyone will need the functionality.
> > > >
> > > > S.
> > > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > Since JasperReports is LGPL, we can't really use it. I took a look
> > > > > around and it looks like jcharts provides some good functionality.
> > > > >
> > > > > http://jcharts.sourceforge.net/
> > > > >
> > > > > I already started working on the GUI and framework part of it. Most of
> > > > > the design tries to stay close to current JMeter design patterns and
> > > > > conventions. I plan to check something into CVS HEAD at the end of the
> > > > > week. Should I check it into the new Subversion instead?
> > > > >
> > > > > peter
> > > > >
> > > > >
> > > > > On 8/4/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > I was think to write/configure the report settings.
> > > > > >
> > > > > >
> > > > > > peter
> > > > > >
> > > > > >
> > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > I'm not sure what the point of the gui is.  Although it's nice to show a
> > > > > > > report gui, there are other tools for that.  I'm thinking these report
> > > > > > > generators are essentially creating output for
> > > > > > > excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> > > > > > > gui in JMeter could assist to control command-line parameters to the
> > > > > > > report generator, but that's it, IMO.
> > > > > > >
> > > > > > > I just don't want to get JMeter into the business of being report
> > > > > > > viewing software.
> > > > > > >
> > > > > > > -Mike
> > > > > > >
> > > > > > > On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > > > > > > > JCharts uses apache style license, so we can use that for the charts
> > > > > > > > and graphs. in terms of reports, it might be nice to have a separate
> > > > > > > > reporting GUI. Though I was thinking of taking the easy way out and
> > > > > > > > have it be a normal jmeter plugin that loads in the same gui
> > > > > > > >
> > > > > > > > peter
> > > > > > > >
> > > > > > > >
> > > > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

in that case, would it be better to write our own chart/graph ?


peter

On 8/8/05, sebb <se...@gmail.com> wrote:
> I can't see any benefit of including JCharts in the JMeter zips or CVS
> - if people want to use it, they can download the jar for themselves,
> and be sure of getting the latest.
> 
> We should just provide any necessary instructions, eg in the extras directory.
> 
> S.
> 
> On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > that's a good point. I didn't think that far. I suppose we can always
> > have 2 downloads:
> >
> > 1. jmeter normal
> > 2. jmeter with reporting
> >
> > of course, this assumes I do a decent job on the reporting component
> > and people actually want to use it. I think jcharts uses apache style
> > license, but I'll make sure.
> >
> > peter
> >
> >
> > On 8/8/05, sebb <se...@gmail.com> wrote:
> > > Agreed we can't at present include LGPL jars in JMeter distributions.
> > >
> > > Even with JCharts, I wonder whether the jar should be included with
> > > JMeter, as not everyone will need the functionality.
> > >
> > > S.
> > > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > > Since JasperReports is LGPL, we can't really use it. I took a look
> > > > around and it looks like jcharts provides some good functionality.
> > > >
> > > > http://jcharts.sourceforge.net/
> > > >
> > > > I already started working on the GUI and framework part of it. Most of
> > > > the design tries to stay close to current JMeter design patterns and
> > > > conventions. I plan to check something into CVS HEAD at the end of the
> > > > week. Should I check it into the new Subversion instead?
> > > >
> > > > peter
> > > >
> > > >
> > > > On 8/4/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > I was think to write/configure the report settings.
> > > > >
> > > > >
> > > > > peter
> > > > >
> > > > >
> > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > I'm not sure what the point of the gui is.  Although it's nice to show a
> > > > > > report gui, there are other tools for that.  I'm thinking these report
> > > > > > generators are essentially creating output for
> > > > > > excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> > > > > > gui in JMeter could assist to control command-line parameters to the
> > > > > > report generator, but that's it, IMO.
> > > > > >
> > > > > > I just don't want to get JMeter into the business of being report
> > > > > > viewing software.
> > > > > >
> > > > > > -Mike
> > > > > >
> > > > > > On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > > > > > > JCharts uses apache style license, so we can use that for the charts
> > > > > > > and graphs. in terms of reports, it might be nice to have a separate
> > > > > > > reporting GUI. Though I was thinking of taking the easy way out and
> > > > > > > have it be a normal jmeter plugin that loads in the same gui
> > > > > > >
> > > > > > > peter
> > > > > > >
> > > > > > >
> > > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[sebb <se...@gmail.com>]

I can't see any benefit of including JCharts in the JMeter zips or CVS
- if people want to use it, they can download the jar for themselves,
and be sure of getting the latest.

We should just provide any necessary instructions, eg in the extras directory.

S.

On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> that's a good point. I didn't think that far. I suppose we can always
> have 2 downloads:
> 
> 1. jmeter normal
> 2. jmeter with reporting
> 
> of course, this assumes I do a decent job on the reporting component
> and people actually want to use it. I think jcharts uses apache style
> license, but I'll make sure.
> 
> peter
> 
> 
> On 8/8/05, sebb <se...@gmail.com> wrote:
> > Agreed we can't at present include LGPL jars in JMeter distributions.
> >
> > Even with JCharts, I wonder whether the jar should be included with
> > JMeter, as not everyone will need the functionality.
> >
> > S.
> > On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > Since JasperReports is LGPL, we can't really use it. I took a look
> > > around and it looks like jcharts provides some good functionality.
> > >
> > > http://jcharts.sourceforge.net/
> > >
> > > I already started working on the GUI and framework part of it. Most of
> > > the design tries to stay close to current JMeter design patterns and
> > > conventions. I plan to check something into CVS HEAD at the end of the
> > > week. Should I check it into the new Subversion instead?
> > >
> > > peter
> > >
> > >
> > > On 8/4/05, Peter Lin <wo...@gmail.com> wrote:
> > > > I was think to write/configure the report settings.
> > > >
> > > >
> > > > peter
> > > >
> > > >
> > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > I'm not sure what the point of the gui is.  Although it's nice to show a
> > > > > report gui, there are other tools for that.  I'm thinking these report
> > > > > generators are essentially creating output for
> > > > > excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> > > > > gui in JMeter could assist to control command-line parameters to the
> > > > > report generator, but that's it, IMO.
> > > > >
> > > > > I just don't want to get JMeter into the business of being report
> > > > > viewing software.
> > > > >
> > > > > -Mike
> > > > >
> > > > > On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > > > > > JCharts uses apache style license, so we can use that for the charts
> > > > > > and graphs. in terms of reports, it might be nice to have a separate
> > > > > > reporting GUI. Though I was thinking of taking the easy way out and
> > > > > > have it be a normal jmeter plugin that loads in the same gui
> > > > > >
> > > > > > peter
> > > > > >
> > > > > >
> > > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

that's a good point. I didn't think that far. I suppose we can always
have 2 downloads:

1. jmeter normal
2. jmeter with reporting

of course, this assumes I do a decent job on the reporting component
and people actually want to use it. I think jcharts uses apache style
license, but I'll make sure.

peter


On 8/8/05, sebb <se...@gmail.com> wrote:
> Agreed we can't at present include LGPL jars in JMeter distributions.
> 
> Even with JCharts, I wonder whether the jar should be included with
> JMeter, as not everyone will need the functionality.
> 
> S.
> On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> > Since JasperReports is LGPL, we can't really use it. I took a look
> > around and it looks like jcharts provides some good functionality.
> >
> > http://jcharts.sourceforge.net/
> >
> > I already started working on the GUI and framework part of it. Most of
> > the design tries to stay close to current JMeter design patterns and
> > conventions. I plan to check something into CVS HEAD at the end of the
> > week. Should I check it into the new Subversion instead?
> >
> > peter
> >
> >
> > On 8/4/05, Peter Lin <wo...@gmail.com> wrote:
> > > I was think to write/configure the report settings.
> > >
> > >
> > > peter
> > >
> > >
> > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > I'm not sure what the point of the gui is.  Although it's nice to show a
> > > > report gui, there are other tools for that.  I'm thinking these report
> > > > generators are essentially creating output for
> > > > excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> > > > gui in JMeter could assist to control command-line parameters to the
> > > > report generator, but that's it, IMO.
> > > >
> > > > I just don't want to get JMeter into the business of being report
> > > > viewing software.
> > > >
> > > > -Mike
> > > >
> > > > On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > > > > JCharts uses apache style license, so we can use that for the charts
> > > > > and graphs. in terms of reports, it might be nice to have a separate
> > > > > reporting GUI. Though I was thinking of taking the easy way out and
> > > > > have it be a normal jmeter plugin that loads in the same gui
> > > > >
> > > > > peter
> > > > >
> > > > >
> > > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[sebb <se...@gmail.com>]

Agreed we can't at present include LGPL jars in JMeter distributions.

Even with JCharts, I wonder whether the jar should be included with
JMeter, as not everyone will need the functionality.

S.
On 08/08/05, Peter Lin <wo...@gmail.com> wrote:
> Since JasperReports is LGPL, we can't really use it. I took a look
> around and it looks like jcharts provides some good functionality.
> 
> http://jcharts.sourceforge.net/
> 
> I already started working on the GUI and framework part of it. Most of
> the design tries to stay close to current JMeter design patterns and
> conventions. I plan to check something into CVS HEAD at the end of the
> week. Should I check it into the new Subversion instead?
> 
> peter
> 
> 
> On 8/4/05, Peter Lin <wo...@gmail.com> wrote:
> > I was think to write/configure the report settings.
> >
> >
> > peter
> >
> >
> > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > I'm not sure what the point of the gui is.  Although it's nice to show a
> > > report gui, there are other tools for that.  I'm thinking these report
> > > generators are essentially creating output for
> > > excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> > > gui in JMeter could assist to control command-line parameters to the
> > > report generator, but that's it, IMO.
> > >
> > > I just don't want to get JMeter into the business of being report
> > > viewing software.
> > >
> > > -Mike
> > >
> > > On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > > > JCharts uses apache style license, so we can use that for the charts
> > > > and graphs. in terms of reports, it might be nice to have a separate
> > > > reporting GUI. Though I was thinking of taking the easy way out and
> > > > have it be a normal jmeter plugin that loads in the same gui
> > > >
> > > > peter
> > > >
> > > >
> > > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

Since JasperReports is LGPL, we can't really use it. I took a look
around and it looks like jcharts provides some good functionality.

http://jcharts.sourceforge.net/

I already started working on the GUI and framework part of it. Most of
the design tries to stay close to current JMeter design patterns and
conventions. I plan to check something into CVS HEAD at the end of the
week. Should I check it into the new Subversion instead?

peter


On 8/4/05, Peter Lin <wo...@gmail.com> wrote:
> I was think to write/configure the report settings.
> 
> 
> peter
> 
> 
> On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > I'm not sure what the point of the gui is.  Although it's nice to show a
> > report gui, there are other tools for that.  I'm thinking these report
> > generators are essentially creating output for
> > excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> > gui in JMeter could assist to control command-line parameters to the
> > report generator, but that's it, IMO.
> >
> > I just don't want to get JMeter into the business of being report
> > viewing software.
> >
> > -Mike
> >
> > On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > > JCharts uses apache style license, so we can use that for the charts
> > > and graphs. in terms of reports, it might be nice to have a separate
> > > reporting GUI. Though I was thinking of taking the easy way out and
> > > have it be a normal jmeter plugin that loads in the same gui
> > >
> > > peter
> > >
> > >
> > > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

I was think to write/configure the report settings.


peter


On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> I'm not sure what the point of the gui is.  Although it's nice to show a
> report gui, there are other tools for that.  I'm thinking these report
> generators are essentially creating output for
> excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
> gui in JMeter could assist to control command-line parameters to the
> report generator, but that's it, IMO.
> 
> I just don't want to get JMeter into the business of being report
> viewing software.
> 
> -Mike
> 
> On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> > JCharts uses apache style license, so we can use that for the charts
> > and graphs. in terms of reports, it might be nice to have a separate
> > reporting GUI. Though I was thinking of taking the easy way out and
> > have it be a normal jmeter plugin that loads in the same gui
> >
> > peter
> >
> >
> > On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Michael Stover <ms...@apache.org>]

I'm not sure what the point of the gui is.  Although it's nice to show a
report gui, there are other tools for that.  I'm thinking these report
generators are essentially creating output for
excel/staroffice/jasperreports/image viewers/etc - not for JMeter.  A
gui in JMeter could assist to control command-line parameters to the
report generator, but that's it, IMO.

I just don't want to get JMeter into the business of being report
viewing software.

-Mike

On Thu, 2005-08-04 at 13:44 -0400, Peter Lin wrote:
> JCharts uses apache style license, so we can use that for the charts
> and graphs. in terms of reports, it might be nice to have a separate
> reporting GUI. Though I was thinking of taking the easy way out and
> have it be a normal jmeter plugin that loads in the same gui
> 
> peter
> 
> 
> On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> > 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

JCharts uses apache style license, so we can use that for the charts
and graphs. in terms of reports, it might be nice to have a separate
reporting GUI. Though I was thinking of taking the easy way out and
have it be a normal jmeter plugin that loads in the same gui

peter


On 8/4/05, Michael Stover <ms...@apache.org> wrote:
> 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Joseph Fifield <jf...@programmerplanet.org>]

This would make more sense. As long as each component basically took a 
.jtl file and either wrote the report to disk or [if possible] display 
the report in a gui. That way each component could generate the report 
using the best strategy for that type of report. Maybe xslt for html 
reports, JRXmlDataSource for JasperReports, ? for charts. Of course, the 
csv formatted .jtl files still pose a problem (atleast for the examples 
given).

Joe

Michael Stover wrote:
> 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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Michael Stover <ms...@apache.org>]

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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

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 <jf...@programmerplanet.org> 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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Joseph Fifield <jf...@programmerplanet.org>]

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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

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 <se...@gmail.com> 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 <wo...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[sebb <se...@gmail.com>]

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 <wo...@gmail.com> 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
> 
> 
> On 8/4/05, sebb <se...@gmail.com> wrote:
> > There surely still needs to be a GUI to configure the Reporter?
> >
> > There is already a Listener that creates output to disk only - Simple
> > Data Writer.
> >
> > Would it not be simpler to extend the existing structure with new or
> > amended Listeners that write to disk rather than the screen?
> >
> > Not that I mind there being a Reporter component.
> >
> > S.
> > On 04/08/05, Peter Lin <wo...@gmail.com> wrote:
> > > Hey sebb,
> > >
> > > mike and I were just chatting about some enhancements to JMeter. I was
> > > thinking, it might be nice to be able to run jmeter in console mode
> > > and have it dump out graphs or statistics. My thought was to do the
> > > following.
> > >
> > > 1. create a new type of component called Report
> > > 2. there would be an Abstract class for it
> > > 3. it would behave similar to a listener, except minus the GUI part.
> > > 4. there would be two base output types: text and png
> > > 5. any statistics would be passed to the output type, which generates
> > > the file or image
> > >
> > >
> > > what do you think?
> > >
> > > peter
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Peter Lin <wo...@gmail.com>]

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


On 8/4/05, sebb <se...@gmail.com> wrote:
> There surely still needs to be a GUI to configure the Reporter?
> 
> There is already a Listener that creates output to disk only - Simple
> Data Writer.
> 
> Would it not be simpler to extend the existing structure with new or
> amended Listeners that write to disk rather than the screen?
> 
> Not that I mind there being a Reporter component.
> 
> S.
> On 04/08/05, Peter Lin <wo...@gmail.com> wrote:
> > Hey sebb,
> >
> > mike and I were just chatting about some enhancements to JMeter. I was
> > thinking, it might be nice to be able to run jmeter in console mode
> > and have it dump out graphs or statistics. My thought was to do the
> > following.
> >
> > 1. create a new type of component called Report
> > 2. there would be an Abstract class for it
> > 3. it would behave similar to a listener, except minus the GUI part.
> > 4. there would be two base output types: text and png
> > 5. any statistics would be passed to the output type, which generates
> > the file or image
> >
> >
> > what do you think?
> >
> > peter
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[sebb <se...@gmail.com>]

There surely still needs to be a GUI to configure the Reporter?

There is already a Listener that creates output to disk only - Simple
Data Writer.

Would it not be simpler to extend the existing structure with new or
amended Listeners that write to disk rather than the screen?

Not that I mind there being a Reporter component.

S.
On 04/08/05, Peter Lin <wo...@gmail.com> wrote:
> Hey sebb,
> 
> mike and I were just chatting about some enhancements to JMeter. I was
> thinking, it might be nice to be able to run jmeter in console mode
> and have it dump out graphs or statistics. My thought was to do the
> following.
> 
> 1. create a new type of component called Report
> 2. there would be an Abstract class for it
> 3. it would behave similar to a listener, except minus the GUI part.
> 4. there would be two base output types: text and png
> 5. any statistics would be passed to the output type, which generates
> the file or image
> 
> 
> what do you think?
> 
> peter
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: [Ehancement ideas]

[Tom Cunningham <cu...@mac.com>]

 
Peter,

I'd be interested in helping on this.   My main interest would be extending the abstract class to dump out to a reporting framework, like JasperReports.

--Tom

On Thursday, August 04, 2005, at 10:27AM, Peter Lin <wo...@gmail.com> wrote:

>Hey sebb,
>
>mike and I were just chatting about some enhancements to JMeter. I was
>thinking, it might be nice to be able to run jmeter in console mode
>and have it dump out graphs or statistics. My thought was to do the
>following.
>
>1. create a new type of component called Report
>2. there would be an Abstract class for it
>3. it would behave similar to a listener, except minus the GUI part.
>4. there would be two base output types: text and png
>5. any statistics would be passed to the output type, which generates
>the file or image
>
>
>what do you think?
>
>peter
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org