Re: [VOTE] Release JMeter 2.5 RC1
On 2 August 2011 14:05, sebb seb...@gmail.com wrote: On 1 August 2011 06:46, Stefan Bodewig bode...@apache.org wrote: On 2011-08-01, Milamber wrote: The first release candidate for JMeter 2.5 has been prepared, and your votes are solicited. I haven't performed any sort of test, not even tried to build JMeter. * hashes and sigs are fine * source tarball and svn tag differ in some ways, some minor like no checkstyle.xml in the source archive but at least one that might be significant: We ought to include checkstyle.xml in the source archive - I think that must be new since 2.4. I see that Milamber has fixed that. diff -ur v2_5_RC1/src/core/org/apache/jmeter/util/JMeterVersion.java jakarta-jmeter-2.5/src/core/org/apache/jmeter/util/JMeterVersion.java --- v2_5_RC1/src/core/org/apache/jmeter/util/JMeterVersion.java 2011-08-01 07:26:20.174097342 +0200 +++ jakarta-jmeter-2.5/src/core/org/apache/jmeter/util/JMeterVersion.java 2011-08-01 01:18:26.0 +0200 @@ -44,7 +44,7 @@ * This ensures that JMeterUtils always gets the correct * version, even if JMeterUtils is not re-compiled during the build. */ - private static final String VERSION = 2.5; + private static final String VERSION = 2.5 r1152655; For me this is not big enough to cast a negative vote, this really depends on how closely the JMeter devs want the tag and the released code to match. This is tricky. The idea is that the displayed version includes the SVN revision number from which the binary was built. The file would need to be updated when creating the tag so it gets the same id as the tag. The existing post-tag update phase could be changed to check that the correct rev number had been included. I'll see if I can get this working, but it may take a while as I don't have access to my normal build PC at present. Looks like it can be made to work. The procedure that worked for me was: Update the file containing the $Revision keyword. It's not sufficient to edit the text within the keywork field, as SVN does not consider that to be an update. Probably the easiest would be to add the current date as a comment to the version file. The SVN tag can then be created using svn copy from the workspace. See my test commit: URL: http://svn.apache.org/viewvc?rev=1153135view=rev Log: Test tag / keyword creation There's a bit more work still needed to incorporate this into the JMeter build process. For example, the keyword expansion produces $Revision: 1153135 $, but ideally we only want the revision number. I can make a start on this. * in addition the source distribution is missing the docs subdirectory. Is this intentional? The docs subdirectory is generated from xdocs, so is not needed in the source archive. It's only stored in SVN for use when updating the website. * RAT only flags some testfiles, which is good enough for me * NOTICE should contain 2011 rather than 2010 Good point; needs to be fixed. I see Milamber has done that too. * ApacheJMeter.jar should probably not contain the tird party notice and licenses but only the ASF ones as the files inside the jar only apply to the jar and not the binary distribution. No biggy for me. Probably should be fixed. Not a +1, yet. Stefan - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.5 RC1
Le 02/08/2011 13:05, sebb a ecrit : * ApacheJMeter.jar should probably not contain the tird party notice and licenses but only the ASF ones as the files inside the jar only apply to the jar and not the binary distribution. No biggy for me. Probably should be fixed. For next RC2, I can fix this? Milamber - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.5 RC1
On 2 August 2011 19:53, Milamber milam...@apache.org wrote: Le 02/08/2011 13:05, sebb a ecrit : * ApacheJMeter.jar should probably not contain the tird party notice and licenses but only the ASF ones as the files inside the jar only apply to the jar and not the binary distribution. No biggy for me. Probably should be fixed. For next RC2, I can fix this? Presumably all the JMeter*.jar files should just contain the standard NOTICE header; only the binary archive needs the additional details of the other code. Ditto for the LICENSE file. Milamber - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter][RFC] JMeter report generator based on JAMon
Hi Sebastian, see my comments below Cheers, Siegfried Goeschl On 25.07.11 16:11, sebb wrote: On 25 July 2011 14:14, Siegfried Goeschlsiegfried.goes...@it20one.at wrote: Hi Sebastian, a few clarifications +) the JMeter report is consumed by a STAX parser so this is basically a post-processor of the JTL file JMeter already contains code to analyse JT:L files - might be better to use that, as any changes to the format will be handled by JMeter. since I don't know the JMeter code base where can I find the code to parser a JTL file? +) the label and response time of the HTTP invocation is fed into JAMon +) with a bit of manual code the underlying JAMon data model is written to a HTML file So you are only using the JAMon data model, is that correct? JMeter also contains code to do summarising and various other statistical analyses for the GUI Listeners. IMHO not good enough because I need the fulfill SLA's and require mapping response times into intervals as shown in the Page Detail Table section. +) currently there is no way to customize the output I also played with CSV output but it is not significantly faster than XML in my case but I will re-check. CSV output will be much smaller and is less expensive at run-time. It's also easier to parse - and again, JMeter has the code to parse the file. Not sure about it but I think the XML output is the way to go because I dump request and response on errors ... Cheers, Siegfried Goeschl On 25.07.11 14:25, sebb wrote: On 24 July 2011 15:19, Siegfried Goeschlsiegfried.goes...@it20one.at wrote: Hi folks, I'm using JMeter for some large-scale performance tests and had problems with the current approach of using XSLT to generate the HTML report since my JTL files exceed two gigabytes. Therefore I implemented a new reporting backend based on JAMon (see http://jamonapi.sourceforge.net/) Code : https://github.com/sgoeschl/jmeter-sla-report Sample Report : http://people.apache.org/~sgoeschl/download/jmeter/summary-report.html If this is of general interest I would like to contribute the code - please note that +) JAMon is under BSD licence +) the latest JAMon libraries are currently not available at Maven Central Feedback appreciated I'm a bit unclear on how JAMon is being used. It looks to me like JAMon is a monitoring system, rather than a reporting system, so how much of the JAMon code is really being used? Also, how easy is it to customise the output? == By the way, for long-running tests, it's a lot more efficient to use CSV output instead of XML. CSV does not support all the possible data types that XML does, but the additional fields in XML are not normally needed for reports. Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
