RE: [RESULT] 4th attempt: Release commons-io 1.3.2
It seems odd that the site (http://jakarta.apache.org/commons/io/) is live but not [announce]'d and the links point to 1.3.1 downloads but are labeled 1.3.2. Thank you, Gary -Original Message- From: Jochen Wiedmann [mailto:[EMAIL PROTECTED] Sent: Monday, July 02, 2007 12:14 PM To: Jakarta Commons Developers List Subject: [RESULT] 4th attempt: Release commons-io 1.3.2 Thanks god, this vote has passed: +1: Stephen, Dion, Oliver, Phil, Rahul, Myself I am ignoring sebb's posting for this release. I'll pick up his comments for the new web site. Hope that suits anyone. Thanks, Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - 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: [RESULT] 3rd attempt: Release commons-io 1.3.2
Right +1 from me as noted in [1]. Indeed I did comment about maintenance releases needing to be binary compatible without new features as Apache guidelines note. In this case, I am happy to let the release manager make the call. I am also happy with the XP release early, release often. I think that as long as we document what we are doing in this case, and why, in the release notes, we should be ok. These release number guidelines are important and perhaps it is OK in this case if we can guarantee that nothing will break previous 1.3.x releases (1.3, 1.3.1). It sure does not seem that this should not break anything unless someone is compiling code and has deprecation usage configured as a compile error! Yikes. I think you can do that in Eclipse... Thank you, Gary -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 19, 2007 8:45 PM To: Jakarta Commons Developers List Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 On 6/19/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, Here's the result of the vote: +1: Sebb, Oliver, Niall, Ben, Myself snip/ And +1 from Gary in another thread [1] -- though in a subsequent post in the same thread he does express some interest in having the version number be 1.4. -1: Stephen No votes from Henri and Dion. My understanding is, that Stephen's vote isn't counted as a veto, but I'd like to ask you to correct me, if I'm wrong. In which case the vote had failed. snap/ Correct, it isn't a veto. In this case, it is upto you (being the RM) to decide whether to go ahead with putting the bits on the mirrors etc. since you have the required votes. I did not understand your comment about the version number [2] as it relates to whether deprecations should preclude release++ from being a point release. Regardless of what you choose to do here, we should (collectively) form an opinion and clarify this in the versioning guide for future reference. I am of the opinion that it shouldn't be a point release. -Rahul [1] http://www.nabble.com/RE%3A-Still-no-votes%21-%28WAS%3A--VOTE--3rd- attempt%3A-Release-commons-io-1.3.2%29-p11091530.html [2] http://www.nabble.com/Re%3A-Still-no-votes%21-%28WAS%3A--VOTE--3rd- attempt%3A-Release-commons-io-1.3.2%29-p11093009.html Thanks, Jochen - 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: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
+1, I would also like to see commons project releases say with each release if they adhere to this charter (as an extra checks and balances thing) Thank you, Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 12, 2007 11:19 PM To: Jakarta Commons Developers List Subject: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1 Sorry, but I have to agree with Niall on this - needs to be 2.0 with the incompatible changes - and I would like very much for us to agree once and for all on some versioning/deprecation rules. We seem to have lost the old versioning guidelines (unless I am senile, we used to have these on the commons or Jakarta pages somewhere). Apart from 0), which is a conservative but worth-considering-carefully PoV, the rules below are more or less what we have been adhering to over the last several years in commons and I would like to propose that we standardize on them. If all are OK, I will gin up a versioning page. A very good one, which is pretty much a C version of what I am proposing below, is http://apr.apache.org/versioning.html. 0) Never break backward source or binary compatibility - i.e., when you need to, change the package name. 1) 0 is going to have to fail sometimes for practical reasons. When it does, fall back to a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release b) no source or binary incompatibilities in an x.y release, but deprecations and semantic changes allowed c) no removals without prior deprecations, but these and other backward incompatible changes allowed in x.0 releases. This means that the [cli] release with the current changes would need to be 2.0. Phil - 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: Still no votes! (WAS: [VOTE] 3rd attempt: Release commons-io 1.3.2)
Are we sure we do not want to call this 1.4 since the only change is a _new_ class as opposed to maintenance updates? Thank you, Gary -Original Message- From: Jochen Wiedmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 12, 2007 12:27 PM To: Jakarta Commons Developers List Subject: Still no votes! (WAS: [VOTE] 3rd attempt: Release commons-io 1.3.2) We still do not have the required three votes by PMC members for a release. See http://www.nabble.com/-VOTE--3rd-attempt:-Release-commons-io-1.3.2- t3880798.html for details. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - 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: Still no votes! (WAS: [VOTE] 3rd attempt: Release commons-io 1.3.2)
Hello [io]: +1 I tested the source distribution with Ant 1.7.0 using: ant clean dist test testjar and got BUILD SUCCESSFULs using the following Java Dev Kits: java version 1.4.2_14 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_14-b05) Java HotSpot(TM) Client VM (build 1.4.2_14-b05, mixed mode) java version 1.4.2_14 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_14-b05) Java HotSpot(TM) Server VM (build 1.4.2_14-b05, mixed mode) 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, sharing) java version 1.6.0_01 Java(TM) SE Runtime Environment (build 1.6.0_01-b06) Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing) java version 1.7.0-ea Java(TM) SE Runtime Environment (build 1.7.0-ea-b13) Java HotSpot(TM) Client VM (build 1.7.0-ea-b13, mixed mode, sharing) I also tested the binary distribution jar with our product build on Java 1.5.0_11 and all of the relevant unit tested passed so I can say that our product should be able migrate from 1.3.1 to 1.3.2 without any issues. Thank you, Gary -Original Message- From: Jochen Wiedmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 12, 2007 12:27 PM To: Jakarta Commons Developers List Subject: Still no votes! (WAS: [VOTE] 3rd attempt: Release commons-io 1.3.2) We still do not have the required three votes by PMC members for a release. See http://www.nabble.com/-VOTE--3rd-attempt:-Release-commons-io-1.3.2- t3880798.html for details. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - 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 CLI 1.1
1) Why not deprecate the public fields in HelpFormatter rather than making them private? Or calling the release 2.0 with the understanding that a breaking compatibility is under the charter of major release. Thank you, Gary -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 12, 2007 7:16 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release CLI 1.1 On 6/12/07, Henri Yandell [EMAIL PROTECTED] wrote: I think we're finally ready for CLI 1.1 to be released: http://people.apache.org/~bayard/commons-cli/1.0-rc1/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc1/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch (needs renaming). [ ] +1, quick release before it's 5 years since 1.0 [ ] -1, let's go for 6 years Theres too much on the CLIRR report IMO for this to be a bug fix release - I'm not that familiar with CLI but most (all?) don't seem necessary for this 1.1 release 1) Why not deprecate the public fields in HelpFormatter rather than making them private? 2) IMO removing the Cloneable interface from Option seems just as bad as leaving it in broken (and actually fixing it doesn't seem that difficult). 3) Why not deprecate the public addValue() method in Option rather than changing the visibility to package (and removing boolean return type)? 4) Could an additional interface that extends CommandLineParser that adds the new methods have not been introduced instead? I don't subscribe to the never break backwards compatibility - but I do believe in deprecate/remove cycles and trying to retain compatibility in bug fix releases. For me there's too much in this one. If it was just the CommandLineParser - which does seem to offer benefits to the user - and is mitigated by the fact that (hopefully) most people will have extended Parser and be unaffected, then I would probably buy that argument. Niall 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: [jci] RC2 available
Hello Torsten: Where is the site that matches this build? Thank you, Gary -Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Thursday, May 24, 2007 4:22 PM To: Jakarta Commons Developers List Subject: [jci] RC2 available On every release you (try to) do with maven you learn something new. That's great - isn't it? :p Anyway... I am (finally) happy to announce that commmon-jci RC2 is available at http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-core/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-fam/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-eclipse/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-groovy/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-janino/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-javac/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-rhino/1.0/ http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ apache/commons/commons-jci-examples/1.0/ Almost no code changes - mostly the packaging and the site has been fixed as requested. (We now also have the assembly instructions and *could* build a one-zip-to-rule-them-all distribution but I would rather not have that as an official release.) Please check and let me know if you find something. If there aren't any objections I will start a vote on the weekend. cheers -- Torsten - 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: [cli] Minimum JDK version for 1.1?
I'm all for it. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, June 04, 2007 9:50 PM To: Jakarta Commons Developers List Subject: [cli] Minimum JDK version for 1.1? I'd like to move the minimum JDK version for CLI up to 1.4 for the CLI 1.1 release. This would: a) Allow the fact that the build.xml does not work on 1.3 to be ignored. b) Allow CLI-131 to be applied. c) Make for an easier build - I can build directly in Maven and not worry about legacy. Anyone against? 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]
[jira] Commented: (LANG-335) Comparisons of Dates and Calendars to second precision
[ https://issues.apache.org/jira/browse/LANG-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497532 ] Gary Gregory commented on LANG-335: --- Would Joda-TIme help here? Comparisons of Dates and Calendars to second precision -- Key: LANG-335 URL: https://issues.apache.org/jira/browse/LANG-335 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Environment: Windows, JDK 1.6.0, Eclipse 3.2 Reporter: Alex Marshall Priority: Trivial The o.a.c.lang.time.DateUtils should have functions for comparing dates and Calendars to only second precision instead of millisecond. The motivation for this is comparison of dates and Calendars in objects both before and after the objects have been committed to and retrieved from a database. In theory the objects should be equal if 'equals' is run on them, but in practice they are not because the date fields do not have exactly the same millisecond values after they've been persisted to a database since times in many databases are only maintained to second-level precision (and without TimeZone information in many cases, to boot!) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (LANG-335) Comparisons of Dates and Calendars to second precision
Hello: I am pointing to Joda-Time in general for date and time issues as it is a comprehensive open source solution. It is my understanding that we have not enhanced [lang] in this department because we do not want to end up with a Joda-Time-like component within [lang]. Thank you, Gary From: Alex Marshall [mailto:[EMAIL PROTECTED] Sent: Monday, May 21, 2007 12:01 PM To: Jakarta Commons Developers List Subject: Re: [jira] Commented: (LANG-335) Comparisons of Dates and Calendars to second precision I've looked at the Joda-Time API and it doesn't look like there's anything that would be nearly as efficient as the simple bit-math that's used to do the calculations in the JDK implementation. Admittedly I'm not that familiar with the library, so if there is a better way, I'm open to being corrected. Alex Marshall Software Developer Email:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED] MSN Messenger: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] ICQ: 137350791 Skype username: alex.marshall Office: 1-888-286-2010 Ext 229 Fax: 1-780-484-0538 CONFIDENTIAL: This message, including any attachments, may contain confidential and/or privileged information, which is intended solely for the use of the addressee(s). Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of the original message. Gary Gregory (JIRA) wrote: [ https://issues.apache.org/jira/browse/LANG-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497532 ] Gary Gregory commented on LANG-335: --- Would Joda-TIme help here? Comparisons of Dates and Calendars to second precision -- Key: LANG-335 URL: https://issues.apache.org/jira/browse/LANG-335 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Environment: Windows, JDK 1.6.0, Eclipse 3.2 Reporter: Alex Marshall Priority: Trivial The o.a.c.lang.time.DateUtils should have functions for comparing dates and Calendars to only second precision instead of millisecond. The motivation for this is comparison of dates and Calendars in objects both before and after the objects have been committed to and retrieved from a database. In theory the objects should be equal if 'equals' is run on them, but in practice they are not because the date fields do not have exactly the same millisecond values after they've been persisted to a database since times in many databases are only maintained to second-level precision (and without TimeZone information in many cases, to boot!)
RE: [IO] Move to a minimum of JDK 1.4?
It seems like a nice coincidence that IO 1.3 is based on JRE 1.3, and we could have IO 1.4 based on JRE 1.4, IO 1.5 on JRE 1.5 ;) Thank you, Gary -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Friday, May 18, 2007 1:10 PM To: Jakarta Commons Developers List Subject: Re: [IO] Move to a minimum of JDK 1.4? On 5/15/07, Niall Pemberton [EMAIL PROTECTED] wrote: There are a couple of Jira tickets which require JDK 1.4 IO-74[1] - Regular Expression IOFileFilter implementation IO-77[2] - FileUtils.move() method that uses NIO Are there any objections to moving Commons IO's minimum requirement to JDK 1.4 for Commons IO 1.4? snip/ Sounds good. I've read the rest of the thread -- probably good to branch regardless of whether both lines are under active (evolutionary, in my mind) development or not. If someone shows up with desire to do a point / bugfix release for JDK 1.3 etc. -Rahul Niall [1] https://issues.apache.org/jira/browse/IO-74 [2] https://issues.apache.org/jira/browse/IO-77 - 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: [IO] Move to a minimum of JDK 1.4?
+1 here (Selfish POV: The product I work on now requires Java 1.4 already) Thank you, Gary -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 8:05 PM To: Jakarta Commons Developers List Subject: [IO] Move to a minimum of JDK 1.4? There are a couple of Jira tickets which require JDK 1.4 IO-74[1] - Regular Expression IOFileFilter implementation IO-77[2] - FileUtils.move() method that uses NIO Are there any objections to moving Commons IO's minimum requirement to JDK 1.4 for Commons IO 1.4? Niall [1] https://issues.apache.org/jira/browse/IO-74 [2] https://issues.apache.org/jira/browse/IO-77 - 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: RfC: Release commons-io-1.3.2
+1 to your +1; Release early, release often! Thank you, Gary -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 12:43 PM To: Jakarta Commons Developers List Subject: Re: RfC: Release commons-io-1.3.2 +1 to the idea. Release early, release often. On 5/16/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, the commons-io project has been rather silent in the last months, apart from IO-116. Unfortunately, this bug is a blocker for the next release of commons-fileupload. Therefore, I'd like to ask whether anyone would object a bug fix release 1.3.2? If noone intervenes, I'd start a formal vote, with me as the release manager. Thanks, Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - 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]
[jira] Commented: (LANG-329) Pointless synchronized in ThreadLocal.initialValue should be removed
[
https://issues.apache.org/jira/browse/LANG-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490375
]
Gary Gregory commented on LANG-329:
---
Before we sign off on this I'd like to know why it is pointless and why does
Sun recommend doing it the way the code was before this patch in their
documentation.
Please see:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ThreadLocal.html
If you are on 1.6+, you'd do it differently:
http://java.sun.com/javase/6/docs/api/java/lang/ThreadLocal.html
Pointless synchronized in ThreadLocal.initialValue should be removed
Key: LANG-329
URL: https://issues.apache.org/jira/browse/LANG-329
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.3
Environment: Any
Reporter: Hanson Char
Priority: Trivial
Fix For: 3.0
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
2007/01/27 07:13:59 500497
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
2007/04/20 05:06:03 530645
@@ -103,7 +103,7 @@
* /p
*/
private static ThreadLocal registry = new ThreadLocal() {
-protected synchronized Object initialValue() {
+protected Object initialValue() {
// The HashSet implementation is not synchronized,
// which is just what we need here.
return new HashSet();
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/HashCodeBuilder.java
2006/09/19 21:58:11 447989
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/HashCodeBuilder.java
2007/04/20 05:11:46 530648
@@ -103,7 +103,7 @@
* @since 2.3
*/
private static ThreadLocal registry = new ThreadLocal() {
-protected synchronized Object initialValue() {
+protected Object initialValue() {
// The HashSet implementation is not synchronized,
// which is just what we need here.
return new HashSet();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Commons HttpClient 3.1 RC1
Hi All: Any guesses on the release schedule? Thank you. Gary Gregory Senior Software Engineer Seagull Software [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] www.seagullsoftware.comhttp://www.seagullsoftware.com
RE: [VOTE] Lang 2.3 (RC3)
+1. Tested with: - Windows XP SP2 + current patches - Ant 1.6.5: ant clean dist test - Maven 1.0.2: maven clean site:generate - Sun Java 1.3.1_15 :ant ok - Sun Java 1.4.2_13: ant maven - Sun Java 1.5.0_10: ant maven - Sun Java 1.5.0_11: ant maven - Sun Java 1.6.0: ant ok Maven failures: - Sun Java 1.3.1_15 :ant ok, maven fails with a class file version 48.0 issue) - Sun Java 1.6.0: ank ok, maven fails with: xdoc:i18n-validation: [echo] Validation of the locale entries BUILD FAILED File.. C:\Documents and Settings\ggregory\.maven\cache\maven-xdoc-plugin-1.10\plugin.jelly Element... j:arg Line.. 666 Column 70 [Ljava.lang.Object; Total time: 5 minutes 26 seconds Finished at: Sun Feb 11 06:58:32 PST 2007 Thank you, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 12:51 PM To: Jakarta Commons Developers List Subject: [VOTE] Lang 2.3 (RC3) Here's the 3rd release candidate for Lang 2.3: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc3/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Difference from RC2 is that the sources and javadoc jars now have LICENSE/NOTICE files and the test for LANG-312 is commented out as it's still an open bug (and fails on some platforms). The pom.xml is NOT in the src bundle, because I forgot and I don't want to do all that again :) I'll make that change in svn now so it'll be in a future RC if one happens. 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: [VOTE] IO 1.3.1 (RC3)
The following worked for me: - Windows XP Pro SP2 + current patches - Sun Java 1.6.0, 1.5.0_10 and 1.4.2_13 - Ant 1.6.5 - Maven 1.0.2 - ant clean dist test - maven clean site:generate Gary -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Saturday, February 10, 2007 8:50 AM To: Jakarta Commons Developers List Subject: Re: [VOTE] IO 1.3.1 (RC3) Everything looks good, but I get the test failure below when building with both ant and maven. I am on Windows XP SP2. The problem occurred with JDK 1.5.0_09 and 1.6.0. Can anybody reproduce this? Oliver Testsuite: org.apache.commons.io.FileUtilsCleanDirectoryTestCase Tests run: 4, Failures: 1, Errors: 0, Time elapsed: 0,18 sec Testcase: testThrowsOnNullList(org.apache.commons.io.FileUtilsCleanDirectoryTestCase): FAILED expected IOException junit.framework.AssertionFailedError: expected IOException at org.apache.commons.io.FileUtilsCleanDirectoryTestCase.testThrowsOnNullList(Fil eUtilsCleanDirectoryTestCase.java:114) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl. java:25) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.jav a:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performActi on(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:634) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl. java:25) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Henri Yandell wrote: Going with RC3: http://people.apache.org/~bayard/commons-io/1.3.1-rc3/ The only change is that I've fixed the manifest to say 1.3.1 and not 1.3. [ ] +1 [ ] -1 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] IO 1.3.1 (RC3)
+1 Tested with: - Windows XP Pro SP2 + current patches - Sun Java 1.4.2_13 - Ant 1.6.5 - Maven 1.0.2 Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 5:44 PM To: Jakarta Commons Developers List Subject: [VOTE] IO 1.3.1 (RC3) Going with RC3: http://people.apache.org/~bayard/commons-io/1.3.1-rc3/ The only change is that I've fixed the manifest to say 1.3.1 and not 1.3. [ ] +1 [ ] -1 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]
[jira] Created: (IO-112) NPE in FileUtils.openOutputStream(File) when file has no parent in path.
NPE in FileUtils.openOutputStream(File) when file has no parent in path.
Key: IO-112
URL: https://issues.apache.org/jira/browse/IO-112
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 1.3
Environment: Sun Java 1.4.2_13.
Windows XP SP2 + current patches.
Eclipse 3.3M4.
Reporter: Gary Gregory
Assigned To: Gary Gregory
Fix For: 1.4
-Original Message-
From: deng xinzi [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 04, 2007 6:19 AM
To: commons-dev@jakarta.apache.org
Subject: [bug]commons-io 1.3 FileUtils.openOutputStream(File file)
NullPointException
FileUtils.openOutputStream(File file)
When the file = new File( abc.txt );
There will be a NullPointerException throw.
Cause
file = new File(abc.txt)
file.getParentFile() returns null.
So I suggest adding the null check code like this.
File parent = file.getParentFile();
if( parent != null ) { // ADD THIS!!!
if (parent.exists() == false) {
if (parent.mkdirs() == false) {
throw new IOException(File ' + file + ' could not be
created);
}
}
}
Xinzi ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-112) NPE in FileUtils.openOutputStream(File) when file has no parent in path.
[
https://issues.apache.org/jira/browse/IO-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved IO-112.
-
Resolution: Fixed
Fixed in SVN.
NPE in FileUtils.openOutputStream(File) when file has no parent in path.
Key: IO-112
URL: https://issues.apache.org/jira/browse/IO-112
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 1.3
Environment: Sun Java 1.4.2_13.
Windows XP SP2 + current patches.
Eclipse 3.3M4.
Reporter: Gary Gregory
Assigned To: Gary Gregory
Fix For: 1.4
-Original Message-
From: deng xinzi [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 04, 2007 6:19 AM
To: commons-dev@jakarta.apache.org
Subject: [bug]commons-io 1.3 FileUtils.openOutputStream(File file)
NullPointException
FileUtils.openOutputStream(File file)
When the file = new File( abc.txt );
There will be a NullPointerException throw.
Cause
file = new File(abc.txt)
file.getParentFile() returns null.
So I suggest adding the null check code like this.
File parent = file.getParentFile();
if( parent != null ) { // ADD THIS!!!
if (parent.exists() == false) {
if (parent.mkdirs() == false) {
throw new IOException(File ' + file + ' could not be
created);
}
}
}
Xinzi ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [bug]commons-io 1.3 FileUtils.openOutputStream(File file) NullPointException
Hello Xinzi:
I've created this JIRA ticket to track your issue:
[IO-112] NPE in FileUtils.openOutputStream(File) when file has no parent in
path.
http://issues.apache.org/jira/browse/IO-112
I've also committed a fix in SVN. You can rebuild from the SVN sources yourself
or wait for the next nightly build.
Thank you,
Gary
-Original Message-
From: deng xinzi [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 04, 2007 6:19 AM
To: commons-dev@jakarta.apache.org
Subject: [bug]commons-io 1.3 FileUtils.openOutputStream(File file)
NullPointException
FileUtils.openOutputStream(File file)
When the file = new File( abc.txt );
There will be a NullPointerException throw.
Cause
file = new File(abc.txt)
file.getParentFile() returns null.
So I suggest adding the null check code like this.
File parent = file.getParentFile();
if( parent != null ) { // ADD THIS!!!
if (parent.exists() == false) {
if (parent.mkdirs() == false) {
throw new IOException(File ' + file + ' could not be
created);
}
}
}
Xinzi ...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] IO 1.3 (RC2)
+1. Builds and tests successful on Windows XP Pro SP2 + current patches with: -Sun Java 1.4.2_13, Ant 1.6.5, Maven 1.0.2 -Sun Java 1.4.2_13, Ant 1.7.0, Maven 1.0.2 -Sun Java 1.5.0_10, Ant 1.6.5, Maven 1.0.2 -Sun Java 1.5.0_10, Ant 1.7.0, Maven 1.0.2 I used: ant clean dist test testjar and: maven site:generate Thank you, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 23, 2007 8:24 AM To: Jakarta Commons Developers List Subject: [VOTE] IO 1.3 (RC2) I've made a second release candidate of IO 1.3, tagged IO_1_3_RC2. Available at: http://people.apache.org/~bayard/commons-io/1.3-rc2/ Various build files, clirr/jardiff reports and the proposed site. [ ] +1 [ ] -1 Vote to end on Friday (if it makes it that far). 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: [sandbox] Using commons-skin for all components
Good idea, +1 here. Gary Dennis Lundberg wrote on Thursday, January 04, 2007 10:34 PM: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-309) Add ArrayUtils.addFirst methods.
Add ArrayUtils.addFirst methods. Key: LANG-309 URL: https://issues.apache.org/jira/browse/LANG-309 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.2 Reporter: Gary Gregory Priority: Minor Add ArrayUtils.addFirst methods? This is pretty trivial, implementation wise. I'd like some feedback before implementation. For example, is ArrayUtils.addFirst (array, newFirstElement); really better than: ArrayUtils.add(array, 0, newFirstElement); ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ang] pre 2.3 build
Hi All: The release notes state that [lang-69] is fixed, it is not. I do have a fix in progress but we should probably push this one back to 3.0 unless we want to delay 2.3. If we really want this one fix, I can take some time to complete this within a week or so. Thank you, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 5:37 PM To: Jakarta Commons Developers List Subject: [ang] pre 2.3 build Using: jvm 1.3 ant dist jvm 1.4 maven dist site I've built the following: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-SNAPSHOT/ Anything need fixing up before doing the real build? 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: [ang] pre 2.3 build
Hi: The release notes should state that [LANG-102] has been fixed. Thank you, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 5:37 PM To: Jakarta Commons Developers List Subject: [ang] pre 2.3 build Using: jvm 1.3 ant dist jvm 1.4 maven dist site I've built the following: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-SNAPSHOT/ Anything need fixing up before doing the real build? 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: [ang] pre 2.3 build
Hi Hen: The comment you quote is from https://issues.apache.org/jira/browse/LANG-279, not [LANG-102]. ;) Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 7:49 PM To: Jakarta Commons Developers List Subject: Re: [ang] pre 2.3 build You resolved that one as fixed saying: Fix already in CVS. Please see HashCodeBuilderTest#testReflectionObjectCycle(). Sounds like it needs to be reopened? Hen On 1/2/07, Gary Gregory [EMAIL PROTECTED] wrote: Hi All: The release notes state that [lang-69] is fixed, it is not. I do have a fix in progress but we should probably push this one back to 3.0 unless we want to delay 2.3. If we really want this one fix, I can take some time to complete this within a week or so. Thank you, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 5:37 PM To: Jakarta Commons Developers List Subject: [ang] pre 2.3 build Using: jvm 1.3 ant dist jvm 1.4 maven dist site I've built the following: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3- SNAPSHOT/ Anything need fixing up before doing the real build? 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] - 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: [ang] pre 2.3 build
Ah, I see now. I was looking at the Comments section, not the Change History. I think the comment I put in is connected to LANG-279 and somehow made it in here. I am not sure how it got in there. I'll reopen. Please accept my apologies for the confusion. Thank you, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 9:16 PM To: Jakarta Commons Developers List Subject: Re: [ang] pre 2.3 build Check LANG-69's Change History: Change by Gary Gregory [29/Sep/06 12:55 PM] StatusIn Progress [ 3 ] Resolved [ 5 ] ResolutionFixed [ 1 ] Change by Gary Gregory [29/Sep/06 01:48 PM] Comment [ Fix already in CVS. Please see HashCodeBuilderTest#testReflectionObjectCycle(). ] On 1/2/07, Gary Gregory [EMAIL PROTECTED] wrote: Hi Hen: The comment you quote is from https://issues.apache.org/jira/browse/LANG-279, not [LANG-102]. ;) Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 7:49 PM To: Jakarta Commons Developers List Subject: Re: [ang] pre 2.3 build You resolved that one as fixed saying: Fix already in CVS. Please see HashCodeBuilderTest#testReflectionObjectCycle(). Sounds like it needs to be reopened? Hen On 1/2/07, Gary Gregory [EMAIL PROTECTED] wrote: Hi All: The release notes state that [lang-69] is fixed, it is not. I do have a fix in progress but we should probably push this one back to 3.0 unless we want to delay 2.3. If we really want this one fix, I can take some time to complete this within a week or so. Thank you, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 5:37 PM To: Jakarta Commons Developers List Subject: [ang] pre 2.3 build Using: jvm 1.3 ant dist jvm 1.4 maven dist site I've built the following: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3- SNAPSHOT/ Anything need fixing up before doing the real build? 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] - 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]
[jira] Reopened: (LANG-69) [lang] ToStringBuilder throws StackOverflowError when an Object cycle exists
[
https://issues.apache.org/jira/browse/LANG-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory reopened LANG-69:
--
Reopening due to an incorrect note in the change history section about
HashCodeBuilder bug [lang-279].
[lang] ToStringBuilder throws StackOverflowError when an Object cycle exists
Key: LANG-69
URL: https://issues.apache.org/jira/browse/LANG-69
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1
Environment: Operating System: other
Platform: Other
Reporter: Maarten Coene
Assigned To: Gary Gregory
Fix For: 2.3
Attachments: 15938.patch, 36061.patch,
ReflectionToStringBuilder.java.patch, ToStringBuilderTest.java.patch,
ToStringStyle.java.patch
Hi,
The ToStringBuilder throws a StackOverflowError if you have a cycle in the
object graph. For instance, the following toString() method will cause a
StackOverflowError:
public class ObjectCycle {
Object obj;
public String toString() {
return new ToStringBuilder(this).append(obj).toString();
}
}
public void testObjectCycle() {
ObjectCycle a = new ObjectCycle();
ObjectCycle b = new ObjectCycle();
a.obj = b;
b.obj = a;
a.toString(); // ouch: StackOverflowError
}
I'll submit some patches that fixes this problem...
regards,
Maarten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-102) [lang] Refactor Entities methods
[ http://issues.apache.org/jira/browse/LANG-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461655 ] Gary Gregory commented on LANG-102: --- Refactored escape and unescape methods to remove code duplication. [lang] Refactor Entities methods Key: LANG-102 URL: http://issues.apache.org/jira/browse/LANG-102 Project: Commons Lang Issue Type: Bug Affects Versions: 3.0 Environment: Operating System: other Platform: Other Reporter: Henri Yandell Fix For: 3.0 Attachments: Entities.java.patch, Entries.java.patch The pairs of escape and unescape methods in Entities need to be modified so that they call each other (one escape to the other escape etc). Otherwise there's a large chunk of repeated code that gives us a high chance of errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-102) [lang] Refactor Entities methods
[ http://issues.apache.org/jira/browse/LANG-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-102: -- Fix Version/s: (was: 3.0) 2.3 Affects Version/s: (was: 3.0) 2.2 [lang] Refactor Entities methods Key: LANG-102 URL: http://issues.apache.org/jira/browse/LANG-102 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Environment: Operating System: other Platform: Other Reporter: Henri Yandell Fix For: 2.3 Attachments: Entities.java.patch, Entries.java.patch The pairs of escape and unescape methods in Entities need to be modified so that they call each other (one escape to the other escape etc). Otherwise there's a large chunk of repeated code that gives us a high chance of errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-102) [lang] Refactor Entities methods
[ http://issues.apache.org/jira/browse/LANG-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461656 ] Gary Gregory commented on LANG-102: --- FWIW, I could not use the attached patch files. They appear to be too old to match against what was in SVN. So I refactored from scratch, no biggie. [lang] Refactor Entities methods Key: LANG-102 URL: http://issues.apache.org/jira/browse/LANG-102 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Environment: Operating System: other Platform: Other Reporter: Henri Yandell Fix For: 2.3 Attachments: Entities.java.patch, Entries.java.patch The pairs of escape and unescape methods in Entities need to be modified so that they call each other (one escape to the other escape etc). Otherwise there's a large chunk of repeated code that gives us a high chance of errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LANG-102) [lang] Refactor Entities methods
[ http://issues.apache.org/jira/browse/LANG-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LANG-102. --- Resolution: Fixed committed. [lang] Refactor Entities methods Key: LANG-102 URL: http://issues.apache.org/jira/browse/LANG-102 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Environment: Operating System: other Platform: Other Reporter: Henri Yandell Fix For: 2.3 Attachments: Entities.java.patch, Entries.java.patch The pairs of escape and unescape methods in Entities need to be modified so that they call each other (one escape to the other escape etc). Otherwise there's a large chunk of repeated code that gives us a high chance of errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [io] svn commit: r491668 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Hi All: Interesting and I do see your POV. IMO, it also depends on what tools you use do to your work. I use the Eclipse Javadoc view which presents the Javadoc comment in a formatted HTML view. I never bother to use the source of Javadocs to understand what the comments say as there usually is too much meta information, [EMAIL PROTECTED] and [EMAIL PROTECTED], to really make reading easy. I guess it comes down to how you want to present each [project] to the outside world. Since I find the Sun JRE Javadoc usually pretty poor, in general, I do like to make my Java comments more technically detailed and prettier. Feel free to replace all codenull/code with null ;) Thank you, Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, January 01, 2007 5:36 PM To: Jakarta Commons Developers List Subject: Re: [io] svn commit: r491668 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtil s. java I'll be honest and say I dislike the convention of using code for null, as as such I'm not greatly enthused by this change. I'd prefer if no more files were changed. This comes down to my basic tenet that javadoc is for developers to read, and it is *frequently* read as source code, not as an HTML page. Adding the code makes its *much* more difficult for someone to read the text. And its the text that matters. Just read the two lines below and decide which is easier to read and extract meaning from. In addition, since every Java programmer knows that null is a reserved word, I really don't see what is gained by highlighting it. Stephen [EMAIL PROTECTED] wrote: Author: ggregory Date: Mon Jan 1 14:45:49 2007 New Revision: 491668 URL: http://svn.apache.org/viewvc?view=revrev=491668 Log: Add missing Javadoc tags. Use null is code format (codenull/code) - * @param file the file to open for input, not null + * @param file the file to open for input, must not be codenull/code - 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]
[jira] Commented: (LANG-284) TextTable for printing a fixedlength columns format text tables
[ http://issues.apache.org/jira/browse/LANG-284?page=comments#action_12461425 ] Gary Gregory commented on LANG-284: --- I agree with Stephen [http://issues.apache.org/jira/browse/LANG-284#action_12461421], this sounds complicated enough and would need enough parameters and customizable features to make it its own component. TextTable for printing a fixedlength columns format text tables --- Key: LANG-284 URL: http://issues.apache.org/jira/browse/LANG-284 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.2 Reporter: David Leal Fix For: 3.0 Attachments: TestTextTable.java, TestTextTable.out, TextTable.java Just to suggest adding a TextTable class for printing in text (ASCII) format fixed columns table. It is usefull for printing information from command line application, that informs about directly on DOS Windows of Xterm direclty. I am adding a patch a possible solution for that, Thanks, David -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections-generics] [PROPOSAL] Remove all author and since version tags
-Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, November 04, 2006 3:01 AM To: Jakarta Commons Developers List Subject: [collections-generics] [PROPOSAL] Remove all author and since version tags As this is a 'new' project, I propose that we: - remove all @author tags - this complies with previous ASF board suggestions +1 - remove all @since tags - as its incompatible anyway, and will probably end up in a separate package, these have no real meaning If the plan is to put code that now has @since in a packages, then +1. Any dissenting opinions? First commits on this topic won't be until after 18th November 2006. 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]
[jira] Commented: (LANG-291) Null-safe comparison methods for finding most recent / least recent dates.
[ http://issues.apache.org/jira/browse/LANG-291?page=comments#action_12446052 ] Gary Gregory commented on LANG-291: --- How about following the naming from Math.min() and Math.max(): public static Date min(Date date1, Date date2); public static Date max(Date date1, Date date2); Alternatively, when I read 'Returnes [sic] the least recent (oldest), why not call the methods oldest() and newest() Null-safe comparison methods for finding most recent / least recent dates. -- Key: LANG-291 URL: http://issues.apache.org/jira/browse/LANG-291 Project: Commons Lang Issue Type: Improvement Environment: N/A Reporter: David J. M. Karlsen Fix For: 3.0 Attachments: DateUtils-patch-rev468924.txt /** * p * Null-safe date comparison. * Returnes the most recent date if date1 and date2 is non-null. * If one of the dates are null, the non-null will be returned. * If both are null, null will be returned. * /p * @param date1 * @param date2 * @return */ public static Date mostRecent( Date date1, Date date2 ) /** * p * Null-safe date comparison. * Returnes the least recent (oldest) date if date1 and date2 is non-null. * If one of the dates are null, the non-null will be returned. * If both are null, null will be returned. * /p * @param date1 * @param date2 * @return */ public static Date leastRecent( Date date1, Date date2 ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Major versions require package name change
In my mind, name vs. name2 makes sense seems for a next generation based on new code rather than a next version. Thank you, Gary -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sandy McArthur Sent: Monday, October 30, 2006 9:41 AM To: Jakarta Commons Developers List Subject: Re: [PROPOSAL] Major versions require package name change On 10/29/06, Stephen Colebourne [EMAIL PROTECTED] wrote: PROPOSAL: The major version number of a component, where it is greater than 1, shall be included in the package name. I gotta disagree with this. If we want to come up with the notion of a super version, something that is more broad than a major version and includes non-backwards compatible changes I'm fine with that. But mandating that any major release be completely non-backwards compatible is silly. Occasional drastic pruning of code is needed to keep it healthy and manageable. But we should not be eager to run out and break compatibility without deliberate and compelling reasons. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - 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: [codec]Implementing support for additional non-english vowels in double metaphone
Hello: Steinar: The current DoubleMetaphone implementation (released and SVN) allows for Spanish and Germanic characters, so adding support for other languages in the same class seems to be in the spirit of the current implementation. I would also say that having language-specific implementation sure sounds like a reasonable idea. I wonder if there are some performance issues with the current implementation attempting to work for all languages. It seems like a bigger topic though and might be worth discussing separately if the list is interested. So I would say: Create a JIRA ticket [1] Go ahead and submit patches [2] for the code *and* unit tests based on the SVN code [3]. Thank you, Gary [1] https://issues.apache.org/jira/browse/CODEC [2] http://jakarta.apache.org/commons/patches.html [3] http://jakarta.apache.org/commons/codec/cvs-usage.html -Original Message- From: Steinar Cook [mailto:[EMAIL PROTECTED] Sent: Monday, October 23, 2006 1:35 PM To: commons-dev@jakarta.apache.org Subject: [codec]Implementing support for additional non-english vowels in double metaphone I have made some modifications to org.apache.commons.codec.language.DoubleMetaphone in order to support the three additional Norwegian and Danish vowels. The current implementation at Jakarta does not provide any methods to specify the language of the input text. Is it all right to modify DoubleMetaphone to support the Scandinavian vowels (Swedish, Danish and Norwegian) and possibly other languages or have I completely misunderstood the idea behind the double metaphone algorithm? That is, should double metaphone detect various language constructs automatically or is it perhaps a better idea to have a factory which returns a double metaphone implementation appropriate for the language? Any suggestions? I would like to contribute any changes back to Jakarta commons-codec, of course. Steinar Cook [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]
[jira] Commented: (LANG-284) TextTable for printing a fixedlength columns format text tables
[ http://issues.apache.org/jira/browse/LANG-284?page=comments#action_12444550 ] Gary Gregory commented on LANG-284: --- I think we are going towards a whole new .table package. I like the idea of a table model with an XML and HTML writer classes on the side. TableModel, XmlTableWriter, HtmlTableWriter. As soon as you say HTML, I am thinking that XML is enough since I can just apply an XSLT later. Opening the door to colors, fonts, borders, etc seems like a big job. You'd also might want a TableColumn class to hold name, data type, etc. TextTable for printing a fixedlength columns format text tables --- Key: LANG-284 URL: http://issues.apache.org/jira/browse/LANG-284 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.2 Reporter: David Leal Fix For: 3.0 Attachments: TestTextTable.java, TestTextTable.out, TextTable.java Just to suggest adding a TextTable class for printing in text (ASCII) format fixed columns table. It is usefull for printing information from command line application, that informs about directly on DOS Windows of Xterm direclty. I am adding a patch a possible solution for that, Thanks, David -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] 3.0 as next release? JDK 1.5 minimum?
Hello [lang]: For the software I work on, Java 1.4.2 is the base requirement, so talking about 1.5 is not an option (yet). We revisit the issue from time to time, but the bottom line is that our customers have not moved to Java 1.5, so we cannot. We could do this in a first stage and say that [lang] 3.0 requires Java 1.4, and [lang] 4.0 requires 1.5. Or maybe sync the [lang] major version to the Java minor (or major depending on how you like your Java versions): lang 4.0 + Java 1.4l; lang 5.0 paired with Java 1.5, etc. I do like moving up the requirement to Java 1.4 and take advantage anything there before moving on. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 12:06 PM To: Jakarta Commons Developers List Subject: [lang] 3.0 as next release? JDK 1.5 minimum? Starting to think about the next Lang release. 2.3 had a few Enum issues to look at. LANG-76 - Complex issue in initializing under JDK 1.5. LANG-262 - ClassLoader issue. Possible fix committed, but no testing done yet. LANG-258 - Improve Enum javadoc. I've been doing some work on this. There were a couple of other ones, but I've moved them over to 3.0. One of them implied functionality change that would better fit a maj release and the other was concerning test improvements. There are 5 issues resolved in 2.3 currently. These would be moved to 3.0. Now for the argument-inducing part: I think Lang 3.0 should have JDK 1.5 as a minimum. This allows us to focus on adding improvements to features in JDK 1.3-1.5, and we would also cleanup by deleting deprecated classes/packages. LANG-76 and LANG-258 both are 1.5 focused, so they'd fit quite happily there. LANG-262 hasn't had any feedback, so I'm in no rush to push it through. So the biggest issue is whether the 5 resolved issues need to be released earlier. Two are enhancements to StringUtils, so not important. The other three are bugs - one in DurationFormatUtils and the others in cyclic object handling in the builder package. They could be backported to a 2.2.1 release(?). Any thoughts? 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]
[jira] Commented: (LANG-287) Optimize StringEscapeUtils.unescapeXml(String)
[
http://issues.apache.org/jira/browse/LANG-287?page=comments#action_12443559 ]
Gary Gregory commented on LANG-287:
---
The problem with this idea is that when there _is_ something to escape, this
would cause the performance penality of scanning the input from start to finish
with 0 gain.
The general case is to unescape. If you know your application does not need
this 80% of the time, the test can be put in your call site.
Optimize StringEscapeUtils.unescapeXml(String)
--
Key: LANG-287
URL: http://issues.apache.org/jira/browse/LANG-287
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Stepan Koltsov
Priority: Minor
StringEscapeUtils.unescapeXml(String) (and other unescaes) works too slowly
if String has nothing to unescape, that is very common situation.
To make unescape faster, following check should be added to be start of
Entities.unescape(str)
if (str.indexOf('') 0)
return str;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-285) Wish : method unaccent
[ http://issues.apache.org/jira/browse/LANG-285?page=comments#action_12442938 ] Gary Gregory commented on LANG-285: --- Please see the Java 6 implementation for: http://download.java.net/jdk6/doc/api/java/text/Normalizer.html I think that going the unicode route is correct instead of an exhaustive list of characters in the code which is bound to be error prone. Wish : method unaccent -- Key: LANG-285 URL: http://issues.apache.org/jira/browse/LANG-285 Project: Commons Lang Issue Type: New Feature Reporter: Guillaume Coté Priority: Minor I would like to add a method that replace accented caracter by unaccented one. For example, with the input String L'été où j'ai dû aller à l'île d'Anticosti commenca tôt, the method would return L'ete ou j'ai du aller à l'ile d'Anticosti commenca tot. I suggest to call that method unaccent and to add it in StringUtils. If we cannot covert all case, the first version could only covert iso-8859-1. If you are willing to go forward with that idea, I am willing to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CODEC-53) build.xml dist target refers to ../LICENSE
[ http://issues.apache.org/jira/browse/CODEC-53?page=comments#action_12442740 ] Gary Gregory commented on CODEC-53: --- I just performed: ant clean dist with the latest from SVN and all is well (BUILD SUCCESSFUL.) Please reopen if can reproduce from current SVN sources. build.xml dist target refers to ../LICENSE Key: CODEC-53 URL: http://issues.apache.org/jira/browse/CODEC-53 Project: Commons Codec Issue Type: Bug Affects Versions: 1.3 Environment: Cygwin 1.5.21(0.156/4/2) 2006-07-30 14:21 i686 Cygwin But probably applicable to any system Reporter: Max Polk Priority: Minor The source distribution for commons-codec-1.3/build.xml file has a dist and jar targets that refer to ../LICENSE which does not exist. Therefore, an ant dist build fails at the copy tasks that refer to this missing file one directory *back* from the unpacked commons-codec-1.3 directory, such as: BUILD FAILED C:\Apps\Libraries\Java\commons-codec-1.3\build.xml:93: Warning: Could not find file C:\Apps\Libraries\Java\LICENSE to copy. Please (1) include the LICENSE file itself in commons-codec-1.3 directory, and then (2) fix lines 93 and 100 of build.xml to refer to LICENSE and not ../LICENSE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-53) build.xml dist target refers to ../LICENSE
[ http://issues.apache.org/jira/browse/CODEC-53?page=all ] Gary Gregory updated CODEC-53: -- Fix Version/s: Nightly Builds build.xml dist target refers to ../LICENSE Key: CODEC-53 URL: http://issues.apache.org/jira/browse/CODEC-53 Project: Commons Codec Issue Type: Bug Affects Versions: 1.3 Environment: Cygwin 1.5.21(0.156/4/2) 2006-07-30 14:21 i686 Cygwin But probably applicable to any system Reporter: Max Polk Priority: Minor Fix For: Nightly Builds The source distribution for commons-codec-1.3/build.xml file has a dist and jar targets that refer to ../LICENSE which does not exist. Therefore, an ant dist build fails at the copy tasks that refer to this missing file one directory *back* from the unpacked commons-codec-1.3 directory, such as: BUILD FAILED C:\Apps\Libraries\Java\commons-codec-1.3\build.xml:93: Warning: Could not find file C:\Apps\Libraries\Java\LICENSE to copy. Please (1) include the LICENSE file itself in commons-codec-1.3 directory, and then (2) fix lines 93 and 100 of build.xml to refer to LICENSE and not ../LICENSE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CODEC-53) build.xml dist target refers to ../LICENSE
[ http://issues.apache.org/jira/browse/CODEC-53?page=all ] Gary Gregory resolved CODEC-53. --- Resolution: Fixed build.xml dist target refers to ../LICENSE Key: CODEC-53 URL: http://issues.apache.org/jira/browse/CODEC-53 Project: Commons Codec Issue Type: Bug Affects Versions: 1.3 Environment: Cygwin 1.5.21(0.156/4/2) 2006-07-30 14:21 i686 Cygwin But probably applicable to any system Reporter: Max Polk Priority: Minor Fix For: Nightly Builds The source distribution for commons-codec-1.3/build.xml file has a dist and jar targets that refer to ../LICENSE which does not exist. Therefore, an ant dist build fails at the copy tasks that refer to this missing file one directory *back* from the unpacked commons-codec-1.3 directory, such as: BUILD FAILED C:\Apps\Libraries\Java\commons-codec-1.3\build.xml:93: Warning: Could not find file C:\Apps\Libraries\Java\LICENSE to copy. Please (1) include the LICENSE file itself in commons-codec-1.3 directory, and then (2) fix lines 93 and 100 of build.xml to refer to LICENSE and not ../LICENSE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CODEC-51) 2 Test failures in SoundexTest
[ http://issues.apache.org/jira/browse/CODEC-51?page=comments#action_12442744 ] Gary Gregory commented on CODEC-51: --- Tests pass for me with SVN sources and *Ant 1.6.5* on *Windows XP SP2+patches* with: - Sun Java 1.4.2_12 - Sun Java 1.5.0_09 2 Test failures in SoundexTest -- Key: CODEC-51 URL: http://issues.apache.org/jira/browse/CODEC-51 Project: Commons Codec Issue Type: Bug Environment: Debian Linux, JDK 1.4.2 and 1.6 Reporter: Henri Yandell Fix For: 1.4 Testsuite: org.apache.commons.codec.language.SoundexTest Tests run: 25, Failures: 2, Errors: 0, Time elapsed: 0.907 sec Testcase: testUsMappingOWithDiaeresis(org.apache.commons.codec.language.SoundexTest): FAILED expected:?000 but was: junit.framework.ComparisonFailure: expected:?000 but was: at org.apache.commons.codec.language.SoundexTest.testUsMappingOWithDiaeresis(SoundexTest.java:349) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testUsMappingEWithAcute(org.apache.commons.codec.language.SoundexTest): FAILED expected:?000 but was: junit.framework.ComparisonFailure: expected:?000 but was: at org.apache.commons.codec.language.SoundexTest.testUsMappingEWithAcute(SoundexTest.java:364) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CODEC-40) [codec] Patch to add crypto-compatible BigInteger encoding support to Base64
[ http://issues.apache.org/jira/browse/CODEC-40?page=comments#action_12442748 ] Gary Gregory commented on CODEC-40: --- I think it would be nice to have the tests and unit tests cover some simple and edge cases: null, -1, 0, 1 as well as bogus byte arrays. A senisble error should be throws NullArgumentException, Illegal ArgumentException, etc. [codec] Patch to add crypto-compatible BigInteger encoding support to Base64 Key: CODEC-40 URL: http://issues.apache.org/jira/browse/CODEC-40 Project: Commons Codec Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Chris Black Priority: Minor Fix For: 1.4 Attachments: addCryptoIntegerCoding There are crypto standards that require large integers for keys to be encoded in base64 with some special caveats (no sign bit, padding, etc). One of the standards that requires this is the w3c's XML-Signature standard. This patch adds this support along with junit tests. This code is taken from the Apache XML Security project's own Base64 class and changed to be more readable and add junit tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-285) Wish : method unaccent
[ http://issues.apache.org/jira/browse/LANG-285?page=comments#action_12442447 ] Gary Gregory commented on LANG-285: --- There is a more Unicode way to do this as is outlined in this discussion: http://forum.java.sun.com/thread.jspa?threadID=728423tstart=135 From what I can tell, you can ask Unicode for the base (=unaccented) version of a given character. I sounds like sun.text.Normalizer will be made public in Java 6. Wish : method unaccent -- Key: LANG-285 URL: http://issues.apache.org/jira/browse/LANG-285 Project: Commons Lang Issue Type: New Feature Reporter: Guillaume Coté Priority: Minor I would like to add a method that replace accented caracter by unaccented one. For example, with the input String L'été où j'ai dû aller à l'île d'Anticosti commenca tôt, the method would return L'ete ou j'ai du aller à l'ile d'Anticosti commenca tot. I suggest to call that method unaccent and to add it in StringUtils. If we cannot covert all case, the first version could only covert iso-8859-1. If you are willing to go forward with that idea, I am willing to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][lang] Commons Lang 2.2-rc3
How are we doing with the release? Any blockers? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, September 29, 2006 11:19 AM To: Jakarta Commons Developers List Subject: Re: [VOTE][lang] Commons Lang 2.2-rc3 Looks like it is due to a javadoc plugin bug when sourceModifications is set. Being of a suspicious mind, I dug into why we have a modification for 'FakeClass'. We don't have a class with that name, so suspicion increases. Looks like it snuck in from Dion's trunk when he applied a large patch from Carlos a long time back (https://issues.apache.org/jira/browse/COMMONSSITE-2). I've removed it and tested and things look good. I'll end the vote next Wednesday morning and release then. Hen On 9/27/06, Niall Pemberton [EMAIL PROTECTED] wrote: +1 from me. The distros look good - but the javadocs in the website are missing the package descriptions - the javadocs in the binary distro are fine though. Niall On 9/27/06, Henri Yandell [EMAIL PROTECTED] wrote: Another try to get it right :) http://people.apache.org/~bayard/commons-lang-2.2-rc3/ (ignoring the various javadoc symlinking I'll need to do before the real site release) [ ] +1 [ ] -1 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LANG-69) [lang] ToStringBuilder throws StackOverflowError when an Object cycle exists
[ http://issues.apache.org/jira/browse/LANG-69?page=all ]
Gary Gregory resolved LANG-69.
--
Resolution: Fixed
[lang] ToStringBuilder throws StackOverflowError when an Object cycle exists
Key: LANG-69
URL: http://issues.apache.org/jira/browse/LANG-69
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1
Environment: Operating System: other
Platform: Other
Reporter: Maarten Coene
Assigned To: Gary Gregory
Fix For: 2.3
Attachments: 15938.patch, 36061.patch,
ReflectionToStringBuilder.java.patch, ToStringBuilderTest.java.patch,
ToStringStyle.java.patch
Hi,
The ToStringBuilder throws a StackOverflowError if you have a cycle in the
object graph. For instance, the following toString() method will cause a
StackOverflowError:
public class ObjectCycle {
Object obj;
public String toString() {
return new ToStringBuilder(this).append(obj).toString();
}
}
public void testObjectCycle() {
ObjectCycle a = new ObjectCycle();
ObjectCycle b = new ObjectCycle();
a.obj = b;
b.obj = a;
a.toString(); // ouch: StackOverflowError
}
I'll submit some patches that fixes this problem...
regards,
Maarten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-69) [lang] ToStringBuilder throws StackOverflowError when an Object cycle exists
[
http://issues.apache.org/jira/browse/LANG-69?page=comments#action_12438787 ]
Gary Gregory commented on LANG-69:
--
Fix already in CVS.
Please see HashCodeBuilderTest#testReflectionObjectCycle().
[lang] ToStringBuilder throws StackOverflowError when an Object cycle exists
Key: LANG-69
URL: http://issues.apache.org/jira/browse/LANG-69
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1
Environment: Operating System: other
Platform: Other
Reporter: Maarten Coene
Assigned To: Gary Gregory
Fix For: 2.3
Attachments: 15938.patch, 36061.patch,
ReflectionToStringBuilder.java.patch, ToStringBuilderTest.java.patch,
ToStringStyle.java.patch
Hi,
The ToStringBuilder throws a StackOverflowError if you have a cycle in the
object graph. For instance, the following toString() method will cause a
StackOverflowError:
public class ObjectCycle {
Object obj;
public String toString() {
return new ToStringBuilder(this).append(obj).toString();
}
}
public void testObjectCycle() {
ObjectCycle a = new ObjectCycle();
ObjectCycle b = new ObjectCycle();
a.obj = b;
b.obj = a;
a.toString(); // ouch: StackOverflowError
}
I'll submit some patches that fixes this problem...
regards,
Maarten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-69) [lang] ToStringBuilder throws StackOverflowError when an Object cycle exists
[ http://issues.apache.org/jira/browse/LANG-69?page=all ]
Gary Gregory updated LANG-69:
-
Comment: was deleted
[lang] ToStringBuilder throws StackOverflowError when an Object cycle exists
Key: LANG-69
URL: http://issues.apache.org/jira/browse/LANG-69
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1
Environment: Operating System: other
Platform: Other
Reporter: Maarten Coene
Assigned To: Gary Gregory
Fix For: 2.3
Attachments: 15938.patch, 36061.patch,
ReflectionToStringBuilder.java.patch, ToStringBuilderTest.java.patch,
ToStringStyle.java.patch
Hi,
The ToStringBuilder throws a StackOverflowError if you have a cycle in the
object graph. For instance, the following toString() method will cause a
StackOverflowError:
public class ObjectCycle {
Object obj;
public String toString() {
return new ToStringBuilder(this).append(obj).toString();
}
}
public void testObjectCycle() {
ObjectCycle a = new ObjectCycle();
ObjectCycle b = new ObjectCycle();
a.obj = b;
b.obj = a;
a.toString(); // ouch: StackOverflowError
}
I'll submit some patches that fixes this problem...
regards,
Maarten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] LANG-279 HashCodeBuilder
Is SVN down? I am getting the following error: Gary Problems reported while synchronizing SVNStatusSubscriber. 0 of 1 resources were synchronized. An error occurred synchronizing /Apache Jakarta Commons trunks-proper/lang: Error getting status for resource F/Apache Jakarta Commons trunks-proper/lang org.tigris.subversion.javahl.ClientException: RA layer request failed svn: PROPFIND request failed on '/repos/asf/jakarta/commons/proper/lang/trunk' svn: PROPFIND of '/repos/asf/jakarta/commons/proper/lang/trunk': could not connect to server (https://svn.apache.org) Error getting status for resource F/Apache Jakarta Commons trunks-proper/lang org.tigris.subversion.javahl.ClientException: RA layer request failed svn: PROPFIND request failed on '/repos/asf/jakarta/commons/proper/lang/trunk' svn: PROPFIND of '/repos/asf/jakarta/commons/proper/lang/trunk': could not connect to server (https://svn.apache.org) org.tigris.subversion.javahl.ClientException: RA layer request failed svn: PROPFIND request failed on '/repos/asf/jakarta/commons/proper/lang/trunk' svn: PROPFIND of '/repos/asf/jakarta/commons/proper/lang/trunk': could not connect to server (https://svn.apache.org) org.tigris.subversion.javahl.ClientException: RA layer request failed svn: PROPFIND request failed on '/repos/asf/jakarta/commons/proper/lang/trunk' svn: PROPFIND of '/repos/asf/jakarta/commons/proper/lang/trunk': could not connect to server (https://svn.apache.org) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][lang] Commons Lang 2.2-rc3
Hello: For the site, I think that under Project Reports, the item Cobertura is a bad idea because it does not describe what it is but rather how it was created. I care to find the Test Coverage report but I do not need to know the particular technology that was used in the heading. 2c, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 27, 2006 10:42 AM To: Jakarta Commons Developers List Subject: [VOTE][lang] Commons Lang 2.2-rc3 Another try to get it right :) http://people.apache.org/~bayard/commons-lang-2.2-rc3/ (ignoring the various javadoc symlinking I'll need to do before the real site release) [ ] +1 [ ] -1 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: [VOTE][lang] Commons Lang 2.2-rc3
Hi: I wish you had not deleted the RC2 because it feels like the errors listed on: http://people.apache.org/~bayard/commons-lang-2.2-rc3/site/checkstyle-re port.html for: org/apache/commons/lang/SerializationUtils.java were not present in RC2. Am I dreaming? (on this topic ;) Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 27, 2006 10:42 AM To: Jakarta Commons Developers List Subject: [VOTE][lang] Commons Lang 2.2-rc3 Another try to get it right :) http://people.apache.org/~bayard/commons-lang-2.2-rc3/ (ignoring the various javadoc symlinking I'll need to do before the real site release) [ ] +1 [ ] -1 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: [VOTE][lang] Commons Lang 2.2-rc3
Ack, let's not mess with it at this point then. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 27, 2006 12:29 PM To: Jakarta Commons Developers List Subject: Re: [VOTE][lang] Commons Lang 2.2-rc3 It's a maven generated page though - so not something that is too desirable to mess with. From their point of view, someone could have Cobertura, Clover and JCoverage reports on the same page so you couldn't call each one of them Test Coverage. Hen On 9/27/06, Gary Gregory [EMAIL PROTECTED] wrote: Hello: For the site, I think that under Project Reports, the item Cobertura is a bad idea because it does not describe what it is but rather how it was created. I care to find the Test Coverage report but I do not need to know the particular technology that was used in the heading. 2c, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 27, 2006 10:42 AM To: Jakarta Commons Developers List Subject: [VOTE][lang] Commons Lang 2.2-rc3 Another try to get it right :) http://people.apache.org/~bayard/commons-lang-2.2-rc3/ (ignoring the various javadoc symlinking I'll need to do before the real site release) [ ] +1 [ ] -1 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] - 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][lang] Commons Lang 2.2-rc3
Our application builds and all tests pass with this version. +1. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 27, 2006 10:42 AM To: Jakarta Commons Developers List Subject: [VOTE][lang] Commons Lang 2.2-rc3 Another try to get it right :) http://people.apache.org/~bayard/commons-lang-2.2-rc3/ (ignoring the various javadoc symlinking I'll need to do before the real site release) [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] [VOTE] Release 2.2 RC2
What's left on the to-do list for the next RC? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 11:36 AM To: Jakarta Commons Developers List Subject: [lang] [VOTE] Release 2.2 RC2 I've rolled an RC2, and based on the comments for RC1 it seems like it's worth taking a stab at a release vote on this one. The relevant files are available at: http://people.apache.org/~bayard/commons-lang-2.2-rc2/ [ ] +1 [ ] -1 Thanks, 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: [lang] [VOTE] Release 2.2 RC2
About the mention that one file was duplicated in the jar file. This is the default Jar behavior of Ant. From the Ant manual: duplicate behavior when a duplicate file is found. Valid values are add, preserve, and fail. The default value is add. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 11:36 AM To: Jakarta Commons Developers List Subject: [lang] [VOTE] Release 2.2 RC2 I've rolled an RC2, and based on the comments for RC1 it seems like it's worth taking a stab at a release vote on this one. The relevant files are available at: http://people.apache.org/~bayard/commons-lang-2.2-rc2/ [ ] +1 [ ] -1 Thanks, 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: [lang] [VOTE] Release 2.2 RC2
This page does not contain any real info: http://people.apache.org/~bayard/commons-lang-2.2-rc2/docs/upgradeto2_2. html gg -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 11:36 AM To: Jakarta Commons Developers List Subject: [lang] [VOTE] Release 2.2 RC2 I've rolled an RC2, and based on the comments for RC1 it seems like it's worth taking a stab at a release vote on this one. The relevant files are available at: http://people.apache.org/~bayard/commons-lang-2.2-rc2/ [ ] +1 [ ] -1 Thanks, 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: [lang] [VOTE] Release 2.2 RC2
FWIW, I noticed that maven-javadoc-plugin version 1.7 was used to generate the Javadocs. The current version is 1.8. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 11:36 AM To: Jakarta Commons Developers List Subject: [lang] [VOTE] Release 2.2 RC2 I've rolled an RC2, and based on the comments for RC1 it seems like it's worth taking a stab at a release vote on this one. The relevant files are available at: http://people.apache.org/~bayard/commons-lang-2.2-rc2/ [ ] +1 [ ] -1 Thanks, 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: [lang] [VOTE] Release 2.2 RC2
Aside from that, our application builds and all tests pass, so +1 from here. Gary -Original Message- From: Gary Gregory Sent: Friday, September 22, 2006 2:27 PM To: 'Jakarta Commons Developers List' Subject: RE: [lang] [VOTE] Release 2.2 RC2 This page does not contain any real info: http://people.apache.org/~bayard/commons-lang-2.2- rc2/docs/upgradeto2_2.html gg -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 11:36 AM To: Jakarta Commons Developers List Subject: [lang] [VOTE] Release 2.2 RC2 I've rolled an RC2, and based on the comments for RC1 it seems like it's worth taking a stab at a release vote on this one. The relevant files are available at: http://people.apache.org/~bayard/commons-lang-2.2-rc2/ [ ] +1 [ ] -1 Thanks, 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: [lang] 2.2 RC1 rolled and ready for comments
I notice that the code coverage report was generated use Cobertura version 1.6. How about migrating to the current version 1.8? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 9:41 PM To: Jakarta Commons Developers List Subject: [lang] 2.2 RC1 rolled and ready for comments I've gone ahead and done a first release candidate for 2.2. http://people.apache.org/~bayard/commons-lang/ Anyone have anything before I kick off a vote? -- Bear in mind that to allow us to keep momentum with 2.3, I've created a branch for Lang 2.2: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LA N G_2_2_X 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: [lang] 2.2 RC1 rolled and ready for comments
Our application builds and all tests pass with 2.2-rc1. So, that's +1. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 9:41 PM To: Jakarta Commons Developers List Subject: [lang] 2.2 RC1 rolled and ready for comments I've gone ahead and done a first release candidate for 2.2. http://people.apache.org/~bayard/commons-lang/ Anyone have anything before I kick off a vote? -- Bear in mind that to allow us to keep momentum with 2.3, I've created a branch for Lang 2.2: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LA N G_2_2_X 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: [lang] 2.2 RC1 rolled and ready for comments
- The release notes mentions changes from 2.0 to 2.1, which it probably shouldn't. Personally, I like having the entire release history. When I upgrade some old component and I am skipping a version, I like to know what I am getting, not just what is in the latest. - the jar is getting a little porky, at nearly 250K. This is not an issue for me. I certainly would not want 1 jar. Do we compress the jar in the build? I'd even like to have a single commons jar! Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 2:23 PM To: Jakarta Commons Developers List Subject: Re: [lang] 2.2 RC1 rolled and ready for comments - Should we be using viewcvs.cgi still now we are on svn? Or is there a viewvc.cgi? - Tasks xdoc needs Stringbuf removing. - The release notes mentions changes from 2.0 to 2.1, which it probably shouldn't. - jar manifest doesn't include the X-... attributes detailed in the release docs for the build JDK. - there is no src-ide.zip in the binary download (io does this...) - the jar is getting a little porky, at nearly 250K. Stephen Henri Yandell wrote: I've gone ahead and done a first release candidate for 2.2. http://people.apache.org/~bayard/commons-lang/ Anyone have anything before I kick off a vote? -- Bear in mind that to allow us to keep momentum with 2.3, I've created a branch for Lang 2.2: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LA N G_2_2_X 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] 2.2 RC1 rolled and ready for comments
- the jar is getting a little porky, at nearly 250K. 3.0 and removing deprecations might help a little there. Should we plan on delivering whatever we delete, like the enum package, in a separate jar for backwards binary compatibility? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 2:37 PM To: Jakarta Commons Developers List Subject: Re: [lang] 2.2 RC1 rolled and ready for comments On 9/20/06, Stephen Colebourne [EMAIL PROTECTED] wrote: - Should we be using viewcvs.cgi still now we are on svn? Or is there a viewvc.cgi? - Tasks xdoc needs Stringbuf removing. - The release notes mentions changes from 2.0 to 2.1, which it probably shouldn't. - jar manifest doesn't include the X-... attributes detailed in the release docs for the build JDK. Will change the above tonight. I left the 2.0-2.1 so people could figure out 2.0 to 2.2; but I was pretty vague on whether there was any value in that. - there is no src-ide.zip in the binary download (io does this...) I've no itch to do that - though I do want to make a src.jar and javadoc.jar for the Maven-2 repository. I've been doing that by pulling the src out of all of the commons distros and making jars, rather than for just a single project. - the jar is getting a little porky, at nearly 250K. 3.0 and removing deprecations might help a little there. 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]
[lang] LANG-279 HashCodeBuilder
Arg, I just ran into a case in our application where I get a stack overflow with HashCodeBuilder and cyclical object trees: https://issues.apache.org/jira/browse/LANG-279 I can fix this the same why I fixed ReflectionToStringBuilder. The question is: do this now or after 2.2? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, September 10, 2006 1:11 AM To: Jakarta Commons Developers List Subject: [lang] LANG-262 Any thoughts on this issue? https://issues.apache.org/jira/browse/LANG-262 Says that the cEnumClasses Hashmap in the Enum class is keeping a ClassLoader from being garbage collected and that switching it to a WeakHashMap should fix it. Seems fair to me, and an easy fix for 2.2; but not something I can think of simple ways to unit test. Any thoughts? 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: [EMAIL PROTECTED]: Project commons-lang (in module jakarta-commons) failed
Fixed in SVN. Gary -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 9:55 AM To: commons-dev@jakarta.apache.org Subject: [EMAIL PROTECTED]: Project commons-lang (in module jakarta-commons) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-lang has an issue affecting its community integration. This issue affects 191 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - JacORB : The free Java implementation of the OMG's CORBA standard. - anakia : Essentially an XML transformation tool, Anakia uses JDOM and... - ant-embed-optional : Java based build tool - ant-xdocs-proposal : Java based build tool - apache-ldapber-provider : Apache Directory Project - apollo : Apollo Project - asn1-ber : Apache ASN.1 Tools - authx-example : Apache Authentication and Authorization Framework - authx-script : Apache Authentication and Authorization Framework - checkstyle : Java style checker - commons-cli : Commons CLI Package - commons-cli2 : Commons CLI Package - commons-configuration : Jakarta commons - commons-dbcp : Database Connection Pool - commons-email : Commons Email Package - commons-fileupload : Commons File Upload Package - commons-io : Commons I/O Utility Package - commons-jci : Commons JCI - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-soap : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - commons-jxpath : XPath traversal of JavaBeans - commons-lang : utilities for the classes that are in java.lang's hierarchy - db-ddlutils : Easy-to-use component for working with Database Definition (... - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - db-torque : Persistence Layer - db-torque-gen : Persistence Layer - excalibur-component : Repository of reusable components. - excalibur-cornerstone-connection-api : Repository of reusable components. - excalibur-cornerstone-connection-impl : Repository of reusable components. - excalibur-cornerstone-datasources-impl : Repository of reusable components. - excalibur-cornerstone-scheduler-impl : Repository of reusable components. - excalibur-cornerstone-threads-api : Repository of reusable components. - excalibur-cornerstone-threads-impl : Repository of reusable components. - excalibur-datasource : Repository of reusable components. - excalibur-event : Repository of reusable components. - excalibur-event-api : Repository of reusable components. - excalibur-event-impl : Repository of reusable components. - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-api : Repository of reusable components. -
[jira] Commented: (CODEC-8) REQ: Streaming codecs
[
http://issues.apache.org/jira/browse/CODEC-8?page=comments#action_12430793 ]
Gary Gregory commented on CODEC-8:
--
Seems reasonable. Has anyone a first cut on top of from the proposed interfaces
above?
REQ: Streaming codecs
-
Key: CODEC-8
URL: http://issues.apache.org/jira/browse/CODEC-8
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.2
Environment: Operating System: All
Platform: All
Reporter: Sergei S. Ivanov
I would really appreciate if, for example, Base64 encoder could operate on
streams. One reason is that it's much easier to attach ByteArrayInputStream to
an array of bytes that to copy a byte array into a stream. The other reason is
greater flexibility, given by the streams.
I'd suggest creating a pair of new interfaces:
public interface StreamingDecoder implements Decoder {
public void decode(InputStream in, OutputStream out) throws
DecoderException;
}
public interface StreamingEncoder implements Encoder {
public void encode(InputStream in, OutputStream out) throws
EncoderException;
}
Base64 and Hex will then be able to implement these interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] 2.2?
Henri: Here the failure: junit.framework.ComparisonFailure: Check 00:00:00.000 expected:...0:00:00.000 MD... but was:...6:00:00.000 GM... at junit.framework.Assert.assertEquals(Assert.java:81) at org.apache.commons.lang.time.DateUtilsTest.testTruncateLang59(DateUtilsT est.java:905) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUn it3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.ja va:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe stRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe stRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRun ner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRu nner.java:196) -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 16, 2006 8:43 PM To: Jakarta Commons Developers List Subject: Re: [lang] 2.2? On 8/16/06, Gary Gregory [EMAIL PROTECTED] wrote: FWIW, here are some test results for test.time I have: Compiled with Sun Java 1.4.2_12: - test.time has 1 failure with Sun Java 1.3.1_15 - test.time passes with Sun Java 1.4.2_12 - test.time passes with Sun Java 1.5.0_08 Doing the same above with the code compiled with Sun Java 1.3.1_15 yield the same results. This is all on Windows XP SP2 and Ant 1.6.5. Wish I could get JDK 1.3 to work on a Linux box. Both my Debian Sarge (hardly a new distro) and Ubuntu laptop have glibc errors. Must grab the IBM version and see how it goes. Which one is the test.time failure? 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]
[httpclient] Please make compile.debug = true the default
Hello All: Unlike version 3.0.1, the 3.1-alpha1 version is not compiled with debug information. I think compile.debug = true is a better default. Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r432652 - /jakarta/commons/proper/httpclient/trunk/project.properties
Thanks Oleg ;)
Gary
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, August 18, 2006 10:21 AM
To: [EMAIL PROTECTED]
Subject: svn commit: r432652 -
/jakarta/commons/proper/httpclient/trunk/project.properties
Author: olegk
Date: Fri Aug 18 10:21:16 2006
New Revision: 432652
URL: http://svn.apache.org/viewvc?rev=432652view=rev
Log:
Changed maven.compile.debug flag to true
Modified:
jakarta/commons/proper/httpclient/trunk/project.properties
Modified: jakarta/commons/proper/httpclient/trunk/project.properties
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/pro
jec
t.properties?rev=432652r1=432651r2=432652view=diff
==
--- jakarta/commons/proper/httpclient/trunk/project.properties
(original)
+++ jakarta/commons/proper/httpclient/trunk/project.properties Fri Aug
18
10:21:16 2006
@@ -2,7 +2,7 @@
maven.compile.source=1.2
maven.compile.target=1.2
-maven.compile.debug=false
+maven.compile.debug=true
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
-
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]
[lang] 2.2?
Hi All: How close are we to an Alpha/Beta for 2.2? Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] 2.2?
FWIW, here are some test results for test.time I have: Compiled with Sun Java 1.4.2_12: - test.time has 1 failure with Sun Java 1.3.1_15 - test.time passes with Sun Java 1.4.2_12 - test.time passes with Sun Java 1.5.0_08 Doing the same above with the code compiled with Sun Java 1.3.1_15 yield the same results. This is all on Windows XP SP2 and Ant 1.6.5. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 16, 2006 12:17 PM To: Jakarta Commons Developers List Subject: Re: [lang] 2.2? If the VariableFormatter stuff is happily resolved (at least the 2.2 aspects of it), then the only issue I know of is the recent failed nightly build of Lang. It implies we have a bugfix that is still failing on some time-based yet random-appearing event. I hadn't pushed on Lang 2.2 in the last couple of weeks due to being a bit tied up; things are lighter again now though and unless anyone wants to jump in I'll get things in motion. Hen On 8/16/06, Gary Gregory [EMAIL PROTECTED] wrote: Hi All: How close are we to an Alpha/Beta for 2.2? Gary - 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]
[lang] EnumUtils new method?
Hello: In EnumUtils we have: public static Enum getEnum(Class enumClass, String name) What I need to ask a List of Enum classes for an Enum: public static Enum getEnum(List enumClassList, String name) Is this too odd a case? Should I keep my utility method in my own code? Your thoughts please... Thank you, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] ExceptionUtilsTestCase should not depend on Java 1.4.x
Hi All: When I have the compiler set to Java 1.3.1, I get: Severity and DescriptionPathResourceLocation Creation Time Id The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1351153767000812 14290961 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1361153767000812 14290965 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1691153767000812 14290993 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 2691153767000812 14291025 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 3161153767000812 14291026 Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] VariableFormatter - pre 2.2
Hello All: I think the argument for the name change I am hearing is: we are not formatting a la printf but we are replacing markers with values (and not formatting those values). Is that right? If that is the case, a Substitutor name is better. As a general rule, I do not like or use abbreviations in class or method names (acronyms are OK by me). So I would say that StringSubstitutor is better. After all, we have StringUtils, StringEscapeUtils and many others, not StrUtils, StrEscapeUtils. So I would ask that we use StringFoo for all of these classes. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 11:30 PM To: Jakarta Commons Developers List; Stephen Colebourne Subject: Re: [lang] VariableFormatter - pre 2.2 On 7/23/06, Stephen Colebourne [EMAIL PROTECTED] wrote: I have reworked the VariableFormatter class along the lines that I was thinking. I have committed it as StrSubstitutor so it doesn't clash for the moment and so it can be easiy reviewed. This version does not have a separate parser class, but still supports escaping, and matchers for prefix/suffix (which can now be set by users). The new class should perform better as a result. I have removed the edge cases wrt resolving Objects, as they were rather ill- defined. Otherwise, the basic functionality it supported, and the test case is slightly enlarged. I still want to break out the resolver as a public abstract class before release. Opinions Oliver, Gary, Tom? Looking to get Lang 2.2 moving out the door and this is the only blocker. 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: [lang] VariableFormatter - pre 2.2
Do you'all think the variable code be simpler to groke/reuse for
customers if there we changed the nested classes into 1st class
citizens? Kinda of a side issue I know...
G
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 20, 2006 10:55 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] VariableFormatter - pre 2.2
This is all that's left in 2.2 before an RC can be built.
On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here
goes...
At a minimum, I'd like to see MapVariableResolver packge scoped.
Reading the following in the threads, no one seems to be against
making MapVariableResolver package scoped.
Personally I don't think we should have public nested classes,
especially if they're intended for extension. That might just be me
being a dumb user.
VariableResolver is another public nested class (well interface). Any
reason to not have this be package scoped for the 2.2 release as well?
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
public class StrLookup {
String lookup(String key);
// package scoped implementation for Map
}
You could envisage other (non [lang]) accessors such as OGNL, EL,
XPath
or perhaps ones that accessed a List of strings by index.
The key point is that this shouldn't be limited to just
VariableFormatter in the same way that StrMatcher isn't limited to
StrTokenizer. Separation of Concerns.
A 2.3/3.0 subject?
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]
[codec] Site links to Bugzilla vs. Jira
Hello: Would now be a good time to change the [codec] site to point to Jira instead of Bugzilla? Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] JRE level?
I have the Eclipse project that the code lives in on my machine setup with Java 1.3.1. In Eclipse, you can set a different JRE for each project or have a project inherit the JRE from the containing workspace. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 9:43 AM To: Jakarta Commons Developers List Subject: Re: [lang] JRE level? Grumble, grumble, Maven - 1.4+, grumble, grumble, OS X - no 1.2.x, grumble, grumble, grumble. How did you catch this by the way Gary? Hen On 7/6/06, Stephen Colebourne [EMAIL PROTECTED] wrote: [lang] should be JDK1.2 compliant, although I tend to think of it as 1.3+ with 1.2 at users risk. Stephen Gary Gregory wrote: Hello All: Based on the project.properties file entry: maven.compile.source = 1.3 I assume that we are making Java 1.3 the requirement. We therefore should not have Java 1.4 dependencies: Severity and Description PathResourceLocation Creation Time Id The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1351151797976890 13807342 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1361151797976890 13807346 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1691151797976890 13807374 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 2691151797976890 13807406 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 3161151797976890 13807407 Or am I missing something? Thanks, Gary - 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: [lang] Heading towards a Lang 2.2 release?
Hi All: -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, July 03, 2006 10:03 PM To: Jakarta Commons Developers List Subject: [lang] Heading towards a Lang 2.2 release? Is anyone opposed to my starting to put together an rc1 distribution for Lang 2.2? +1! The current state of play can be seen at: http://issues.apache.org/jira/browse/LANG There is one issue left in 2.2; a bug that sometimes passes tests and sometimes fails - regardless of which, I'm not sure how to fix it even when I do figure out how to make it repeatedly fail. I suspect I have to sit and play with my system clock. I'm tempted to push it back to 2.3. Can the APIs be parameterized such that we can pass in various system times during tests? Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] JRE level?
Hello All: Based on the project.properties file entry: maven.compile.source = 1.3 I assume that we are making Java 1.3 the requirement. We therefore should not have Java 1.4 dependencies: Severity and DescriptionPathResourceLocation Creation Time Id The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1351151797976890 13807342 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1361151797976890 13807346 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1691151797976890 13807374 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 2691151797976890 13807406 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 3161151797976890 13807407 Or am I missing something? Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] VariableFormatter - pre 2.2
Hello All:
At a minimum, I'd like to see MapVariableResolver packge scoped.
Looking at the message thread:
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg78697.html
It seems that another proposal being discussed back in April was to make
some classes /easier/ to reuse and extend for the more advanced users by
making them come out of inner, which would also mean keeping them
public.
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
The challenge to me here is that I've heard some folks says they do not
want [lang] to become too framework-like. I am wondering if making
VariableResolver more generic would go in that direction. The nice thing
I see about the way it is now is that the solution is on making the
variable resolver pluggable and nothing more. Which is a draw back if
that interface is really /that great/.
FWIW, I am pretty happy with using the VariableFormatter class as is and
plan on doing so (as soon as my work schedule allows.)
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 05, 2006 5:07 PM
To: Jakarta Commons Developers List
Subject: [lang] VariableFormatter - pre 2.2
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here
goes...
At a minimum, I'd like to see MapVariableResolver packge scoped.
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
public class StrLookup {
String lookup(String key);
// package scoped implementation for Map
}
You could envisage other (non [lang]) accessors such as OGNL, EL,
XPath
or perhaps ones that accessed a List of strings by index.
The key point is that this shouldn't be limited to just
VariableFormatter in the same way that StrMatcher isn't limited to
StrTokenizer. Separation of Concerns.
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]
[jira] Commented: (LANG-267) Support char array converters on ArrayUtils
[ http://issues.apache.org/jira/browse/LANG-267?page=comments#action_12419316 ] Gary Gregory commented on LANG-267: --- Is [lang] the right project for this instead of [primitives]? Where do we draw the line between [primitives] and [lang]? Support char array converters on ArrayUtils --- Key: LANG-267 URL: http://issues.apache.org/jira/browse/LANG-267 Project: Commons Lang Type: New Feature Versions: 2.2 Reporter: Andres Almiray Priority: Minor Fix For: 2.2 Attachments: ArrayUtils.txt, commons-lang_ArrayUtils-with-test.patch, commons-lang_ArrayUtils.patch I don't know it the following methods have been overlooked, but they will make a fine addition to ArrayUtils: public static char[] toPrimitive(Character[] array) public static char[] toPrimitive(Character[] array, char valueForNull) public static Object[] toObject(char[] array) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-226) [lang] Using ReflectionToStringBuilder and excluding secure fields
[ http://issues.apache.org/jira/browse/LANG-226?page=comments#action_12416586 ] Gary Gregory commented on LANG-226: --- Do you have any time to look at unifying those Gary? I've just come back from my honeymoon and I will not be able to take the time to look at this for a week or so. [lang] Using ReflectionToStringBuilder and excluding secure fields -- Key: LANG-226 URL: http://issues.apache.org/jira/browse/LANG-226 Project: Commons Lang Type: Improvement Versions: Nightly Builds Environment: Operating System: All Platform: Other Reporter: Gary Gregory Priority: Minor Fix For: 2.2 Short discussion: http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200508.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Pushing Enums back to 2.3?
Any thoughts on having a 2.3 release that focuses on the 5 enum issues? I'm +1. Release early, release often, a la XP. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 06, 2006 12:45 PM To: Jakarta Commons Developers List Subject: [lang] Pushing Enums back to 2.3? Any thoughts on having a 2.3 release that focuses on the 5 enum issues? * Bug LANG-262Use of enum prevents a classloader from being garbage collected resuling in out of memory exceptions. * Bug LANG-153[lang] Can't XMLDecode an Enum * Bug LANG-76 [lang] EnumUtils.getEnum() doesn't work well in 1.5 * Improvement LANG-258Enum JavaDoc: 1) outline 5.0 native Enum migration 2) warn not to use the switch() , 3) point out approaches for persistence and gui * Bug LANG-259ValuedEnum.compareTo(Object other) not typesafe - it easily could be... So they would be pushed back to 2.3, leaving us with 8 issues in 2.2. Of those 8, LANG-180 and LANG-197 should be pushed back to 3.0. Features that require discussion I think. * Improvement LANG-180[lang] adding a StringUtils.replace method that takes an array or List of replacement strings * Improvement LANG-197[lang] Extending VariableFormatter to use FormatPatterns That leaves us with 6. Bug LANG-66 [lang] StringEscaper.escapeXml() escapes characters 0x7f Bug LANG-100[lang] RandomStringUtils.random() family of methods create invalid unicode sequences Bug LANG-59 [lang] DateUtils.truncate method is buggy when dealing with DST switching hours Bug LANG-69 [lang] ToStringBuilder throws StackOverflowError when an Object cycle exists Bug LANG-140[lang] DurationFormatUtils.formatPeriod() returns the wrong result Improvement LANG-226[lang] Using ReflectionToStringBuilder and excluding secure fields LANG-66 is easy enough to change assuming no one is against the idea. Gary's reading of the XML spec suggested that we shouldn't be escaping such characters but just letting them sit in the XML. LANG-100 is confusing. I think it's solveable, but not sure any of us know much about this part of unicode. LANG-59 - I have no idea on fixing this. Needs code of some kind in DateUtils.modify. If it's all that's left at the end, I'll be recommending we push it to 3.0. LANG-69 needs to be reworked - there's too much there and it breaks another test. LANG-140 needs some hacking to get a fix that isn't too ugly. LANG-226 just needs a bit of cleanup. 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: [lang] ClassUtils.getPublicMethod
Hi: I think ClassUtils is fine unless it gets to be a giant class. I think if asking a class for its methods, so asking a ClassUtils for this info makes sense. I could see a MethodUtils being useful if one needed to perform operations on a bunch of methods. For example: Method[] methods = ClassUtils.getMethods(...); Method[] publicMethods = MethodUtils.toPublicMethods(methods); Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, May 13, 2006 5:38 AM To: Jakarta Commons Developers List Subject: [lang] ClassUtils.getPublicMethod This is a new addition in this release. Should we be creating a MethodUtils instead? 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][all] Switch to Jira
+1 * Cleanup Commons project (we'll still use it as a catch-all). Delete components/versions. This does not match: * Make Bugzilla read-only What about creating an 'Catch all' product in JIRA and only using JIRA? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 02, 2006 10:52 AM To: Jakarta Commons Developers List Subject: [VOTE][all] Switch to Jira I'd like to call a vote that we switch to Jira. Here's the loose migration plan: * Make Bugzilla read-only * Import Commons project in Bugzilla into Commons project in JIRA This will pull over users, components, versions etc. * Setup notification scheme * Setup permission scheme * Setup group * For each of the 37 components ** Create new project - name: Commons Xxxx, key . ** Assign notification, permission and group ** Create relevant versions ** View component, bulk move all issues to new project * Cleanup Commons project (we'll still use it as a catch-all). Delete components/versions. The 37 components don't all have to be set up at the same time, we can take our time to move things out of the Commons project and into the individual Commons Foo projects. [ ] +1 [ ] -1 Vote to last 72 hours, 3 +1s required, 3/4 of active vote being +1. 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: [lang] org.apache.commons.lang.Entities
So... should we dig in to multi-threading issues for 2.2?
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 27, 2006 4:07 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] org.apache.commons.lang.Entities
Gary Gregory wrote:
- Let users call StringEscapeUtils once to init the data like David
discovered.
- Change the init in Entities to lazy-init methods (which must be
synchronized)
- Change the init in Entities to use an on-demand holder class
Would this work? I suspect not.
static {
Entities xml = new Entities();
xml.addEntities(BASIC_ARRAY);
xml.addEntities(APOS_ARRAY);
XML = xml;
}
I have to be honest that I did think that static blocks were
inherently
synced in Java.
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: [lang] org.apache.commons.lang.Entities
I 3.0'd it.
Fine with me. Perhaps we can document a fix in the ticket.
Gary
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Friday, April 28, 2006 5:49 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] org.apache.commons.lang.Entities
I 3.0'd it.
Mostly because:
a) There's no obvious solution
b) It's not an error that is going to cause huge problems. No
exceptions flying around, just a bit of garbage when the code using
the library first starts.
Hen
On 4/28/06, Gary Gregory [EMAIL PROTECTED] wrote:
So... should we dig in to multi-threading issues for 2.2?
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 27, 2006 4:07 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] org.apache.commons.lang.Entities
Gary Gregory wrote:
- Let users call StringEscapeUtils once to init the data like
David
discovered.
- Change the init in Entities to lazy-init methods (which must
be
synchronized)
- Change the init in Entities to use an on-demand holder class
Would this work? I suspect not.
static {
Entities xml = new Entities();
xml.addEntities(BASIC_ARRAY);
xml.addEntities(APOS_ARRAY);
XML = xml;
}
I have to be honest that I did think that static blocks were
inherently
synced in Java.
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]
-
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: [lang] org.apache.commons.lang.Entities
Hello:
To top it all off the behavior is probably different b/w Java 1.4 and
1.5.
We could:
- Let users call StringEscapeUtils once to init the data like David
discovered.
- Change the init in Entities to lazy-init methods (which must be
synchronized)
- Change the init in Entities to use an on-demand holder class
See Effective Java by J. Bloch, Item 48, for multi-threaded init
issues.
Gary
-Original Message-
From: Gaulin, David: #CIPO - OPIC [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 26, 2006 5:09 AM
To: commons-dev@jakarta.apache.org
Subject: [lang] org.apache.commons.lang.Entities
Hello,
Not sure if it is the right mailling list but here we go anyway.
I am currently using the Entities.java class (well I am using the
StringEscapeUtils.java which uses that class). Works really good,
saved me a lot
of time. My thanks to the people who wrote it.
I have encountered a little problems with it taught. Nothing major
but I just
taugth I would share since it migth be of interest to you.
I have an heavily multithreaded process that runs on a really under
powered
server. All those threads access the StringEscapeUtils.escapeXml()
methods
pretty much at the same time. What happens is that by the time the
Second or
Third Thread calls the StringEscapeUtils.escapeXml() the static
initialization in
the Entities.java class has not completed yet. That block in
particular.
static {
XML = new Entities();
XML.addEntities(BASIC_ARRAY);
XML.addEntities(APOS_ARRAY);
}
I don't get a NullPointer so it seems that XML = new Entities() is
actually being
executed before the other Thread starts but the
XML.addEntities(BASIC_ARRAY)
on the other hand is not executed before the other thread starts. So
when the
second or third thread calls the StringEscapeUtils.escapeXml() it
doesn't escape
the BASIC_ARRAY or APOS_ARRAY entities. To fix it, in my code, I just
make sure
to call StringEscapeUtils.escapeXml() before I start any threads and
it solve the
problems but if anyone is ever to re-work the class this might be
something to
look at.
Just to share.
Thank
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] org.apache.commons.lang.Entities
Tracking with this bugzilla ticket:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39411
Gary
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 26, 2006 8:32 AM
To: Jakarta Commons Developers List
Subject: RE: [lang] org.apache.commons.lang.Entities
Hello:
To top it all off the behavior is probably different b/w Java 1.4 and
1.5.
We could:
- Let users call StringEscapeUtils once to init the data like David
discovered.
- Change the init in Entities to lazy-init methods (which must be
synchronized)
- Change the init in Entities to use an on-demand holder class
See Effective Java by J. Bloch, Item 48, for multi-threaded init
issues.
Gary
-Original Message-
From: Gaulin, David: #CIPO - OPIC [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 26, 2006 5:09 AM
To: commons-dev@jakarta.apache.org
Subject: [lang] org.apache.commons.lang.Entities
Hello,
Not sure if it is the right mailling list but here we go anyway.
I am currently using the Entities.java class (well I am using the
StringEscapeUtils.java which uses that class). Works really good,
saved me a lot
of time. My thanks to the people who wrote it.
I have encountered a little problems with it taught. Nothing major
but I just
taugth I would share since it migth be of interest to you.
I have an heavily multithreaded process that runs on a really under
powered
server. All those threads access the StringEscapeUtils.escapeXml()
methods
pretty much at the same time. What happens is that by the time the
Second or
Third Thread calls the StringEscapeUtils.escapeXml() the static
initialization in
the Entities.java class has not completed yet. That block in
particular.
static {
XML = new Entities();
XML.addEntities(BASIC_ARRAY);
XML.addEntities(APOS_ARRAY);
}
I don't get a NullPointer so it seems that XML = new Entities() is
actually being
executed before the other Thread starts but the
XML.addEntities(BASIC_ARRAY)
on the other hand is not executed before the other thread starts.
So
when the
second or third thread calls the StringEscapeUtils.escapeXml() it
doesn't escape
the BASIC_ARRAY or APOS_ARRAY entities. To fix it, in my code, I
just
make sure
to call StringEscapeUtils.escapeXml() before I start any threads and
it solve the
problems but if anyone is ever to re-work the class this might be
something to
look at.
Just to share.
Thank
David
-
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: [lang] VariableFormatter issues
Hello:
I wonder if in the interest of getting version 2.2 out the door we
should keep VariableFormatter as-is. Anyone who likes the subclass can
obviously use it. If the feature is easy to add, we don't have to
discuss the following for post-2.2:
- Does the VariableFormatterWithFormating functionality belong in
VariableFormatter or should it be a subclass.
- It seems like we could also extend the current ${} syntax to include
the VariableFormatterWithFormating feature. Where this gets tricky and
could become difficult is if we cannot reuse MessageFormat.format.
Tom (and all):
Have you considered changing VariableFormatter itself to provide the
feature?
Would changing MapVariableResolver only do the trick?
The implementation in the ticket subclasses VariableFormatter, why not
subclass just MapVariableResolver only?
To make the code more reusable we should be open to making the inner
classes stand alone.
Gary
Sent: Tuesday, April 25, 2006 7:05 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] VariableFormatter issues
Gary Gregory wrote:
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Monday, April 24, 2006 12:12 AM
To: Jakarta Commons Developers List
Subject: [lang] VariableFormatter issues
Our favourite 'will this become a templating language' class.
Two issues to ask questions about:
1) First enhancement request: #36873. Adds MessageFormat like format
patterns. It's an enhancement, seems like a pretty good one to me as
it is an enhancement that builds on the JDK and not a new feature.
How
does this sit on people's slippery slopes?
This is interesting and slippery. Since the submitted code uses
MessageFormat.format, we are not inventing a language, just
accessing
a JRE feature.
OTOH, the class VariableFormatter is named as such *because* it is
not a
Format subclass and was not intended to be. So providing Format
features via a subclass to VariableFormatter is clean in the sense
that
we are not mixing things up but not really what I had in mind
(that's
the great part about OS). OTOH (the OOH), if we really think this is
a
fantastic feature, we should consider if it should be better
integrated
than with a subclass.
I like VariableFormatter the way it is. So I am neutral as to using
the
submitted code. If we do use VariableFormatterWithFormating, could
we
consider better class name?
Well I like it (maybe because I've submitted it) and use it frequently
in my source codes. I wasn't really happy with the name too, still in
my
idea you don't need a sub-class a better idea would be a flag passed
and
turns on/off formatting but on the other hand this would maybe blow up
the numer of API-Functions.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] VariableFormatter issues
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, April 24, 2006 12:12 AM To: Jakarta Commons Developers List Subject: [lang] VariableFormatter issues Our favourite 'will this become a templating language' class. Two issues to ask questions about: 1) First enhancement request: #36873. Adds MessageFormat like format patterns. It's an enhancement, seems like a pretty good one to me as it is an enhancement that builds on the JDK and not a new feature. How does this sit on people's slippery slopes? This is interesting and slippery. Since the submitted code uses MessageFormat.format, we are not inventing a language, just accessing a JRE feature. OTOH, the class VariableFormatter is named as such *because* it is not a Format subclass and was not intended to be. So providing Format features via a subclass to VariableFormatter is clean in the sense that we are not mixing things up but not really what I had in mind (that's the great part about OS). OTOH (the OOH), if we really think this is a fantastic feature, we should consider if it should be better integrated than with a subclass. I like VariableFormatter the way it is. So I am neutral as to using the submitted code. If we do use VariableFormatterWithFormating, could we consider better class name? 2) Any idea what the status of the 35588 issue is? Looks like it was all done with just some minor OT Clover stuff. Any reason to keep this open? I was trying to get 100% code coverage with Clover. I think you can close this one. In my perfect world, any new features and patches would get 100% code coverage. Gary 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: [all] Clover version
What about switching to Cobertura? http://cobertura.sourceforge.net/ Gary -Original Message- From: Brian K. Wallace [mailto:[EMAIL PROTECTED] Sent: Monday, April 24, 2006 2:22 PM To: Jakarta Commons Developers List Subject: [all] Clover version -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I saw a thread on this from (almost) a year ago with no visible resolution - so here goes again. :-) The current version of the clover.jar in the committer's repo is version 1.3.2. This version will not compile annotations (and results in an NPE if attempted). (Is it possible / What will it take) to get a newer version of clover? The license file states it's valid for 0.x and 1.x - the latest 1.x (as of this writing) is 1.3.12 (which does compile annotations properly). Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFETUGMaCoPKRow/gARAuCdAKCmH0IsRuHjIiXG4so5Pb736s5rxQCfX5T/ 7nDpwzV1/yILQyqnDWWHInM= =Hj65 -END PGP SIGNATURE- - 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: [lang] Entities question
Refactor away! Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 18, 2006 12:29 AM To: Jakarta Commons Developers List Subject: [lang] Entities question Any ideas why there are unescape(String);String and unescape(Writer, String) implementations in Entities - independently implemented? They look like clones of each other - just one has nicer variable names. Seems to me that: a) One should call the other. b) One could be deleted (given that Entities isn't public). In the latter case, there are two users of the methods: unescapeHtml calls the Writer,String and unescapeXml calls the String; so we would delete one and make the two unescapeXxx methods call the same method. Same applies for the escape() variants. 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: [lang] next version etc
-Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Sunday, April 16, 2006 7:23 AM To: Jakarta Commons Developers List Subject: Re: [lang] next version etc snip 36925: Status Gary? I like the feature and it is done and it tested. The only thing I can think of is trying to make the API names better (they seem fine now to me). I would like to see method override taking in a Collection of Strings, otherwise its done. snip A Collection version of the method is now in SVN. All feedback welcome. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] CompositeFormat warnings
Hello: The recent CompositeFormat commits cause warnings: javadoc: [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.commons.lang... [javadoc] Loading source files for package org.apache.commons.lang.builder... [javadoc] Loading source files for package org.apache.commons.lang.enum... [javadoc] Loading source files for package org.apache.commons.lang.enums... [javadoc] Loading source files for package org.apache.commons.lang.exception... [javadoc] Loading source files for package org.apache.commons.lang.math... [javadoc] Loading source files for package org.apache.commons.lang.mutable... [javadoc] Loading source files for package org.apache.commons.lang.text... [javadoc] Loading source files for package org.apache.commons.lang.time... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.4.2_11 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] C:\svn-store\jakarta\commons\lang\src\java\org\apache\commons\lang\text\ CompositeFormat.java:51: warning - Tag @see: missing #: Format.format(Objec t, StringBuffer, FieldPosition) [javadoc] C:\svn-store\jakarta\commons\lang\src\java\org\apache\commons\lang\text\ CompositeFormat.java:51: warning - Tag @see: can't find Format.format(Object , StringBuffer, FieldPosition) in org.apache.commons.lang.text.CompositeFormat [javadoc] C:\svn-store\jakarta\commons\lang\src\java\org\apache\commons\lang\text\ CompositeFormat.java:60: warning - Tag @see: missing #: Format.parseObject( String, ParsePosition) [javadoc] C:\svn-store\jakarta\commons\lang\src\java\org\apache\commons\lang\text\ CompositeFormat.java:60: warning - Tag @see: can't find Format.parseObject(S tring, ParsePosition) in org.apache.commons.lang.text.CompositeFormat [javadoc] Building index for all classes... [javadoc] C:\svn-store\jakarta\commons\lang\src\java\org\apache\commons\lang\text\ CompositeFormat.java:41: warning - @param argument Format is not a paramet er name. [javadoc] C:\svn-store\jakarta\commons\lang\src\java\org\apache\commons\lang\text\ CompositeFormat.java:41: warning - @param argument Format is not a paramet er name. [javadoc] Generating C:\svn-store\jakarta\commons\lang\dist\docs\api\stylesheet.css... [javadoc] 6 warnings Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] next version etc
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, April 14, 2006 6:04 PM To: Jakarta Commons Developers List Subject: [lang] next version etc I want to do something fun...so how about a Lang release. First up; 2.2 or 3.0? It would be nice to have one without enum and the other deprecated bits. IMO: 2.2, then 3.0 which removes 'enum' and anything that Java 5/6 complains about. Or... The ticket list below is long and diverse in scope and time needed. A possible release early, release often track could be: - Release 2.2 now, with only critical fixes. Time frame: now=weeks. - Release 2.3: implement easy fixes and apply no-brainer patches. Time frame: +1 month. - Release 2.4: implement trickier new features that require discussion and time to implement. Time frame: Months. - Release 3.0: - discuss breaking the API by removing deprecated methods? - discuss changing the base JRE requirement? - discuss deprecating any date/time code that can be replaced with Joda-Time. - builds/works on Java 5? - builds/works on Java 6? Some brief comments on some of the list items: Second up; text? I think it needs to go into our next version regardless of version number, or we need to decide to drop it. I will use text.VariableFormatter in our product. If 2.2 does not come out soon, I am going to pluck it out of there for our own use ;) I have no plans to use the Str* classes though. Third, bugs. Here're my thoughts: 20015: WONTIFX? Gary's on making Entities public. Looks like a lump of work to do, is it likely to happen or should we just decide that Entities shouldn't be public? I don't recall user's being desperate to use this class. Release early, release often. Let's leave this one for later. 26659: WONTFIX? Seems like too much in the way of date work - suggest JODA instead unless a patch is offered. I use Joda-Time now. I would even like to propose deprecating DateUtils 'softly' in favor of Joda-Time. I am sure many will not like this at all since Joda-Time is pretty large. 29692: Patch recently added. Consider and either apply or WONTFIX. Seems too specific/complex. 30082: WONTFIX. This is too specific an issue to be putting in Lang I believe. I agreed. 30184: Consider for lang.text. There are no unit tests provided (I know, the class is pretty simple). 31602: Sean/Stephen, thoughts? Should we WONTFIX as too complicated, or is it simple enough and we can do it? 33102: FIX: On the one hand, it's pretty simple stuff, and we'd have to support the roll(..) method. On the other hand, user's like this stuff and it's not hard to add it, even if we overload with Calendar as well. 4 methods would be needed. +0. Joda-Time? 33401: FIX: it's a bit redundant, but I've no reason not to have these methods available. Any -1s? Needs better method names IMO. -0. I'm always in favor of release early, release often when there are no unit tests with a code proposal ;) 33609: FIX. Javadoc needs improving. Nothing wrong with better docs! :) 33825: WONTFIX. Standard java.time question - is it valuable and simple, or should we just point to JODA? I'm going to go with WONTFIX as my default answer on time enhancements. I'm with you: Joda-Time. 33889: Unsure. Could be a CharSet enhancement instead of just a camel case method. Thoughts? 33997: I think this is a useful method - just need to make sure the implementation is the best possible. What about commons-math? 34284: FIX: NullPointer; test and fix. 34351: FIX: I don't see any reason not to try to write Albert's method. If not obvious when digging into it, then we can WONTFIX. 35400: WONTFIX. I'm -1 to a new classloader in lang, starts to leave the scope of 'simple' to my ignorant brain :) 35588: Part of the lang.text call. I need text.VariableFormatter. If 2.2 does not come out soon, I am going to pluck it out of there for our own use ;) 35826: Bring up with [math]. I think it could be in either, not sure I have the itch to write a BigXxx replacement though. Indeed, what does [math] think about that? It would be interesting to know what the [math] folks think about project boundaries for class like that. 36061: FIX. Seems simple enough - bug and patches. Some of these bugs might be obsolete. I thought I'd take care of object cycles a while back. Hm, but that might have been for the ReflectionToStringBuilder class, not the ToStringBuilder. 36512: FIX. I think there's value for a .forName improvement. Personally, I would only do the super simple stuff, primitives I suppose. Arrays of primitives ok... Basically, anything that you can say in Java code: int, int[]. Yeah, that's nice. But I would not want to have us invent a mini-language which the talk of eating up spaces starts to feel like. My vote would be to keep it simple in the first cut, if it is there at all. 3: Thoughts? Is it worth putting that inside the
