Re: [VOTE] Move Jakarta to the Attic; close down Jakarta PMC
+1 Oleg On Thu, 2011-11-10 at 10:01 -0800, Henri Yandell wrote: A joint vote to retire Jakarta into the Attic and to ask the board to close down the PMC. [ ] +1 [ ] -1, because Hen - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Apache JMeter TLP
[x] +1, its time for an Apache JMeter TLP On Thu, 2011-10-13 at 14:04 -0400, Rahul Akolkar wrote: [This vote is being held on dev@jakarta, please reply there. This message is being sent to multiple lists to make sure most at Jakarta are informed.] This is a vote for proposing an Apache JMeter TLP resolution to the board, with sebb nominated as the first Chair. The full text appears below [1] and is also on the wiki [2]. Vote will remain open for atleast 72 hours. 8 [ ] +1, its time for an Apache JMeter TLP [ ] +/- 0 [ ] -1, because ... 8 Cheers, -Rahul [1] Establish the Apache JMeter Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a Java desktop application designed to load test functional behavior and measure performance, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache JMeter Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache JMeter Project be and hereby is responsible for the creation and maintenance of software that provides a Java desktop application designed to load test functional behavior and measure performance; and be it further RESOLVED, that the office of Vice President, Apache JMeter be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache JMeter Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache JMeter Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache JMeter Project: * Sebastian Bazley (sebb AT a.o) * Milamber (milamber AT a.o) * Peter Lin (woolfel AT a.o) * Henri Yandell (bayard AT a.o) * Rahul Akolkar (rahul AT a.o) * Oleg Kalnichevski (olegk AT a.o) * Rainer Jung (rjung AT a.o) * Philippe Mouawad (pmouawad AT a.o) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Sebastian Bazley be appointed to the office of Vice President, Apache JMeter, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache JMeter PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache JMeter Project; and be it further RESOLVED, that the Apache JMeter Project be and hereby is tasked with the migration and rationalization of the Apache Jakarta JMeter sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Jakarta JMeter sub-project encumbered upon the Apache Jakarta Project are hereafter discharged. [2] http://wiki.apache.org/jakarta/TLPJMeter (version 7 of wiki page) - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.5.1 RC3
On Mon, 2011-10-03 at 10:03 +0100, sebb wrote: On 29 September 2011 00:52, Milamber milam...@apache.org wrote: Hello, The third release candidate for JMeter 2.5.1 has been prepared, and your votes are solicited. This release fixes mainly some bugs appeared since JMeter 2.5, and contains few improvements. Tests (load tests and/or functional tests) with JVM 5/6/7 on Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient 4.1 request, Http request with parallels embedded resources, View results tree, WebServices (SOAP) request, Async sample sending mode, etc.) List of changes: http://people.apache.org/~milamber/jmeter-2.5.1RC3/docs/changes.html I hope that this 3rd RC will corrects all majors bugs. *I would like send special congratulations for Philippe M. and Sebb for their work and their improving the future version of JMeter. Thanks.* JMeter is a Java desktop application designed to load test functional behavior and measure performance. The current version is targeted at Java 1.5+. Archives/hashes/sigs and RAT report: http://people.apache.org/~milamber/jmeter-2.5.1RC3/dist MD5 hashes of archives for this vote: e72f17c352fa4d3469d042e6542dd36d *jakarta-jmeter-2.5.1.tgz 2ed9e7ef8c225a416fd58de1124b7242 *jakarta-jmeter-2.5.1.zip 7423d3eebbdf11c28b3aebcd8ed2e78a *jakarta-jmeter-2.5.1_src.tgz 2b5ab9e599ac08880f85f61dab899a53 *jakarta-jmeter-2.5.1_src.zip Site Docs are here: http://people.apache.org/~milamber/jmeter-2.5.1RC3/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC3 (r1176908) Keys are here: http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/ also http://people.apache.org/~milamber/ N.B. To download the dependencies: ant download_jars To create the jars and test JMeter: ant package test. JMeter 2.5 requires Java 1.5 or later. Note that there is a bug in Java on some Linux systems that manifests itself as the following error when running the test cases or JMeter itself: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number This does not affect JMeter operation. All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and rename the RC tag as the release tag. Thanks in advance! Milamber The 72 hours are up. Although some additional bugs have surfaced, as far as I know these aren't regressions, so users are no worse off running 2.5.1, and in many respects it is better than 2.5. Therefore I think we should continue with the release. However, the known bugs section does not mention Bug 51918 and Bug 51919 so we should probably mention those in the announcement. Something like: Version 2.5 introduced a concurrent download feature for embedded HTML resources. Unfortunately this may result in corrupted downloads or other errors (bugs 51918 and 51919). We will fix these bugs as soon as possible; meanwhile the feature should not be used. OK? Works for me. Oleg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.5.1 RC3
[x] +1 I support this release On Wed, 2011-09-28 at 23:52 +, Milamber wrote: Hello, The third release candidate for JMeter 2.5.1 has been prepared, and your votes are solicited. This release fixes mainly some bugs appeared since JMeter 2.5, and contains few improvements. Tests (load tests and/or functional tests) with JVM 5/6/7 on Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient 4.1 request, Http request with parallels embedded resources, View results tree, WebServices (SOAP) request, Async sample sending mode, etc.) List of changes: http://people.apache.org/~milamber/jmeter-2.5.1RC3/docs/changes.html I hope that this 3rd RC will corrects all majors bugs. *I would like send special congratulations for Philippe M. and Sebb for their work and their improving the future version of JMeter. Thanks.* JMeter is a Java desktop application designed to load test functional behavior and measure performance. The current version is targeted at Java 1.5+. Archives/hashes/sigs and RAT report: http://people.apache.org/~milamber/jmeter-2.5.1RC3/dist MD5 hashes of archives for this vote: e72f17c352fa4d3469d042e6542dd36d *jakarta-jmeter-2.5.1.tgz 2ed9e7ef8c225a416fd58de1124b7242 *jakarta-jmeter-2.5.1.zip 7423d3eebbdf11c28b3aebcd8ed2e78a *jakarta-jmeter-2.5.1_src.tgz 2b5ab9e599ac08880f85f61dab899a53 *jakarta-jmeter-2.5.1_src.zip Site Docs are here: http://people.apache.org/~milamber/jmeter-2.5.1RC3/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC3 (r1176908) Keys are here: http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/ also http://people.apache.org/~milamber/ N.B. To download the dependencies: ant download_jars To create the jars and test JMeter: ant package test. JMeter 2.5 requires Java 1.5 or later. Note that there is a bug in Java on some Linux systems that manifests itself as the following error when running the test cases or JMeter itself: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number This does not affect JMeter operation. All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and rename the RC tag as the release tag. Thanks in advance! Milamber - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.5.1 RC2
On Sun, 2011-09-25 at 12:01 +, Milamber wrote: Hello, The second release candidate for JMeter 2.5.1 has been prepared, and your votes are solicited. This release fixes mainly some bugs appeared since JMeter 2.5, but contains few improvements. Tests (load tests or functional tests) with JVM 5/6/7 on Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient 4.1 request, Http request with parallels embedded resources, View results tree, WebServices (SOAP) request, Async sample sending mode, etc) List of changes: http://people.apache.org/~milamber/jmeter-2.5.1RC2/docs/changes.html JMeter is a Java desktop application designed to load test functional behavior and measure performance. The current version is targeted at Java 1.5+. Archives/hashes/sigs and RAT report: http://people.apache.org/~milamber/jmeter-2.5.1RC2/dist MD5 hashes of archives for this vote: abc0d327d19f3e138955de5082c000b3 *jakarta-jmeter-2.5.1.tgz 3e69786253880a1293e245519cba4ad3 *jakarta-jmeter-2.5.1.zip cdc73f4db83dee52d216c74c2a323721 *jakarta-jmeter-2.5.1_src.tgz 3f294979e6c696bba91d62c2ec5f0473 *jakarta-jmeter-2.5.1_src.zip Site Docs are here: http://people.apache.org/~milamber/jmeter-2.5.1RC2/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC2 (r1175373) Keys are here: http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/ also http://people.apache.org/~milamber/ N.B. To download the dependencies: ant download_jars To create the jars and test JMeter: ant package test. JMeter 2.5 requires Java 1.5 or later. Note that there is a bug in Java on some Linux systems that manifests itself as the following error when running the test cases or JMeter itself: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number This does not affect JMeter operation. All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and rename the RC tag as the release tag. Thanks in advance! Milamber I am seeing this error while trying to get all requisite dependencies with 'ant download_jars' _get_jarfile: _get_zipfile: [get] Getting: http://prdownloads.sourceforge.net/htmlparser/HTMLParser-2.0-SNAPSHOT-bin.zip [get] To: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build/HTMLParser-2.0-SNAPSHOT-bin.zip [get] Not modified - so not downloaded BUILD FAILED /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2202: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2172: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2064: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2093: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2101: The unwar type doesn't support the nested mapper element. Is this a common issue? Oleg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.5.1 RC2
On Mon, 2011-09-26 at 21:00 +0100, sebb wrote: ... I am seeing this error while trying to get all requisite dependencies with 'ant download_jars' _get_jarfile: _get_zipfile: [get] Getting: http://prdownloads.sourceforge.net/htmlparser/HTMLParser-2.0-SNAPSHOT-bin.zip [get] To: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build/HTMLParser-2.0-SNAPSHOT-bin.zip [get] Not modified - so not downloaded BUILD FAILED /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2202: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2172: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2064: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2093: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2101: The unwar type doesn't support the nested mapper element. Is this a common issue? Not seen it before. What version of Ant are you using? Good call. Problem solved by upgrading to Ant 1.8.2 Now I am getting a batchtest failure. I guess this has something to do with my network configuration. I am not sure how severe this failure is. Otherwise, building from source worked and all unit tests passed for me. batchtest: [echo] Starting BatchTestLocal using -X [jmeter] Created the tree successfully using testfiles/BatchTestLocal.jmx [jmeter] Starting the test @ Mon Sep 26 22:32:52 CEST 2011 (1317069172892) [jmeter] Waiting for possible shutdown message on port 4445 [jmeter] Tidying up ...@ Mon Sep 26 22:33:28 CEST 2011 (1317069208987) [jmeter] ... end of run [echo] BatchTestLocal output files compared OK batchtestserver: [server] Created remote object: UnicastServerRef [liveRef: [endpoint:[127.0.1.1:36010](local),objID:[6b66acdf:132a7714332:-7fff, -2840269162966433815]]] [server] An error occurred: Cannot start. ubuntu is a loopback address. [server] Server failed to start: java.rmi.RemoteException: Cannot start. ubuntu is a loopback address. batchtest: [echo] Starting BatchTestLocal using -Rlocalhost:2099 [server] Java Result: 1 [client] Created the tree successfully using testfiles/BatchTestLocal.jmx [client] Configuring remote engine for localhost:2099 [client] Failed to configure localhost:2099 [client] No remote engines were started. [client] Failure connecting to remote host: localhost:2099 java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: [client] java.net.ConnectException: Connection refused [echo] BatchTestLocal output files compared OK - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.5.1 RC2
On Mon, 2011-09-26 at 22:25 +0100, sebb wrote: On 26 September 2011 21:45, Oleg Kalnichevski ol...@apache.org wrote: On Mon, 2011-09-26 at 21:00 +0100, sebb wrote: ... I am seeing this error while trying to get all requisite dependencies with 'ant download_jars' _get_jarfile: _get_zipfile: [get] Getting: http://prdownloads.sourceforge.net/htmlparser/HTMLParser-2.0-SNAPSHOT-bin.zip [get] To: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build/HTMLParser-2.0-SNAPSHOT-bin.zip [get] Not modified - so not downloaded BUILD FAILED /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2202: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2172: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2064: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2093: The following error occurred while executing this line: /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2101: The unwar type doesn't support the nested mapper element. Is this a common issue? Not seen it before. What version of Ant are you using? Good call. Problem solved by upgrading to Ant 1.8.2 Good - what were you using? It might make sense for the Ant script to check for a minimum version. It was using ant 1.6.3 prior to upgrading to the latest version. Now I am getting a batchtest failure. I guess this has something to do with my network configuration. I am not sure how severe this failure is. Yes, it looks like the default host name ubuntu is being resolved as a loopback address. This causes problems for client-server mode. Though client-server mode would probably work for the unit test, it would not work if the client and server were on different nodes, so the server refuses to start. I'll try and tweak my network settings. Oleg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: Activity of Jakarta subprojects
On Fri, 2011-08-05 at 20:50 -0400, Rahul Akolkar wrote: On Sat, Jul 23, 2011 at 10:50 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Sat, Jul 23, 2011 at 3:39 PM, Oleg Kalnichevski ol...@apache.org wrote: ... * JMeter: Lots of activity. New committer in 2010. This should go TLP. There are two obvious members of a JMeter PMC present (sebb and milamber). Reality is that Jakarta=JMeter now, so hopefully there are other interested parties who simply aren't active. Or perhaps join HttpComonents? I think the charter allows for this, and the main use of JMeter is for HTTP testing (though of course it encompasses many other protocols). The charter can be amended if needed. There is a lot of overlap between JMeter and HttpComponents. Cool, so next step -- either of you (sebb/olegk) want to check with the HttpComponents PMC if there is consensus on that? snip/ Don't see anything on above in hc archives, unless I missed it. Want me to broach the topic ;-? -Rahul Rahul Taking JMeter to HC should be the latest resort, only if JMeter is unable to gather enough support to become a TLP of its own. A possibility of JMeter going TLP should be discussed first, in my opinion. Oleg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Cactus to the Attic
[x] +1, G'night Cactus On Sat, 2011-07-23 at 11:25 -0700, Henri Yandell wrote: Proposing this as a challenge vote (i.e. if no one has a good -1 against something moving to the attic, it's a sign it should go to the attic). [ ] +1, G'night Cactus [ ] -1, No because: There's no activity in the project and I think it would be best to recognize the reality and call it a day. Hen - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: Activity of Jakarta subprojects
... * JMeter: Lots of activity. New committer in 2010. This should go TLP. There are two obvious members of a JMeter PMC present (sebb and milamber). Reality is that Jakarta=JMeter now, so hopefully there are other interested parties who simply aren't active. Or perhaps join HttpComonents? I think the charter allows for this, and the main use of JMeter is for HTTP testing (though of course it encompasses many other protocols). The charter can be amended if needed. There is a lot of overlap between JMeter and HttpComponents. Oleg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.3.3 based on RC2
+1 Oleg sebb wrote: The second release candidate for JMeter 2.3.3 has been prepared, and your votes are again solicited. JMeter is a Java desktop application designed to load test functional behavior and measure performance. The current version is targetted at Java 1.4+. There were some build/test problems reported with the previous release candidate, so a new version has been built. This fixes: * the I18N problems reported when testing using a French locale * a compiler warning re: illegal UTF-8 characters * a test timing issue Some documentation tweaks were also added. Archives/hashes/sigs and RAT report: http://people.apache.org/~sebb/jmeter-2.3.3RC2/dist MD5 hashes of archives for this vote: f93fd88b4d91b37934233a2d9c038867 *jakarta-jmeter-2.3.3.tgz 333c4f6a9123929db22408c3d679673e *jakarta-jmeter-2.3.3.zip f71a012e2f22a333250e08011310f897 *jakarta-jmeter-2.3.3_src.tgz caccce29846949b28c2e52079c80e81d *jakarta-jmeter-2.3.3_src.zip Site Docs are here: http://people.apache.org/~sebb/jmeter-2.3.3RC2/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_3_RC2 (r776386) Keys are here: http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/ also http://www.apache.org/dist/jakarta/jmeter/KEYS N.B. To rebuild JMeter or run the unit tests, you need to unpack both the binary and source archives into the same directory structure. This is because the library files are only included in the binary archive. To create the jars and test JMeter: ant package test. Note that there is a bug in Java on some Linux systems that manifests itself as the following error when running the test cases or JMeter itself: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number This does not affect JMeter operation. All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and rename the RC tag as the release tag. Here's my: +1 S/// - To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release JMeter 2.3.3 RC1
sebb wrote: The first release candidate for JMeter 2.3.3 has been prepared, and your votes are solicited. JMeter is a Java desktop application designed to load test functional behavior and measure performance. The current version is targetted at Java 1.4+. Archives/hashes/sigs and RAT report: http://people.apache.org/~sebb/jmeter-2.3.3RC1/dist MD5 hashes of archives for this vote: dbdb62e4b64dc4cee77dd6229f8b687e *jakarta-jmeter-2.3.3.tgz f1c310eb9b3746143730e880d1aa17a8 *jakarta-jmeter-2.3.3.zip 51c20a74e90c5f61660414480e092d83 *jakarta-jmeter-2.3.3_src.tgz f8ecb89c5e6094b870b795fea7c9b460 *jakarta-jmeter-2.3.3_src.zip Site Docs are here: http://people.apache.org/~sebb/jmeter-2.3.3RC1/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_3_RC1 (r774953) Keys are here: http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/ also http://www.apache.org/dist/jakarta/jmeter/KEYS N.B. To rebuild or test JMeter, you need to unpack both the binary and source archives into the same directory structure. This is because the library files are only included in the binary archive. To create the jars and test JMeter: ant package test Note that there is a bug in Java on some Linux systems that manifests itself as the following error when running the test cases or JMeter itself: [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number This does not affect JMeter operation. All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and rename the RC tag as the release tag. Here's my: +1 S/// Sebastian, I am getting one compile warning and one test case failure. ... init-version: [echo] jmeter.version = 2.3.3.20090516 [echo] display.version = 2.3.3.20090516 [echo] implementation.version = 2.3.3.20090516 compile-jorphan: [mkdir] Created dir: c:\data\jakarta-jmeter-2.3.3\build\jorphan [javac] Compiling 48 source files to c:\data\jakarta-jmeter-2.3.3\build\jorphan [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. update-version: [echo] Updating version string to 2.3.3.20090516 compile-core: [mkdir] Created dir: c:\data\jakarta-jmeter-2.3.3\build\core [javac] Compiling 292 source files to c:\data\jakarta-jmeter-2.3.3\build\core [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. compile-components: [mkdir] Created dir: c:\data\jakarta-jmeter-2.3.3\build\components [javac] Compiling 111 source files to c:\data\jakarta-jmeter-2.3.3\build\components compile-functions: [mkdir] Created dir: c:\data\jakarta-jmeter-2.3.3\build\functions [javac] Compiling 31 source files to c:\data\jakarta-jmeter-2.3.3\build\functions [javac] c:\data\jakarta-jmeter-2.3.3\src\functions\org\apache\jmeter\functions\UnEscapeHtml.java:36: warning: unmappable character for encoding UTF-8 [javac] * For example, the string lt;Franccedil;aisgt; will become Fran?ais [javac] ^ [javac] 1 warning ... [java] ..F... [java] . [java] . [java] . [java] .. [java] Time: 25.49 [java] There was 1 failure: [java] 1) testPause(org.apache.jmeter.samplers.TestSampleResult)junit.framework.AssertionFailedError: Accumulated time (199) was not between 200 and 290 ms [java] at org.apache.jmeter.samplers.TestSampleResult.testPause(TestSampleResult.java:66) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:218) [java] [java] FAILURES!!! [java] Tests run: 1658, Failures: 1, Errors: 0 [java] The compile warning is not a release blocker but you may still want to fix it by setting source encoding to ISO-8859-1 or UTF-8 or by escaping the non-ASCII character in the source code. Oleg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail:
Re: [VOTE] JMeter 2.3.2RC7 - please!
sebb wrote: Trying yet again ... votes needed (positive or negative) - thanks! +1 Oleg The licence issues reported by Henri have (I trust) been fixed. Also the lib/opt directory is now included in the source archives. To rebuild or test JMeter, you need to unpack both the binary and source archives in the same directory structure. This is because the library files are not duplicated in the source archive. Note that there is a bug in Java on some Linux systems that manifests itself as the follow error when running the test cases or JMeter itself. [java] WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Not supported: indent-number Archives/hashes/sigs and RAT report: http://people.apache.org/~sebb/jmeter-2.3.2RC7/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3.2RC7/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC7 Keys are here: http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt also http://www.apache.org/dist/jakarta/jmeter/KEYS All feedback (and votes!) welcome. [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release (please indicate why) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and create the release tag from the RC tag. Here's my: +1 S/// - 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]
Re: [VOTE] JMeter 2.3.2RC3
On Sat, 2008-05-31 at 20:44 +0100, sebb wrote: On 31/05/2008, Dennis Lundberg [EMAIL PROTECTED] wrote: sebb wrote: ... How about adding a download-libraries target to the Ant build, that downloads the dependencies from the central (Maven) repository? That's a possibility for a future release. Better yet, consider using Ivy [1], which is now an Ant sub-project, for dependency management. I am sure it must be possible to get Ivy to retrieve and copy all project dependencies to a local folder. Oleg [1] http://ant.apache.org/ivy/ Almost all users of JMeter will need the binary version. Anyone who wants to build add-ons for JMeter will need the binary version. It's only if someone wants to build JMeter from scratch that they will need the source. We did consider releasing JMeter as 3 archiives: source, binary and libraries, but it was felt that the user should not be required to download multiple archives in order to start using JMeter. For a Maven project, this is done by declaring dependencies on the library files, which it may (or may not if provided) download for you. In this case, the Ant file has a dependency on the binary archive. It just does not download it for you. Best regards Henning sebb schrieb: On 30/05/2008, sebb [EMAIL PROTECTED] wrote: On 28/05/2008, Henri Yandell [EMAIL PROTECTED] wrote: MD5, PGP good. It's a bit odd that the binary version comes chock full of jars and the source version doesn't. When I run 'ant' in the source version I get: BUILD FAILED /Users/hen/apache/jmeter/jakarta-jmeter-2.3.2/build.xml:925: /Users/hen/apache/jmeter/jakarta-jmeter-2.3.2/lib/opt not found. I need to look at that. Fixed in SVN. If a build is attempted from just the source archive the output is: C:\ReleaseCheck\jakarta-jmeter-test ant Buildfile: build.xml _message_3rdParty: [echo] Cannot find all the required 3rd party libraries. [echo] If building from a release, you need both source and binary archives. BUILD FAILED C:\ReleaseCheck\jakarta-jmeter-test\build.xml:937: Cannot find required classes I'm also suspect of whether it will build with so few jars available. I don't see junit in there, or being hooked up to download. It won't build on its own. To avoid duplication, building requires the binary archive as well. This is documented in the README file. In the current source download, the geronimo and velocity jars should ideally have their license and notice files. As they are ASF projects, I assumed that they were covered by the following in the NOTICE file: This product includes software developed at The Apache Software Foundation (http://www.apache.org/). and the LICENCE. The following jars need license files in the binary download: junit (CPL) htmllexer (I'm assuming it's under the htmlparser CPL?) Yes, it's part of htmlparser. js_rhino (MPL iirc) OK; there were pointers to the online versions in the main LICENSE file, but I've now added local copies. Ideally, various ASF Apache 2.0 licenses/notices would also be there; but those are the three important ones. Thanks. Hen On Tue, May 27, 2008 at 4:50 PM, sebb [EMAIL PROTECTED] wrote: [Third time lucky, I hope] There is one trivial code change from RC1: * Log the property java.vm.name which shows whether the -client or -server Java flag was used when starting JMeter Otherwise the main changes relate to the way the archives are created: the tar files use LF endings for native files, and the zip files use CRLF endings. The JMX test and demo files have been updated to the new format. Some AL headers were added. As far as I can tell I've fixed all the previous test problems that were reported (and one I accidentally introduced in RC2 when the EOL settings were tidied up). Note that there is a bug in Java on some Linux systems that manifests itself as the follow error: [java]
Re: [VOTE] JMeter 2.3.2RC1
On Tue, 2008-05-20 at 01:23 +0100, sebb wrote: It's about time (indeed overdue) for another JMeter release, so I've created JMeter 2.3.1 RC1 in the directory: http://people.apache.org/~sebb/jmeter-2.3.2/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3.2/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC1 Keys are here: http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt also http://www.apache.org/dist/jakarta/jmeter/KEYS All feedback (and votes!) welcome. [ ]+1 - the release candidate is OK [ ]-1 - there is a problem (please indicate what it is) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and create the release tag from the RC1 tag. Hi Sebastian JMeter compiles and builds just fine. All tests pass for me, but the 'ant test' terminates with a build failure. BUILD FAILED /home/oleg/temp/jakarta-jmeter-2.3.2/build.xml:1552: Files are not identical. Any idea what may be wrong? Oleg Here's my: +1 - 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]
Re: [VOTE] JMeter 2.3.2RC1
On Tue, 2008-05-20 at 21:03 +0100, sebb wrote: On 20/05/2008, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Tue, 2008-05-20 at 01:23 +0100, sebb wrote: It's about time (indeed overdue) for another JMeter release, so I've created JMeter 2.3.1 RC1 in the directory: http://people.apache.org/~sebb/jmeter-2.3.2/dist Site/Docs are here: http://people.apache.org/~sebb/jmeter-2.3.2/docs Tag: http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC1 Keys are here: http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt also http://www.apache.org/dist/jakarta/jmeter/KEYS All feedback (and votes!) welcome. [ ]+1 - the release candidate is OK [ ]-1 - there is a problem (please indicate what it is) The vote will remain open for at least 72 hours. Note: If the vote passes, the intention is to release the archive files and create the release tag from the RC1 tag. Hi Sebastian Thanks for trying it out. JMeter compiles and builds just fine. All tests pass for me, but the 'ant test' terminates with a build failure. BUILD FAILED /home/oleg/temp/jakarta-jmeter-2.3.2/build.xml:1552: Files are not identical. Any idea what may be wrong? One of the tests uses two threads - the ramp up time is supposed to ensure that the first thread finishes before the second starts, but sometimes this does not happen, and the samples occur in the wrong order. In my experience that is fairly rare, but perhaps the ramp-up needs to be increased. If the comparison fails, there should be some BatchTestLocal.csv/.xml files in the bin directory; these should agree with the same name files in bin/testfiles. If you want to run it again without rebuilding everything, try ant batchtest or ant batchtestserver The batch test seems to be failing consistently for me. I did not get a single successful run out of 6. If the test often fails on your system then clearly the test needs fixing - what OS/Java/hardware are you using? Single core Intel Centrino CPU, 2GB Ubuntu 8.04 Linux ubuntu 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux Sun JDK 1.5.0 java version 1.5.0_11 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode) I do not think it is a blocker, but I would be nice to fix it. Oleg Oleg Here's my: +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents = TLP
On Sat, 2007-08-18 at 09:25 +0200, Roland Weber wrote: Oleg Kalnichevski wrote: Could you live with HttpComponents being the name of the new TLP? I would really like to avoid having to come up with a completely new name for the project. HttpComponents use the package org.apache.http. I would prefer something abstract as the home for non-HTTP code such as WebDAV or multipart. How do we do that without a project name to use as the package name? (org.apache.httpcomponents is not an improvement over org.apache.http ;-) What's wrong with org.apache.slide for WebDAV components? Oleg cheers, Roland - 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]
Re: [discuss] Slide + HttpComponents = TLP
On Sat, 2007-08-18 at 11:49 +0200, Roland Weber wrote:
Oleg Kalnichevski wrote:
What's wrong with org.apache.slide for WebDAV components?
If we're not taking over the full Slide codebase,
and if Slide\{WebDAV-client} is not officially
declared dormant in Jakarta, then we'd have two
independent projects using the same namespace.
Since a WebDAV client based on the 4.0 HttpClient
will be incompatible, it's also a question whether
the same package names should be used. That will
create name clashes in applications that for some
reason - for example during migration - have to
use both old and new packages.
While Martin mentioned in the June board report [1]
that he would like to keep the Slide codebase in
one piece, the current state of the discussion tends
towards carving out the WebDAV client only. In that
case, I wonder whether we should position the new
component as a successor to Slide at all.
If there are no plans to develop non-client bits any further, I
personally think WebDAV client should keep Slide as its name. Slide is a
well established brand and I see no benefit in discarding it and coming
up with some new fancy name.
Oleg
cheers,
Roland
[1] http://wiki.apache.org/jakarta/JakartaBoardReport-June2007
-
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]
Re: [discuss] Slide + HttpComponents = TLP
On Sat, 2007-08-18 at 12:21 +0200, Roland Weber wrote: Oleg Kalnichevski wrote: If there are no plans to develop non-client bits any further, That exactly is my concern. I still hope for some more input from Slide developers. I personally think WebDAV client should keep Slide as its name. I could live with that. Slide is a well established brand As a server component that happens to have a little client-side WebDAV library as an add-on. and I see no benefit in discarding it Disassociation from the server side. What is the benefit of that? At any rate in my opinion it is not worth trouble of rebranding the whole project. Oleg cheers, Roland - 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]
Re: [discuss] Slide + HttpComponents = TLP
On Sat, 2007-08-18 at 13:40 +0200, Roland Weber wrote: Disassociation from the server side. What is the benefit of that? At any rate in my opinion it is not worth trouble of rebranding the whole project. Will the current [EMAIL PROTECTED] and [EMAIL PROTECTED] mailing lists continue to exist alongside [EMAIL PROTECTED] and [EMAIL PROTECTED], where the Slide WebDAV client finds a new home? Yes, as aliases. I think it is a standard practice. But it is a detail when can take care of in the normal course of things. Oleg That would be bound to confuse users. cheers, Roland - 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]
Re: [discuss] Slide + HttpComponents = TLP
Oliver Zeigermann wrote: 2007/8/10, Roland Weber [EMAIL PROTECTED]: While I would like to get rid of HttpClient 3.x rather sooner than later, there's no denyig that it will stay with us for several years to come. From this angle, it would make sense to move the WebDAV client as it is. Maybe that could be the first step. If there is a reasonable interest of developers to help support the 3.x based WebDAV client, I am in favor of cutting it out. I hope that this discussion will heat up a bit next week. (while I'm away...) Let's see if there is... Leaving the server-side code of Slide in Jakarta will surely give the new project a better start. That code would be a huge burden on my mind, and probably not mine alone. Right. Oliver Hi Oliver Could you live with HttpComponents being the name of the new TLP? I would really like to avoid having to come up with a completely new name for the project. The name is ugly and unwieldy but we have already had a number of public releases so it is more or less established. If yes, consider adding your name to the TLP proposal draft below [1] and I'll go ahead and add a clause about WebDAV client based on Slide codebase to the project scope. Cheers Oleg [1] http://wiki.apache.org/jakarta-httpclient/ApacheHttpComponentsTlpProposalDraft - 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]
Re: [discuss] Slide + HttpComponents = TLP
On Thu, 2007-08-02 at 18:45 +0200, Roland Weber wrote: Hi all, ... I've been following the Slide [3] developer list for about two months, and I've read through their home page. The last release was at the end of 2004, and development seems to have basically stopped then. Slide comprises both client and server side components, with most of the code being for the server side. Martin indicated that the server side functionality is being replaced by Jackrabbit [4], but that the client side could have a future. Slide has two client side components, a WebDAV library and a WebDAV command line tool. In case you are not familiar with it, WebDAV is an extension of HTTP. The Slide WebDAV client library is based on the old HttpClient code. Incidentally, Jackrabbit also has a WebDAV client library which is based on the old HttpClient code. So, how would the new project look like? I see it as the home of three codebases: a) HttpComponents 4.0 + modules for a WebDAV client based on the 4.0 API, active. Maybe also the command line client. b) HttpClient 3.x, in maintenance mode. c) Slide 2.1, in maintenance mode. The scope for the activities of the new project: HTTP and related, with a focus on libraries implementing the protocols rather than applications using them. related encompasses HTTP extensions such as WebDAV and CalDAV, and other HTTP-like protocols such as SIP. Compared to the current scope of HttpComponents, it is an extension towards the content layer. HttpComponents is deliberately content agnostic and focusing on the transport aspects of HTTP. Compared to the current scope of Slide, it is a strong cutback. The server-side repository architecture, including ACL and whatever, is falling out of scope. Your thoughts? Slide seems pretty inactive at the moment. I am just wondering how many developers out there would be willing to contribute on a more or less regular basis to the maintenance and further development of Slide, or the new TLP will effectively end up tasked with the job of trying to recreate the community around the old Slide code base, albeit with a somewhat reduced scope. Oleg cheers, Roland [1a] http://mail-archives.apache.org/mod_mbox/jakarta-slide-dev/200706.mbox/[EMAIL PROTECTED] [1b] http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200706.mbox/[EMAIL PROTECTED] [2] http://jakarta.apache.org/httpcomponents/ [3] http://jakarta.apache.org/slide/ [4] http://jackrabbit.apache.org/ - 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]
Re: What about HttpClient?
On Fri, 2007-06-29 at 21:26 +0100, Stephen Colebourne wrote: Roland Weber wrote: 1. Keep the httpclient site with the rest of commons and move it to the new TLP domain. We'll have to update the httpclient build with the new location and redeploy. (Anything I've forgotten?) 2. Move the httpclient site to httpcomponents. Since httpcomponents is unlikely to remain in Jakarta indefinitely, that means the site would move again later this year. Two moves within a few months is a bit too disruptive to users for my liking. 3. Keep the httpclient site at it's current location in Jakarta when the rest of the commons site moves. Move it only once to httpcomponents when those leave Jakarta. The question is really whether the Commons TLP owns the HttpClient codebase. Stephen et al Based on the project's charter approved by the Jakarta PMC on Oct 31st, 2005 the HttpComponents project is meant to have the ownership of the Commons HttpClient codebase http://svn.apache.org/repos/asf/jakarta/httpcomponents/project/project-charter.txt It all did not matter much while we were still one (more or less) happy family. My preference is to not not move stuff around (option 1). I am planning to cut HttpClient 3.1 final release shortly after HttpClient 4.0 alpha1. 3.1 is very likely to be the last release of the HttpClient 3.x codebase unless some serious security or legal problems are found. There is no point in investing a lot of efforts into a codeline, which is going to become dormant very soon. Oleg I don't believe its terribly sensible for it to do so. All active committers and knowledge are focussed in the HttpComonents group. Thus I would suggest #3 as the best option, followed by #2. Stephen - 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]
Re: [VOTE] Commons moving to TLP
On Wed, 2007-05-23 at 19:14 +1000, Dion Gillard wrote: I think there's another issue here. Many of those who voted +1, aren't on the initial list of committers in the proposal. Also, many current commons committers aren't on the proposed list. It seems that we're not voting on that specific proposal, rather just the idea to move, and that a lot of people are being disenfranchised by not being listed. Wouldn't it be better if the initial list came from the svn acl? Dion, Just speaking for myself I intentionally did not want to add my name to the list of committers to show my disapproval of the proposal, but at the same I did not feel my involvement in the rest of Commons besides maintenance of HttpClient 3.x codeline was significant enough to justify a -1 vote. Oleg On 5/23/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote: Sadly a bit too late to make the next board meeting I suspect. However, here's a vote for Commons to officially request that it move to TLP. http://wiki.apache.org/jakarta-commons/TLPResolution Please add your name if you're a Commons developer and haven't added your name yet. [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. Quick summary of this thread 28 Votes for (23 binding), 4 against (3 binding). Seems to me that those objecting don't seem to have pursuaded people to change their vote. At what point do we decide on a result? Votes +1 (* indicates binding) 1. Henri Yandell(*) 2. Dennis Lundberg(*) 3. Mladen Turk(*) 4. Torsten Curdt(*) 5. Oliver Heger(*) 6. Robert Burrell Donkin(*) 7. Stephen Colebourne(*) 8. Daniel F. Savarese(*) 9. Martin Cooper(*) 10. Mark Thomas(*) 11. Niall Pemberton(*) 12. Stefan Bodewig(*) 13. Phil Steitz(*) 14. Jörg Schaible(*) 15. Jean-Frederic(*) 16. Henning Schmiedehausen(*) (conditional on The TLP proposal matching the template) 17. Nick Burch 18. Davanum Srinivas(*) 19. Thomas Vandahl 20. Oliver Zeigermann(*) 21. Rony G. Flatscher(*) 22. Scott Eade(*) 23. Yegor Kozlov 24. Luc Maisonobe 25. Mario Ivankovits(*) 26. Roland Weber(*) 27. Andrew Oliver(*) (think this was a vote for, voted -1 to Commons=Jakarta) 28. Jesse Kuhnert Added themselves to the TLP Proposal but didn't vote(?) 1. Jochen Wiedmann 2. Martin van den Bemt(*) 3. Matt Benson 4. Rory Winston(*) 5. Joerg Pietschmann Objections / Votes -1 = 1. Petar Tahchiev - sees no direct benfits for Commons 2. Ted Husted(*) - Strike Java from resolution or don't hijack Commons Name 3. Simon Kitching(*) - Will erect walls we took down - like Ted doesn't want java to monopolise commons name 4. Danny Angus(*) - preserve the Jakarta brand - Wants Jkarata==Jakarta Commons - thinks Commons should sort out Jakarta problems Bile Nonsense === Jean Carlo Salas - 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]
Re: [VOTE] Release Regexp 1.5
On Mon, 2007-03-19 at 13:30 -0400, Jesse Kuhnert wrote: Sure, of course it's ok for the ASF to dictate policies - I just hope it's ok for me to question them / point out their flaws. So the real problem as far as I can tell is making sure a release is legitimately licensed. There are other things like software quality, but I guess it's assumed (by me at least) that we're all trying to release as high a caliber of software as we are able given our resources / time. Somehow this still doesn't feel like a legitimate problem, or at least it is not consistent with the rest of our daily practices. ..Like committing a change to subversion. As far as I can tell there is no legal difference between subversion repositories and released software - is there? Isn't the end goal to prevent any naughty code coming out of apache period? Non conforming code sitting in subversion would appear to be just as guilty as anything else...So given your current logic shouldn't we all be required to have a PMC vote for each commit made into the repo? It just feels like we're being treated a little bit like incompetents in some way. Like maybe someone accidentally made a bad release once or twice and so we must all suffer the same solution that they have. Ehh...Obviously I'm alone in my opinion so I'll shut up now, just wanted to make sure I got my two cents in. Jesse, You are certainly not alone. I have always been of an option that the content of the SVN repository is what truly represents the source code of ASF software, with packaged releases merely being versioned snapshots officially endorsed by the project committers and the respective PMC and recommended for use by the end users. I am not a legal expect by any stretch of imagination but I think ASF may be equally liable for any given revision in its official SVN repository as for its packaged releases. In Commons HttpClient / HttpComponents land we historically voted on SVN revisions and published release packages based on a lazy consensus if no one raised complaints about the content of the release packages. Oleg On 3/19/07, J Aaron Farr [EMAIL PROTECTED] wrote: Jesse Kuhnert [EMAIL PROTECTED] writes: You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. The problem is that Vote-Then-Release leaves opportunities for the small details to get missed and you end up with a sloppy release. Examples include non-signed distributables, incomplete legal notices, missing or incorrect hashes. The worst is someone slipping in some malicious code in between the time the vote is cast and the release is made. When a PMC votes on a release they should be approving the exact bits that hit the mirrors. That vote binds the ASF to be _legally_ responsible. The only way to have sufficient and appropriate oversight is to give the PMC a chance to check that these final steps of a release have been properly handled. Otherwise the PMC risks releasing a half baked product. It is completely appropriate for the ASF to set guidelines on release procedures. -- jaaron (who is not on the Jakarta PMC) - 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]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
On Fri, 2007-02-23 at 23:35 +0100, Martin van den Bemt wrote: I prefer this vote to see where it should end up in Jakarta and based on that result the path full incubation / legal incubation is decided. So in my view the vote should be : [x] Jakarta should sponsor (which effectively states we like to see the code end up here) [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP) if accepted in Jakarta, it should end up in : [x] commons as a component [ ] httpcomponents as a component [ ] subproject directly under Jakarta [ ] integrate / merge code into project xxx (please replace x) (so not a subcomponent of a project!) And [ ] I am willing to mentor (you need to be on the Incubator PMC / Member of the ASF) [x] I want to get involved in coding [ ] No interest in getting involved. Oleg Reasoning : 1) the first decides if Jakarta wants to sponsor this 2) we need to know the place it should end up in Jakarta (at least have some kind of direction) 3) if no one is interested in getting involved or being a mentor (preferably 3 mentors!), we can easily see if option 1 and 2 are viable at all. The problem with the current vote is that I have to start yet another vote to let us sponsor and where it should end up, best to do it in one go in my opninion... So Martin and Ortwin could you please revote ? (Sorry for the inconvenience) Mvgr, Martin Julius Davies wrote: Hi, Jakarta-General, Let's vote on where to put this code! Here's the code right now: http://juliusdavies.ca/commons-ssl/ Forgive my newbieness; I hope these are the right options: [+1] Sub-module in Httpcomponents. [+1] Sandbox. [+1] Full Incubator. [-1] not-yet-commons-ssl is not a good project for Apache because... I'm fine with majority rules, assuming there are no -1 votes. Some background: http://wiki.apache.org/jakarta/JakartaBoardReport-February2007 The code grant for the not yet commons SSL (formerly named commons-ssl), has been completed, so we can progress to having a vote where SSL should end up on general and based on that result take the correct incubator path (legal / full incubation). Let's just get this vote out of the way, and then we can move on to other issues in the appropriate venue (HttpComponents, or Sandbox, or Incubator). My original proposal to jakarta-general about the project is here: http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html Yesterday I released not-yet-commons-ssl-0.3.7. Changes described at the bottom of this email. My intention is for 0.3.7 to be the last release outside of Apache. By the way, there's one undocumented feature of common-ssl that's been quite fun: http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html :-) yours, Julius ps. My vote is: [+0] - Abstaining because I'm too much of a newb to really understand what I'm voting for. On 2/23/07, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote: not-yet-commons-ssl-0.3.7 released! http://juliusdavies.ca/commons-ssl/download.html Hi Julius, What are your plans regarding not-yet-commons-ssl? Is there anything still blocking the incubation process? There are already two Apache projects (HttpComponents and Synapse) that can potentially benefit from collaboration with not-yet-commons-ssl. So, there is a lot of interest in seeing things moving forward. Oleg Features as of not-yet-commons-ssl-0.3.7: 1. useStrongCiphers() used by default. - 40 bit and 56 bit ciphers are now disabled by default. To turn them back on call useDefaultJavaCiphers(). 2. addAllowedName() adds some flexibility to the CN verification. - Here's a code example using cucbc.com to connect, but anticipating www.cucbc.com in the server's certificate: SSLClient client = new SSLClient(); client.addAllowedName( www.cucbc.com ); Socket s = client.createSocket( cucbc.com, 443 ); This technique is also useful if you don't want to use DNS, and want to connect using the IP address. 3. SSLServer can re-use a Tomcat-8443 private key if running from inside Tomcat. - SSLClient server = new SSLServer(); server.useTomcatSSLMaterial(); 4. RMI-SSL support improved. - Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server sockets. Anonymous server-sockets (port 0) will always be set to port 31099. Analyzes the server certificate CN field and tries to set java.rmi.server.hostname
Re: PROPOSAL: commons-ssl - commons-sslutils?
On Fri, 2006-12-01 at 15:20 -0500, Vadim Gritsenko wrote: Julius Davies wrote: ... I had to explain that Commons-SSL just sits on top of the JSSE and JCE to try and make working with SSL and Java easier. Your point about the name is a good one. The counterpoint to name argument. Just single example, I'm sure there are many more: commons-logging sits on top of log4j/java logger/logkit/... and tries to make working with all them seamless. commons-ssl may be not the best name but it isn't terribly bad either. Vadim Folks, What about Commons-SSLUtils? This name seems consistent with already existent Commons projects (DBUtils) Julius, Since what-some-day-might-become-commons-ssl is partially based on some little bits of code I wrote, you can safely add me to the initial list of committers. I will not be able to do a lot in terms of coding, given my HttpComponents commitments, but I could help by doing some code reviews once in a while and participating in design decisions. Cheers, Oleg ... On 12/1/06, Roland Weber [EMAIL PROTECTED] wrote: The working title Commons-SSL does not really reflect this. Do you plan to implement the SSL protocol as part of the project? Probably not, so the title is misleading. An all-encompassing name might also be offensive to people working on other SSL-related projects. I think you should spend the time and define not only a motto, but a very clear scope of the project. Both in terms of what's in scope as well as what's out of scope. From there on, we can work on finding a name and home. Please do not underestimate the importance of this step. Finding a name may seem like a minor detail, but the problem of defining the scope is very real. Only a few months ago, there was a long discussion on this list about a proposal for testing.apache.org. I haven't read anything about it anymore after the supporters realized that a scope of everything that has to do with testing was overly broad. We don't want to see that happen to your proposal. - 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]
[ANNOUNCEMENT] HttpClient issue tracking migrated to Jira
HttpClient issue tracking has migrated from Bugzilla to Jira. Please do not enter new bug reports and update exiting ones in Bugzilla. HttpComponents project will be using Jira to manage HttpClient related issues as of today. Please use the following project in Jira to report new issues against HttpClient and search for reported ones. http://issues.apache.org/jira/browse/HTTPCLIENT All existing issue reports can be accessed in Jira by their original Bugzilla bug id. Jakarta HttpComponents Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components + Jakarta HttpComponents
On Mon, 2006-03-06 at 10:14 -0800, Martin Cooper wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: (feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) snip/ But do it within a reasonable time frame (atleast post any objections to JWC in a week -- I think thats reasonable, unless anyone wants more time?). I have been meaning to add some initial components to JWC and begin work there, and while I agree that the name is important, this name game is now getting old ;-) Recap - We had 3 votes for JWC in the initial vote thread, and there seems to have been more added informally on parallel conversations on commons-dev. Seems the J*C trend is catching on (see Stephen talk about JLC in another thread). Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). snap/ Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) Hello, Martin et al There's already plenty of code to look at in SVN. We are gradually moving toward releasing our first official ALPHA. The preview of the HJC web site can be found here: http://people.apache.org/~olegk/httpcomponents/ May I, however, express my (humble) opinion that some of the Commons [FileUpload] code may find a better home in Commons [Codec]. To me, all the mime/multipart parsing logic clearly belongs to [Codec]. There are plans to factor out all multipart encoding code from Commons [HttpClient] and move it to Commons [Codec] This said, Commons [FileUpload] is welcome to consider joining JHC Cheers, Oleg * Latka (dormant) * FeedParser (possibly? dormant) From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) I used to work on the Mailer taglib, but abandoned it when someone else decided to reinvent that as a Mailer2 taglib. That now appears to have been abandoned as well, and never made it out of the Taglibs sandbox. So I'm not sure which, if either, would go to JWC. -- Martin Cooper Then there is the question of sandbox. There has been talk about a Jakarta sandbox, that probably deserves its own thread. -Rahul Hen - 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]
Re: Action Items: Jakarta Http Components
On Fri, Nov 04, 2005 at 09:57:26AM -0500, Henri Yandell wrote: So, to move HttpClient up we need: 1) svn move (what is the new svn directory name to be?) Done. The svn directory can be found here: http://svn.apache.org/repos/asf/jakarta/httpcomponents/ 2) update the asf-authorization file 3) update the Jakarta navigation etc 4) move the httpclient site We would like to keep Jakarta Commons HttpClient where it is until Jakarta HttpClient 4.0 is ready (has an RC quality release). Jakarta Commons HttpClient and Jakarta HttpComponents will have to co-exist for an interim period of time 5) make sure htaccess redirect is in place from old site We are working on getting the new site up, which will point at the existing HttpClient site 6) mailing list rename 7) what am I missing? We have an action plan in the HttpClient Wiki. Feel free to put it to a good use http://wiki.apache.org/jakarta-httpclient/HttpComponentsActionPlan 2 has to be the PMC chair, so once I know what 1) is I'll do both 1 and 2 at the same time. 6 means a request of to asf-infrastructure. Many thanks for helping us Cheers, Oleg Hen - 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]
Re: [Request for Comment] Http Components proposal
On Wed, Oct 19, 2005 at 11:42:47PM -0400, Henri Yandell wrote: Oleg, did Robert's bits all get into the charter? Can I go ahead and call a vote? The usual apologies for my slowness in returning back to the thread. I need to kick myself into spending the next couple of days sending out Jakarta email on various threads. Hen Hi Henri There's nothing you need to apologize for. The work at Jakarta on top our regular daily responsibilities is a tough balancing act for most of us. All Robert's bits made it into the charter draft http://wiki.apache.org/jakarta-httpclient/NewProjectCharter. Please go ahead and call a vote. Cheers, Oleg On Thu, 6 Oct 2005, Oleg Kalnichevski wrote: On Thu, Oct 06, 2005 at 10:51:24AM +0100, robert burrell donkin wrote: just a few more from me: * Jakarta Http Components continues the development of Jakarta HttpClient (formerly Jakarta Commons HttpClient ) based on the toolset of HTTP components. This tool focuses strictly on the client side of HTTP. - * Jakarta Http Components continues the development of Jakarta HttpClient (formerly Jakarta Commons HttpClient ) based on the toolset of HTTP components. This tool focuses on the client side of HTTP. 'strictly' is an unnecessary and subjective qualifier so probably best removed. * Jakarta Http Components MAY develop non-client components (such as an HTTP connector, a lightweight server component, proxy components) as reference material to demonstrate the capabilities of the toolset. The said artifacts ARE NOT meant for production use and are not released as official Apache Jakarta products. - * Jakarta Http Components MAY develop application layer components (such as an HTTP connector, a lightweight server component, proxy components) as reference material to demonstrate the capabilities of the toolset. The said artifacts ARE NOT meant for production use and are not released as official Apache Jakarta products. this fits in better with the rest of the draft: low level transport layer APIs suitable for use on servers may be developed but application layer components (whether client or server) may only be developed as demonstrations. i'd also like to add a new clause: * Jakarta Http Components is additional charged with the maintenance of the existing jakarta-commons httpclient component. this makes it clear that the sub-project can and will maintain the existing httpclient components even if they would not longer be considered in-scope. all just IMHO, of course Hi Robert, I believe the changes you have suggested are quite reasonable. Please do not be shy and feel free to tweak the draft of the project charter directly in the Wiki: http://wiki.apache.org/jakarta-httpclient/NewProjectCharter Cheers, Oleg - robert On Thu, 2005-10-06 at 01:10 -0400, Henri Yandell wrote: Any more comments before I call a vote? Hen On Sat, 24 Sep 2005, Henri Yandell wrote: Prior to calling a PMC vote here in a week or two, I'd like to ask if anybody has any comments on the following proposal for Commons HttpClient to become a Jakarta subproject focusing on Http components. Hen * (The following charter for Jakarta Http Components project is pending approval of the Jakarta Project Management Committee (PMC). ) Rationale: = The original Jakarta Commons HttpClient API has a number limitations that cannot be resolved without a significant architectural redesign. Moreover, Jakarta Commons HttpClient has been increasingly used in applications and environments it has not been specifically designed for. The existing monolithic design no longer adequately reflects the use patterns of HttpClient. HttpClient needs to be refactored into a toolset of simple, low level HTTP components suitable for building more specialized HTTP services. Project scope: = * Jakarta Http Components develops a toolset of low level components focused exclusively at the transport aspects of HTTP protocol. * Jakarta Http Components MUST be content agnostic. The project DOES NOT develop components intended to produce or consume content of HTTP messages. * Jakarta Http Components continues the development of Jakarta HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of HTTP components. This tool focuses strictly on the client side of HTTP. * Jakarta Http Components MAY develop non-client components (such as an HTTP connector, a lightweight server component, proxy components) as reference material to demonstrate the capabilities of the toolset. The said artifacts ARE NOT meant for production use and are not released as official Apache Jakarta products. * Jakarta Http Components collaborates with other projects to develop specialized HTTP services for production use based on the toolset of HTTP
Re: [Request for Comment] Http Components proposal
On Sun, Sep 25, 2005 at 11:30:02PM +0100, robert burrell donkin wrote: On Sun, 2005-09-25 at 12:27 +0200, Oleg Kalnichevski wrote: On Sat, 2005-09-24 at 20:34 -0700, Martin Cooper wrote: On 9/24/05, Henri Yandell [EMAIL PROTECTED] wrote: ... * Jakarta Http Components MUST be content agnostic. The project DOES NOT develop components intended to produce or consume content of HTTP messages. While I understand what you're trying to say here, this wording appears to preclude some of what is in HttpClient today, namely multipart content handling. Hi Martin, This statement is not accidental. The plan is to factor the multipart content handling out of HttpClient. There's already a project in Commons Sandbox led by Mark R. Diggory http://svn.apache.org/repos/asf/jakarta/commons/dormant/codec-multipart/ for that end. Unfortunately the project has been dormant for quite some time but the plan is to revive the project at some point, get it graduate from Sandbox and possibly get it merged with Commons Codec proper at some point of time. IMHO a clause need to be inserted to allow the sub-project maintain the existing codebase (since it will be out-of-scope otherwise). actually, i'd prefer to see the pmc give the explicit responsibility for maintenance to the sub-project. * Jakarta Http Components DOES NOT define a server side API on top of the low level transport API. Again, I understand what you want to say. However, I think it would be better said in terms that make it clear that it is intended for use on the client side _of the protocol_, since many people are using HttpClient on the server side today, but as a client to other servers. Actually we see more and more often HttpClient code used to implement server side of the protocol as well. This statement is primarily to ensure that the project will not sidetrack into developing and _application_ API competing with javax.servlet API. We merely want to provide low level generic transport primitives. IMHO if this is the vision then it would be better to rephrase the final clause to make this clear. maybe something like: * Jakarta Http Components will provide ONLY a toolset of low level generic transport APIs. In particular, server side application layer APIs WILL NOT be developed. This does sound much better. If there are no objections, I would like to update the charter draft and replace the original clause with the one suggested by Robert. Oleg - robert - 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]
Re: [Request for Comment] Http Components proposal
On Mon, Sep 26, 2005 at 11:06:58AM -0400, Henri Yandell wrote: On Mon, 26 Sep 2005, Oleg Kalnichevski wrote: On Sun, Sep 25, 2005 at 11:30:02PM +0100, robert burrell donkin wrote: IMHO if this is the vision then it would be better to rephrase the final clause to make this clear. maybe something like: * Jakarta Http Components will provide ONLY a toolset of low level generic transport APIs. In particular, server side application layer APIs WILL NOT be developed. This does sound much better. If there are no objections, I would like to update the charter draft and replace the original clause with the one suggested by Robert. None from me; go ahead and drop us the link to the Wiki (because I didn't include it in the original like a fool :) ). Here's the link to the wiki based draft: http://wiki.apache.org/jakarta-httpclient/NewProjectCharter?action=show Oleg Hen - 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]
Re: [Request for Comment] Http Components proposal
On Sat, 2005-09-24 at 20:34 -0700, Martin Cooper wrote: On 9/24/05, Henri Yandell [EMAIL PROTECTED] wrote: ... * Jakarta Http Components MUST be content agnostic. The project DOES NOT develop components intended to produce or consume content of HTTP messages. While I understand what you're trying to say here, this wording appears to preclude some of what is in HttpClient today, namely multipart content handling. Hi Martin, This statement is not accidental. The plan is to factor the multipart content handling out of HttpClient. There's already a project in Commons Sandbox led by Mark R. Diggory http://svn.apache.org/repos/asf/jakarta/commons/dormant/codec-multipart/ for that end. Unfortunately the project has been dormant for quite some time but the plan is to revive the project at some point, get it graduate from Sandbox and possibly get it merged with Commons Codec proper at some point of time. * Jakarta Http Components DOES NOT define a server side API on top of the low level transport API. Again, I understand what you want to say. However, I think it would be better said in terms that make it clear that it is intended for use on the client side _of the protocol_, since many people are using HttpClient on the server side today, but as a client to other servers. Actually we see more and more often HttpClient code used to implement server side of the protocol as well. This statement is primarily to ensure that the project will not sidetrack into developing and _application_ API competing with javax.servlet API. We merely want to provide low level generic transport primitives. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Release of Commons HttpClient 3.0 RC1
The link has been fixed. Many thanks, Mark Oleg On Mon, 2005-02-07 at 07:25 -0800, Mark wrote: http://jakarta.apache.org/commons/httpclient/3.0/index.html has a broken link: http://jakarta.apache.org/commons/httpclient/3.0/applications.html Not Found The requested URL /commons/httpclient/3.0/applications.html was not found on this server. Apache/2.0.52 (Unix) Server at jakarta.apache.org Port 80 Regards, Mark --- Michael Becke [EMAIL PROTECTED] wrote: The Jakarta Commons team is pleased to announce the release of HttpClient 3.0 RC1. The 3.0 API is frozen and all known bugs have been fixed. Assuming no major problems are discovered in RC1 a final 3.0 release will follow shortly. We strongly encourage all current HttpClient users to start migrating. As always we welcome suggestions and bug reports. Thank you, Commons HttpClient Development Team HttpClient 3.0 Web Site: http://jakarta.apache.org/commons/httpclient/3.0/index.html Release Notes: http://www.apache.org/dist/jakarta/commons/httpclient/RELEASE- NOTES.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com - 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]
