Re: [VOTE] Release Candidate JMeter 2.3 RC1 - abandoned
On 09/07/07, Dion Gillard [EMAIL PROTECTED] wrote: sebb, one of the things I find useful about the build process that httpd, Struts, Tomcat etc use is that it means anyone can do a build and then call for a vote on it's quality. If this process is streamlined enough, it means feedback can be extracted from people more often and issues discovered earlier. I know this isn't how things are done ATM with jakarta, but it's worth thinking about. I have been making regular nightly builds available, however it was only when I created a formal build and called for a vote that various issues surfaced. So yes, it could be useful in future. Do these quality check builds have to be tagged in SVN? Or can they just be built from the current code line? On 7/9/07, sebb [EMAIL PROTECTED] wrote: On 04/07/07, sebb [EMAIL PROTECTED] wrote: I've created JMeter 2.3 RC1 in the directory: http://people.apache.org/~sebb/jmeter-2.3/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3/site All feedback welcome. [ ]+1 - the release candidate looks OK, proceed with full release [ ]-1 - there is a problem (please indicate what it is) Various problems have been found in the release, so I won't be proceeding with it. Thanks for all the feedback so far, which has been very useful. I have been able to fix most of the reported problems, but there are still some outstanding. sebb AT apache DOT org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dIon Gillard Rule #131 of Acquisition: Information is Profit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Candidate JMeter 2.3 RC1 - abandoned
From looking at Struts SVN, I'm guessing that they're built and then tagged from a revision of trunk and then that tag is voted on for quality. Maybe one of the Struts/Tomcat committers can explain how they do it? Ted, Don? On 7/9/07, sebb [EMAIL PROTECTED] wrote: On 09/07/07, Dion Gillard [EMAIL PROTECTED] wrote: sebb, one of the things I find useful about the build process that httpd, Struts, Tomcat etc use is that it means anyone can do a build and then call for a vote on it's quality. If this process is streamlined enough, it means feedback can be extracted from people more often and issues discovered earlier. I know this isn't how things are done ATM with jakarta, but it's worth thinking about. I have been making regular nightly builds available, however it was only when I created a formal build and called for a vote that various issues surfaced. So yes, it could be useful in future. Do these quality check builds have to be tagged in SVN? Or can they just be built from the current code line? On 7/9/07, sebb [EMAIL PROTECTED] wrote: On 04/07/07, sebb [EMAIL PROTECTED] wrote: I've created JMeter 2.3 RC1 in the directory: http://people.apache.org/~sebb/jmeter-2.3/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3/site All feedback welcome. [ ]+1 - the release candidate looks OK, proceed with full release [ ]-1 - there is a problem (please indicate what it is) Various problems have been found in the release, so I won't be proceeding with it. Thanks for all the feedback so far, which has been very useful. I have been able to fix most of the reported problems, but there are still some outstanding. sebb AT apache DOT org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dIon Gillard Rule #131 of Acquisition: Information is Profit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dIon Gillard Rule #131 of Acquisition: Information is Profit.
Re: [VOTE] Release Candidate JMeter 2.3 RC1 - abandoned
Dion Gillard wrote: From looking at Struts SVN, I'm guessing that they're built and then tagged from a revision of trunk and then that tag is voted on for quality. Maybe one of the Struts/Tomcat committers can explain how they do it? In Tomcat the committers agree on a release date the corresponding code is tagged binaries and source packages are prepared and made available for download. People are asked to vote: For example, the x.y.z tag is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable After the vote the release is announced. (Normally Stable is what we want to reach and announce). Cheers Jean-Frederic Ted, Don? On 7/9/07, sebb [EMAIL PROTECTED] wrote: On 09/07/07, Dion Gillard [EMAIL PROTECTED] wrote: sebb, one of the things I find useful about the build process that httpd, Struts, Tomcat etc use is that it means anyone can do a build and then call for a vote on it's quality. If this process is streamlined enough, it means feedback can be extracted from people more often and issues discovered earlier. I know this isn't how things are done ATM with jakarta, but it's worth thinking about. I have been making regular nightly builds available, however it was only when I created a formal build and called for a vote that various issues surfaced. So yes, it could be useful in future. Do these quality check builds have to be tagged in SVN? Or can they just be built from the current code line? On 7/9/07, sebb [EMAIL PROTECTED] wrote: On 04/07/07, sebb [EMAIL PROTECTED] wrote: I've created JMeter 2.3 RC1 in the directory: http://people.apache.org/~sebb/jmeter-2.3/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3/site All feedback welcome. [ ]+1 - the release candidate looks OK, proceed with full release [ ]-1 - there is a problem (please indicate what it is) Various problems have been found in the release, so I won't be proceeding with it. Thanks for all the feedback so far, which has been very useful. I have been able to fix most of the reported problems, but there are still some outstanding. sebb AT apache DOT org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dIon Gillard Rule #131 of Acquisition: Information is Profit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Candidate JMeter 2.3 RC3
Following on from the helpful feedback on RC1, I've now created JMeter 2.3 RC3 in the directory: http://people.apache.org/~sebb/jmeter-2.3/dist Site documentation is here: http://people.apache.org/~sebb/jmeter-2.3/site It should now build and test OK on Unix (and in non-English Locales). [Please note that the 2 BeanShell tests require the optional beanshell jar to be downloaded from www.beanshell.org and put in the lib/opt directory.] All feedback welcome. [ ]+1 - the release candidate looks OK, proceed with releasing it [ ]-1 - there is a problem (please indicate what it is) There have been quite a few major updates since 2.2, so I think it would be prudent to release 2.3 initially as a release candidate; a full release can follow in a month or so. sebb AT apache DOT org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Candidate JMeter 2.3 RC3
On 09/07/07, sebb [EMAIL PROTECTED] wrote: Following on from the helpful feedback on RC1, I've now created JMeter 2.3 RC3 in the directory: http://people.apache.org/~sebb/jmeter-2.3/dist Site documentation is here: http://people.apache.org/~sebb/jmeter-2.3/site It should now build and test OK on Unix (and in non-English Locales). [Please note that the 2 BeanShell tests require the optional beanshell jar to be downloaded from www.beanshell.org and put in the lib/opt directory.] All feedback welcome. [ ]+1 - the release candidate looks OK, proceed with releasing it Here's my +1 [ ]-1 - there is a problem (please indicate what it is) There have been quite a few major updates since 2.2, so I think it would be prudent to release 2.3 initially as a release candidate; a full release can follow in a month or so. sebb AT apache DOT org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Candidate JMeter 2.3 RC3
Hi Sebastian, sebb wrote: Following on from the helpful feedback on RC1, I've now created JMeter 2.3 RC3 in the directory: http://people.apache.org/~sebb/jmeter-2.3/dist Site documentation is here: http://people.apache.org/~sebb/jmeter-2.3/site It should now build and test OK on Unix (and in non-English Locales). [Please note that the 2 BeanShell tests require the optional beanshell jar to be downloaded from www.beanshell.org and put in the lib/opt directory.] All feedback welcome. [ ]+1 - the release candidate looks OK, proceed with releasing it [ ]-1 - there is a problem (please indicate what it is) There have been quite a few major updates since 2.2, so I think it would be prudent to release 2.3 initially as a release candidate; a full release can follow in a month or so. sebb AT apache DOT org After using the offical bsh-2.0-beta-4.jar from the website (and not the one provided by Gentoo) the tests run much better. I build now RC3 with my complete compiler zoo, running ant all test. One strange error is always present: The ClassFinder detects 72 TestCase classes, but 1 cannot be instantiated: = % [java] Creating test suite [java] Scanning /home/joehni/java/jakarta-jmeter-2.3RC3/build/test,../lib/ext for test cases [java] ClassFinder found: 72 TestCase classes [java] INFO: JMeterGUIComponent: skipping some tests org.apache.jmeter.testbeans.gui.TestBeanGUI [java] Error adding test for class org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer java.lang.ClassCastException: org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer$1 [java] Created: 71 tests including 5 suites [java] Starting test run, test count = 1286 = % Apart from this following JDKs run all the tests fine: - Blackdown 1.4.2_03 - Sun JDK 1.5.0_12 - Sun JDK 1.6.0_01 These JDKs failed: - IBM JDK 1.4.2_08 with = % [java] There were 4 failures: [java] 1) testAssertionBadXSDFile(org.apache.jmeter.assertions.XMLSchemaAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XMLSchemaAssertionTest.testAssertionBadXSDFile(XMLSchemaAssertionTest.java:107) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] 2) testAssertionBlankResult(org.apache.jmeter.assertions.XMLSchemaAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XMLSchemaAssertionTest.testAssertionBlankResult(XMLSchemaAssertionTest.java:151) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] 3) testXMLTrailingcontent(org.apache.jmeter.assertions.XMLSchemaAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XMLSchemaAssertionTest.testXMLTrailingcontent(XMLSchemaAssertionTest.java:164) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] 4) testAssertionBlankResult(org.apache.jmeter.assertions.XPathAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XPathAssertionTest.testAssertionBlankResult(XPathAssertionTest.java:183) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] [java] FAILURES!!! [java] Tests run: 1286, Failures: 4,
Re: [VOTE] Release Candidate JMeter 2.3 RC3
On 09/07/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Sebastian, sebb wrote: Following on from the helpful feedback on RC1, I've now created JMeter 2.3 RC3 in the directory: http://people.apache.org/~sebb/jmeter-2.3/dist Site documentation is here: http://people.apache.org/~sebb/jmeter-2.3/site It should now build and test OK on Unix (and in non-English Locales). [Please note that the 2 BeanShell tests require the optional beanshell jar to be downloaded from www.beanshell.org and put in the lib/opt directory.] All feedback welcome. [ ]+1 - the release candidate looks OK, proceed with releasing it [ ]-1 - there is a problem (please indicate what it is) There have been quite a few major updates since 2.2, so I think it would be prudent to release 2.3 initially as a release candidate; a full release can follow in a month or so. sebb AT apache DOT org After using the offical bsh-2.0-beta-4.jar from the website (and not the one provided by Gentoo) the tests run much better. I build now RC3 with my complete compiler zoo, running ant all test. Glad that's sorted. One strange error is always present: The ClassFinder detects 72 TestCase classes, but 1 cannot be instantiated: = % [java] Creating test suite [java] Scanning /home/joehni/java/jakarta-jmeter-2.3RC3/build/test,../lib/ext for test cases [java] ClassFinder found: 72 TestCase classes [java] INFO: JMeterGUIComponent: skipping some tests org.apache.jmeter.testbeans.gui.TestBeanGUI [java] Error adding test for class org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer java.lang.ClassCastException: org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer$1 I changed the test recently to use a one-time TestSetup - this returns a Test, not a TestSuite. The changed test worked fine in Eclipse, but I see now that it does not work in Ant - unfortunately I overlooked that line in the output ... instead of prining a message, perhaps I should add a dummy test that is bound to fail. Thanks for finding it. [java] Created: 71 tests including 5 suites [java] Starting test run, test count = 1286 = % Apart from this following JDKs run all the tests fine: - Blackdown 1.4.2_03 - Sun JDK 1.5.0_12 - Sun JDK 1.6.0_01 Good. These JDKs failed: - IBM JDK 1.4.2_08 with = % [java] There were 4 failures: [java] 1) testAssertionBadXSDFile(org.apache.jmeter.assertions.XMLSchemaAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XMLSchemaAssertionTest.testAssertionBadXSDFile(XMLSchemaAssertionTest.java:107) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] 2) testAssertionBlankResult(org.apache.jmeter.assertions.XMLSchemaAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XMLSchemaAssertionTest.testAssertionBlankResult(XMLSchemaAssertionTest.java:151) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] 3) testXMLTrailingcontent(org.apache.jmeter.assertions.XMLSchemaAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XMLSchemaAssertionTest.testXMLTrailingcontent(XMLSchemaAssertionTest.java:164) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] 4) testAssertionBlankResult(org.apache.jmeter.assertions.XPathAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XPathAssertionTest.testAssertionBlankResult(XPathAssertionTest.java:183) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at
