Re: [BeanUtils] Progressing towards a 1.8.0 release
Henri Yandell wrote: On 7/17/07, Niall Pemberton [EMAIL PROTECTED] wrote: Assemblies work except you only get a default manifest - not sure where I got the attachment idea from, can't find any reference to that - so I think we should keep it simple and stick to option #1 That has my +1 [obviously]. I think we should keep it simple. But surely, the problem is that maven will pull in collections.jar when it pulls in beanutils.jar, which is unnecessary. Its big, unnecessary dependencies like this that give commons a bad name. Anyway, I'll not block this, if this is the way you want to go. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Progressing towards a 1.8.0 release
Henri Yandell wrote: One area for discussion is the split between the optional Collections component and the 'Core' beanutils. Do we maintain that, or should we just fold the code back together? 1.7.0 shipped three versions: commons-beanutils-1.7.0.jar commons-beanutils-core-1.7.0.jar commons-beanutils-collections-1.7.0.jar where the first is the sum of the second and third. Personally I think we should just merge them back together. It's not worth the effort. The purpose is to avoid forcing users to take dependencies that they are not interested in, [collections] in this case. As such I think that the split is a Good Thing. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-259) TransformerClosure should implement Transformer and allow extension.
[
https://issues.apache.org/jira/browse/COLLECTIONS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512402
]
Stephen Colebourne commented on COLLECTIONS-259:
My preference would be to see the Predicate/Transformer/Closure parts of
[collections-generics] separated into a separate jar/project, as I don't think
that they are the main focus of interest for [collections]. Then, I think
adding new constructors/methods like this would have less impact (eg. on jar
file size of the main [collections] jar)
TransformerClosure should implement Transformer and allow extension.
Key: COLLECTIONS-259
URL: https://issues.apache.org/jira/browse/COLLECTIONS-259
Project: Commons Collections
Issue Type: Improvement
Components: Functor
Affects Versions: 3.2
Reporter: Stephen Kestle
Priority: Minor
Fix For: 3.3, Generics
TransformerClosure currently decorates a transformer. However, in the
interests of non-verbose code, it makes sense to be able to subclass it for a
class that implements both interfaces.
I propose the addition of the following constructor and method
protected TransformerClosure(){
iTransformer = this;
}
public O transform(I in){
return iTransformer.transform();
}
--
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] Commented: (COLLECTIONS-259) TransformerClosure should implement Transformer and allow extension.
[
https://issues.apache.org/jira/browse/COLLECTIONS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511686
]
Stephen Colebourne commented on COLLECTIONS-259:
An interesting idea, however I sense that it might confuse the intent of the
class for a limited use case.
TransformerClosure should implement Transformer and allow extension.
Key: COLLECTIONS-259
URL: https://issues.apache.org/jira/browse/COLLECTIONS-259
Project: Commons Collections
Issue Type: Improvement
Components: Functor
Affects Versions: 3.2
Reporter: Stephen Kestle
Priority: Minor
Fix For: 3.3, Generics
TransformerClosure currently decorates a transformer. However, in the
interests of non-verbose code, it makes sense to be able to subclass it for a
class that implements both interfaces.
I propose the addition of the following constructor and method
protected TransformerClosure(){
iTransformer = this;
}
public O transform(I in){
return iTransformer.transform();
}
--
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: [fileupload] RFC: Fileupload 1.3 or 2.0?
Jochen Wiedmann wrote: when applying the fixes for IO-99 to commons-fileupload, I was originally under the impression, that this would be easily possible without any or at least with fully upward compliant API changes. Until I detected that for reasons, which absolutely escape me, someone made FileItem to implement the Serializable interface. I've read the JIRA's and I don't understand why FileItem/Serializable is relevant. As such I'm struggling to understand this thread :-) The longer I thought about it, the more I came to the conclusion, that the only clean solution is to accept API changes. In particular, let FileItem no longer implement the Serializable interface. While we are at it, we could as well dissolve the the FileItemFactory and the multipart parser. Remove the whole bunch of deprecated methods. In other words, I propose to resolve FILEUPLOAD-120.or FILEUPLOAD-125 finally by dropping binary compatibilty and declaring the next version as commons-fileupload 2.0, not 1.3. OK, here is my view on this (I'll get in early this time). If there is a minor incompatible change, like making FileItem no longer implement Serializable, then IMO that can be a v2.0 with the same package name. (Minor means that it has no effect on the vast majority of users. In addition, deprecated methods and classes can be removed. If there are larger changes that involve design changes, especially changes to user code (backwards imcompatible) then that should be a v2.0 with a different package name. If you choose the latter option, I would personally prefer to see [fileupload] move to Java 1.5 at the same time. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements
[ https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509269 ] Stephen Colebourne commented on BEANUTILS-285: -- Although I haven't followed the detail of this case, ensuring it is fully semantically, binary and source compatible is essential IMO. These are exceptionally widely distributed libraries, and having anything change in them that breaks others will create all sorts of dependency hell. Maybe the better solution here is to get commons-convert working and released, as a simple object-string conversion tool (the original plan), and then allow [beanutils] to optionally use [convert] as the conversion provider instead of the old (rolled back) converters in [beanutils] ? Consider options for BeanUtils compatibility in light of Conversion improvements Key: BEANUTILS-285 URL: https://issues.apache.org/jira/browse/BEANUTILS-285 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.8.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Attachments: betwixt-beanutils-gump-fix.patch The Conversion improvements associated with BEANUTILS-258 potentially create compatibility issues - this was highlighted by Betwixt's tests failing recently in the gump run - see http://tinyurl.com/2mxbv8 for more details. Quite a bit of effort has been put into making the new conversion facilities as painless as possible for existing users. However it is not fully backwards compatible in terms of behaviour (stiil binary compatible). Need to give this some consideration before a BeanUtils release - at the moment there are two options on the table (more welcome!): 1) The compatibility as it stands is good enough (covers most cases) - so do nothing 2) Provide a compatibility option - so that users can choose either the new behaviour or behaviour compatible with BeanUtils 1.7.0. This probably involves quite a bit of work - adding back the old behaviour alongside the new -- 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] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509270 ] Stephen Colebourne commented on LANG-326: - Personally, I would go with 2.4. StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- 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] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509193 ] Stephen Colebourne commented on LANG-326: - I'm happy for these ignoreCase methods to be added. For collators I'd suggest a CollatorUtils. StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- 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] 4th attempt: Release commons-io 1.3.2
sebb wrote: Licence and notice files are present in all files (twice in sources.jar, but better twice than none). Not something I'm worried about. Nice to fix if there is another RC. The RELEASE-NOTES.txt say: - The FileCleaner is deprecated. Unfortunate, but not something I'm too worried about. If there is another RC, I'd suggest rewording to The previous class FileCleaner will be deprecated in 1.4 Also, the changes.xml says: release version=1.3.2 date=2007-May-16 Not something I'm worried about. Nice to fix if there is another RC. The sources.jar file does not contain all the files present in the src.jar file - e.g. it does not contain the test or xdocs trees. Thats correct and normal. The bin.zip archive contains bin.jar and the javadoc. However it also contains the src.jar and the javadoc.jar. Seems a bit unnecessary to me. Thats been standard practice for [io] for a while, as it means IDE developers only need to download the zip. has a link called RAT (Release Audit Tool). This probably shouldn't be on the final website. Could not find any reference to the minimum version of Java that is required. It would be useful to add this to the dependencies section. Adding to dependencies is not easy to do. This can be done for 1.4 My main spot was that the website is of the old commons style, rather than the new (compare fonts/colours against the live [io] site). We shouldn't change the contents of 1.3.2, but the website that goes live should probably be built from TRUNK rather than the branch. (of course, the 1.3.2 javadoc will have to be generated from the branch, so this is a complex operation...) I am +1 to this release. Thanks for your patience Jochen. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: infrastructure work for TLP move
I also would strongly prefer to use this opportunity to create a commits list and an issues list. Commons is big enough to need it, and it would increase the signal to noise on the main list, especially when searching. Stephen - Original Message From: Martin van den Bemt [EMAIL PROTECTED] Agree with Niall.. Archives are pretty much unusable with commits messages and jira issues.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Invite Rahul Akolkar to join the Apache Commons PMC
Niall Pemberton wrote: [ ] +1, don't let Rahul get away - lets try to get him to join the new PMC [ ] -1, no leave him out +1 Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Invite Simon Kitching to join the Apache Commons PMC
Niall Pemberton wrote: [ ] +1, don't let Simon get away - lets try to get him to join the new PMC [ ] -1, no leave him out +1 Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
What is a minor x.x.x release for? Consider the recent modeler vote for 2.0.1. This will probably go through very quickly, and that is because the change involved is tiny and non controversial. That is what these releases are for IMHO - fixing up release process mistakes and major bugs. As a general rule, commons has always preferred x.x releases to fix bugs. Especially bugs which involve the creation of a new class, and the deprecation of an entire existing class. Personally, I expect to be able to drop in a x.x.x without thought. In this case, a LOT of thought is being asked to remove the deprecation. (Although deprecation doesn't require immediate action, many shops require that) To change an application which relies on a static utility class (easy to use, available directly from anywhere), to one using a bean which has to be manually managed (create, delete, pass around to point of use) is a big deal. That doesn't come anywhere close to my definition of an x.x.x release. This isn't about deprecation per se, but the scale of change. I would accept a deprecation of a single method in a non-major part of the library in a x.x.x, but not a whole class where the way to solve the deprecation is so hard. My opinion is that this should be a 1.4. However, if you wish to release more quickly, I offered the option of removing the @deprecated from the static utility class for 1.3.2. Should I do the work? Well, I generally take the view that the RM is in control of the sourcebase during the release period. We also haven't taken a decision on which of the two approaches to take. Finally, as I have previously indicated, my involvement in commons is currently fairly limited due to my JSR310 commitments. However, should you request that I make a change here (the group should decide which change), then I will try and fit it in. Stephen Jochen Wiedmann wrote: On 6/20/07, Phil Steitz [EMAIL PROTECTED] wrote: It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. The problem is simply that votes for releases on commons drive me sick. It is not the exception, but the standard, that people demand changes (which they of course assume that the RM will do) and use a -1 to enforce their opinion. I have a different opinion in this matter. I see absolutely no problem with a compiler warning as long as I may drop in the binary to a running system: *That* is what I call binary compatible and what assume to be the contract for binary releases. My point of view is that he or she who demands such work (going through the docs and find all occurrencies of 1.3.2 and such is a nontrivial work and will easily take two hours or so) should be ready to do it for himself *or* leave it up to me to decide. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
I requested one of two remedies: a) Release as 1.3.2, but undeprecate the static utility class FileCleaner methods (they would be deprecated in 1.4). The static methods can have comments added in 1.3.2 indicating the preferred alternative. b) Release as 1.4. I also have no recollection of a release with an unresolved -1. I would strongly prefer one of the two remedies to be applied. I also agree that we desperately need this to be properly agreed and documented. Stephen - Original Message From: Ben Speakmon [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, 20 June, 2007 5:42:32 AM Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 Is there anything at stake beyond the version number? If it's called 1.4instead of 1.3.2, does that fully answer the concern? On 6/19/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. 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]
[jira] Commented: (IO-123) LineIterator should call close on itself when hasNext() returns false.
[
https://issues.apache.org/jira/browse/IO-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506338
]
Stephen Colebourne commented on IO-123:
---
Unfortunately, if the block of code within the loop throws an exception, then
the file isn't closed.
LineIterator should call close on itself when hasNext() returns false.
--
Key: IO-123
URL: https://issues.apache.org/jira/browse/IO-123
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.3.1
Reporter: Dalibor Novak
Priority: Minor
Fix For: 1.3.2
LineIterator should call close on itself when hasNext() returns false. This
would enable us to write something like this:
for (LineIterator lit = FileUtils.lineIterator(csvFile); lit.hasNext(); )
{
//do something
}
--
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: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
- Original Message From: Phil Steitz [EMAIL PROTECTED] I would like very much for us to agree once and for all on some versioning/deprecation rules. Exactly the thread I was about to start :-) 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 is pretty much my thinking, except that I want to tighten 1c - no removals without prior deprecations allowed in x.0 releases. Source and binary backward incompatible changes may be considered at the edges of the API, but not the core. (We have to be strict as many, many other open source projects rely on commons, and they can't be re-compiled just because of commons. Commons has to act and behave close to the JDK on incompatibilities). Commons needs clarity on this subject, and having it should speed up releases and voting. Stephen - 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
- Original Message From: Phil Steitz [EMAIL PROTECTED] I would like very much for us to agree once and for all on some versioning/deprecation rules. Exactly the thread I was about to start :-) 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 is pretty much my thinking, except that I want to tighten 1c - no removals without prior deprecations allowed in x.0 releases. Source and binary backward incompatible changes may be considered at the edges of the API, but not the core. (We have to be strict as many, many other open source projects rely on commons, and they can't be re-compiled just because of commons. Commons has to act and behave close to the JDK on incompatibilities). Commons needs clarity on this subject, and having it should speed up releases and voting. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1
- Original Message From: Henri Yandell [EMAIL PROTECTED] 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 It is a minor, rather than bugfix. So I think it's fair to say Please recompile. However, also good to keep backwards compat when it's not too painful. -1 to the principle, and thus -1 to the release as is. See the versioning thread for more details. Stephen - 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)
Following subsequent discussions on other threads (and the new versioning thread) I feel I must take a tougher line on this. My vote for the release of 1.3.2 changes to -1. Deprecating a class and adding a new one is inappropriate for a x.x.x release. This should either be 1.4, or the deprecated markers removed from the static class in 1.3.2 (adding comments instead). Stephen - Original Message From: Jochen Wiedmann [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Tuesday, 12 June, 2007 8:26:42 PM 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]
[jira] Commented: (COLLECTIONS-255) Unused variable in TreeBidiMap.java
[ https://issues.apache.org/jira/browse/COLLECTIONS-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502770 ] Stephen Colebourne commented on COLLECTIONS-255: As a general rule, collections implementations use (b). Unused variable in TreeBidiMap.java --- Key: COLLECTIONS-255 URL: https://issues.apache.org/jira/browse/COLLECTIONS-255 Project: Commons Collections Issue Type: Bug Components: BidiMap Affects Versions: Nightly Builds Reporter: Henri Yandell Priority: Trivial Fix For: 3.3 Twice in TreeBidiMap there is an entrySet variable that is not used. Rather the entrySet() method returns a new TreeView every time. We should either: a) Delete the variable. b) Use the variable and always return the same TreeView. I'm thinking a). [Found via http://opensource.fortifysoftware.com/ ] -- 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] 3rd attempt: Release commons-io 1.3.2
Jochen Wiedmann wrote: Please cast your vote. [ ] +1 [ ] =0 [ ] -1 Hmmm, I feel I'd like to vote -1, but that does seem a little unfair as I obviously haven't been following that closely. Officially, my vote is a -0. I hadn't tracked the changes going into [io], but I was surprised to find a newly deparecated class in a minor point release. I would suggest that deprecations should be avoided for minor point releases (that are supposed to be just small bugfixes). My preference would be for one of these to occur: a) FileCleaner to be non-deprecated (see below) b) FileCleaner to be non-deprecated in 1.3.2, but deprecated in 1.4 c) This release to be 1.4 Despite all the discussions, I still believe that having a static method version of FileCleaner seems useful to me. Why should we force our users to have to hold the static reference if they only want or need a singleton? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[io] Next release - was Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
I would normally consider a minor point release to be essential bug fix only (in the numbering system we've been using). Perhaps, rather than trying to release 1.3.2, we should release [io] v1.4 (still JDK1.3 compatible). Stephen - Original Message From: Niall Pemberton [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Tuesday, 22 May, 2007 8:51:10 PM Subject: Re: [VOTE] 2nd attempt: Release commons-io 1.3.2 I committed a small patch to the trunk today (IO-121) - since this release seems delayed is there any objections to me porting this to the 1.3 branch so it makes the 1.3.2 release? https://issues.apache.org/jira/browse/IO-121 The change is v.small - just adding a new resetByteCount() method to ThresholdingOutputStream that has 2 lines in it. Niall On 5/17/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have fixed the issues with the file permissions and added license headers to most of the files, with the only exception of MANIFEST.MF. Now, I'd like to call for another vote on the release of commons-io 1.3.2. The proposed distributables can be found at http://people.apache.org/~jochen/commons-io/dist A KEYS file is included. The proposed site is at http://people.apache.org/~jochen/commons-io/site Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- 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] - 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_12497837 ] Stephen Colebourne commented on LANG-335: - Joda-Time, DateTimeComparator 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: [beanutils] commons collection classes
Torsten Curdt wrote: On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote: I suggest marking the offending methods as deprecated for the 1.x series, and schedule them for removal in the 2.x series. Well, then let's create a 2.x branch and do a release without the classes *now*. No problem with that. Then it is communicated and people can choose. But doing *nothing* just because of binary compatibility is silly. Doing nothing because of binary incompatibility is not silly, its essential. Commons has to be far more extreme than almost any other OSS project on this point. In fact, I contend that commons is now in such a position that we can't make incompatible changes even in major version number releases. Especially as no one *has* to upgrade libraries. And checking release notes if you do can't hurt if you upgrade. Users are forced to upgrade all the time, and thats why they require backwards compatibility. For example, if project A is complied against the old [beanutils] jar, while project B is compiled against the new [beanutils] jar, then it is impossible to use both project A and project B together. You cannot physically upgrade the jar file to the one B needs, because A needs the old one. The only solutions to this at present are - for the 2.x series to have a different package name, including 'v2' - to force the user to play with class loaders, so they can load two different versions of the same class In summary, I suggest we all just let this one be. This isn't causing major pain IMO. The lesson should be to not have dependencies between commons projects wherever possible. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Move to a minimum of JDK 1.4?
I would expect a JDK change to be a major version number change. Stephen Gary Gregory wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Move to a minimum of JDK 1.4?
My preference would be to support JDK1.3 and JDK1.5 versions, rather than JDK1.4. If desired, these calls can be implemented using reflection, so they work on JDK1.4 but not on JDK1.3. Stephen Niall Pemberton 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? 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: [beanutils] commons collection classes
Torsten Curdt wrote: On 18.05.2007, at 13:57, Niall Pemberton wrote: I wasn't part of the decision at the time, but (at least some if not all) these classes are in the BeanUtils public API so changing the package would have (and still will) broken binary compatibility (to remove the dependency on Collections 'coz of its incompatibility between versions!) - they were copied and (AFAIK) the parts of the public API deprecated with the intention of removing them in the next release - but there hasn't been one since that was done and 1.7.0 released. I am not pointing fingers. But whatever it takes - having those classes in there like this is not acceptable and needs to be fixed ASAP. Whilst it may have frustrated you recently, the current situation really isn't that bad. It allowed [beanutils] to drop a 500Kb dependency on [collections] in a simple manner. The copy was permitted as there were few classes involved, and they were very stable. Changing the package name would have been, and still is, backwards incompatible. As such it is unacceptable for such a widely used package as [beanutils]. I am -1 to arbitrarily changing the package name. We really need a prime directive in commons. Don't break backwards compatibility. Every time we do we cause problems down the line - its simple due to our status as the lowest of low libraries. And again, this also emphasises that each commons library works much better when it stands alone - no dependencies. In summary, I am currently -1 to any change here, except possibly producing a commons-beanutils-without-collections.jar file, perhaps as a 1.7.1. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-231) Not return the base interface on decorate
[ https://issues.apache.org/jira/browse/COLLECTIONS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493501 ] Stephen Colebourne commented on COLLECTIONS-231: This change cannot be made as changing the return type is binary incompatible. The constructor is not public as it has a different meaning to a constructor taking a map on a HashMap (decorate vs copy). Not return the base interface on decorate - Key: COLLECTIONS-231 URL: https://issues.apache.org/jira/browse/COLLECTIONS-231 Project: Commons Collections Issue Type: Improvement Components: Map Affects Versions: 3.2 Reporter: Torsten Curdt Fix For: 3.3 At the moment I don't see a reason why the static decorate method does not return ListOrderedMap but just the base interface OrderedMap. I want to decorate a Map to be a ListOrderedMap but due to the fact that the constructor is not visible and decorate only returns the base interface OrderedMap an unnecessary cast is required. ListOrderedMap map = (ListOrderedMap)ListOrderedMap.decorate(new MyMap()); As the decorate method is static and not part of any interface it should be fine to return the real type instead of the base. Otherwise I'd suggest to make the constructor visible. From the API POV It is not really understandable why this ListOrderedMap map = new ListOrderedMap(); is fine and creates a HashMap under the hood while this ListOrderedMap map = new ListOrderedMap(new MyMap())); is not ok. -- 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] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489332 ] Stephen Colebourne commented on LANG-326: - Is there a role for CaseInsensitiveStringUtils instead? How many of these methods need adding? StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- 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: [Jakarta-commons Wiki] Update of TLPResolution by HenriYandell
I am +1 to TLP so long as it specifies Java, possibly 'Java-focussed' to
cover [daemon]. As Phil says, thats not anti-other languages, just a
representation of community.
I also agree that 'small' isn't that useful.
Stephen
Phil Steitz wrote:
This may not be popular or a consensus view, but I would
a) insert Java in front of libraries and components.
b) remove small - I don't think that is possible to define in any
reasonable way and I would not like to see us arguing about numbers of
classes or lines of code.
c) change create and maintain to develop
If we agree on a), we are not re-establishing anything, we are just
moving Jakarta Commons to TLP. I thought that was the proposal.
I think we are already on thin ice in terms of binding and if we
take away to common language, we lose the key ingredient that makes
j-c go, IMHO. Look at the real technical discussion that happens here
and provides value to the components - it is all about Java and
designing reusable components *in Java.*
I would be fine with a Python commons or Ruby Commons or whatever
there is energy to establish, but trying to mix it all up in one
community makes no sense to me and seems like a recipe for
disintegration if we try to turn Jakarta Commons into that.
I am curious as to what others think about this.
Phil
On 4/6/07, Apache Wiki [EMAIL PROTECTED] wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on
Jakarta-commons Wiki for change notification.
The following page has been changed by HenriYandell:
http://wiki.apache.org/jakarta-commons/TLPResolution
--
+ {{{
Establish the Apache Commons project
WHEREAS, the Board of Directors deems it to be in the best
@@ -49, +50 @@
RESOLVED, that all responsibility pertaining to the Commons
sub-project encumbered upon the Apache Jakarta
Project are hereafter discharged.
+ }}}
+ We may need to adjust the resolution slight to say 'Reestablishing',
but I don't think that will be a big change.
+
-
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: [parent-pom] versions
Henri Yandell wrote: Personally I think we should only have the plugins defined if the release jar itself needs them for stability. Otherwise we just deal with whatever pain Maven is throwing everyone's way and yell at them to fix. Er why? It is not our job to be gump and test commons builds against the latest random collection of maven plugins. rant If anyone looks objectively at the amount of time spent on maven on this mailing list over the past few years its incredible. I'd suggest its been a big distraction from actually coding for some people. The basic problem in this case is that maven builds aren't repeatable. They are only repeatable if you have exactly the same version of maven and each one of its many plugins. This isn't something that plagues ant - there if you write a build script it keeps on working - its called backwards compatibility. /rant Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] additions
Matt Benson wrote: - was there a plan for breaking things apart into functors, what else? I would like to see a good discussion on what jars to produce. - Does this really matter?--people can always use tools to create subset jars if they can't deal with the full-size version, no? I don't mind if it ends up as one project producing lots of jars, but we need to produce them, not require others to. - are enhancements to existing classes (as opposed to new classes) still fair game? Yes, IMHO - any objections to me committing in this component? Should I attempt to port to the 1.5 branch? Or will that be a restart? AFAIK, there have been no changes on trunk since the 1.5 branch split, so I would suggest coding in the 1.5 branch. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer - Stephen Kestle
Stephen Colebourne wrote: [X] +1 - Let him commit [ ] 0 [ ] -1 - Perhaps not... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] New committer - Stephen Kestle
Stephen Kestle has been voted in as a new committer for Jakarta: +1 Stephen Colebourne Henri Yandell Joerg Schaible Simon Kitching Niall Pemberton Martin van dem Bemt Phil Steitz Oliver Heger Oliver Zeigermann Rahul Akolkar Stephen K, please see http://www.apache.org/dev/new-committers-guide.html for what happens next. In particular for the CLA you must sign. Contact me off-list with any questions. Stephen Stephen Colebourne wrote: Stephen has spent a considerable amount of effort in discussions and chivying in the commons area, particularly on commons-collections. In another life he has been heavily involved in one of the existing generics ports of collections - http://collections.sf.net. [ ] +1 - Let him commit [ ] 0 [ ] -1 - Perhaps not... 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]
[VOTE] New committer - Stephen Kestle
Stephen has spent a considerable amount of effort in discussions and chivying in the commons area, particularly on commons-collections. In another life he has been heavily involved in one of the existing generics ports of collections - http://collections.sf.net. [ ] +1 - Let him commit [ ] 0 [ ] -1 - Perhaps not... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] Editing the wiki
Stephen Kestle wrote: Does becoming a committer allow me to edit pages such as http://wiki.apache.org/jakarta-commons/Collections? My first action would be to update that so that people can figure out what we're actually doing without trawling mailing lists. You can do that now. Just create a user and make the change. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-243) Generic versions of Predicated, Syncronized and Unmodifiable classes
[ https://issues.apache.org/jira/browse/COLLECTIONS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated COLLECTIONS-243: --- Component/s: Set List Bag Summary: Generic versions of Predicated, Syncronized and Unmodifiable classes (was: generic versions of some more classes) Generic versions of Predicated, Syncronized and Unmodifiable classes Key: COLLECTIONS-243 URL: https://issues.apache.org/jira/browse/COLLECTIONS-243 Project: Commons Collections Issue Type: Improvement Components: Bag, Collection, List, Set Affects Versions: Generics Environment: OS X Reporter: Edwin Tellman Priority: Minor Fix For: Generics Attachments: collections_06_03_11.patch I added generics to some more classes and fixed some compilation problems. The generic version of Transformer required the input and output types to be identical. This seemed to me to reduce the usefulness of transformed collections, as transforming one type into another seems like it would be a fairly common operation. I'm not sure how to fix this, however, as it also doesn't seem feasible to have a generic TransformedCollection with different input and output types that implements CollectionE. Anyway, this patch de-generifies TransformedCollection, which also fixes some compilation problems. Please disregard this change if you disagree and have a better solution. The modified collection classes are: Bags: PredicatedSortedBag, AbstractBagDecorator, SynchronizedBag, UnmodifiableSortedBag, SynchronizedSortedBag, PredicatedBag Lists: PredicatedList, SynchronizedList Sets: PredicatedSortedSet, SynchronizedSortedSet, PredicatedSet, UnmodifiableSortedSet, SynchronizedSet Miscellaneous: PredicatedBuffer -- 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] Commented: (COLLECTIONS-110) Support parametized classes with commons.collections.
[ https://issues.apache.org/jira/browse/COLLECTIONS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481929 ] Stephen Colebourne commented on COLLECTIONS-110: Note for the implementation of generics. List implementations need to consider whether they should implement the JDK interface 'RandomAccess'. Support parametized classes with commons.collections. - Key: COLLECTIONS-110 URL: https://issues.apache.org/jira/browse/COLLECTIONS-110 Project: Commons Collections Issue Type: Wish Environment: Operating System: other Platform: Other Reporter: Colbert Philippe Fix For: Generics It's time to create a parallel version of commons.collections to support parametized classes of each container class and abstract class. It's not that hard. There is a 23 PDF document on Sun Java website describing in detail how it should be done and what to watch out for. I already converted a few classes from commons.collection privately for my own needs. Once you get the hang of it, it's a rather quick process. I am even willing to volunteer my time to do some more but I need the collaboration of some of the original programmers to watch over things. -- 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: [collections] VOTE: Rewriting junit tests (Was: Test cases for compilation failures on generifying collections.)
The collections tests were probably written before the concept of mocks became widely known. I have no problems with the use of mocks for testing in collections, provided that the license of the tool used is compatible with Apache Software Foundation restrictions (no GPL or LGPL). Stephen Stephen Kestle wrote: Ok - the problem is that the end of the test is performing a type safety check. Something that the generic parameters will not allow. The collection under test should contain Collections of Strings, not Strings - that's the same as the closure. Therefore it's a compile error to add a string to the collection. But apart from that - WHAT IS THAT TEST DOING???!!! It's absolutely horrible. It has no place in that class. (Sorry guys, I just hadn't looked at the tests for Commons Collections before this). This is why mock object libraries were created - to ensure that the method under test is the method under test. When testing CollectionUtils, we have no business using reflective Closure implementations, and then testing the bounds of those to ensure they work correctly. If I were to write that test: ClosureNumber testClosure = EasyMock.createMock(Closure.class); IterableLong col = new ArrayListLong(); col.add(1); col.add(2); testClosure.execute(1); //Record the expectation that '1' will be processed testClosure.execute(2); //Record the expectation that '2' will be processed EasyMock.replay(testClosure); CollectionUtils.forAllDo(col, testClosure); EasyMock.verify(testClosure); There - less than half the lines, clear about what it's testing, won't break in the future, unless the method under test breaks, etc, etc. If we were to go ahead with proxied mock based testing (which I would strongly recommend), then I have a (IMHO) really good helper test class for making it even easier than above, and I'd be able to show the really correct way of doing it, without being too much more verbose - lines 2-4 should be something like: IteratorLong iterator = EasyMock.createMock(Iterator.class); IterableLong col= EasyMock.createMock(Iterable.class); EasyMock.expect(col.iterator()).andReturn(iterator); EasyMock.expect(iterator.next()).andReturn(1); EasyMock.expect(iterator.next()).andReturn(2); This would set up the exact way that we want CollectionUtils methods to work (which is what we want in THIS case), and would be extracted to a separate iterableSetUp() method. So, can we import EasyMock as well as Junit4? Our tests should be far more like deterministic mathematical proofs than they are at the moment. Stephen Smith wrote: Hi, Does anyone have any example JUnit 3.x test cases for testing compilation failures on generifying collections? For example, the end of the current test case TestCollectionUtils#testForAllDo asserts that adding invoking CollectionUtils#forAllDo(Collection c, Closure cl) fails when cl is defined to accept Collection and c is defined to contain Strings. After generifying CollectionUtils#forAllDo(CollectionT c, ClosureT cl), the test case will no longer compile and I'd prefer to replace it with a JSE5 compatible assertion rather than delete it - does anyone have any thoughts on this? Steve. - 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: [collections] VOTE: Rewriting junit tests (Was: Test cases for compilation failures on generifying collections.)
MIT is compatible. Raise JIRA calls for everything for now. Stephen Stephen Kestle wrote: Is the MIT license compatible? I'm struggling to figure out whether it is or not... If it is, I'd like to have a go at revamping the CollectionUtils test with something more... concise (and tell, not ask). Should I create a ticket to include this jar etc, or email straight to you? Cheers Stephen Stephen Colebourne wrote: The collections tests were probably written before the concept of mocks became widely known. I have no problems with the use of mocks for testing in collections, provided that the license of the tool used is compatible with Apache Software Foundation restrictions (no GPL or LGPL). Stephen Stephen Kestle wrote: Ok - the problem is that the end of the test is performing a type safety check. Something that the generic parameters will not allow. The collection under test should contain Collections of Strings, not Strings - that's the same as the closure. Therefore it's a compile error to add a string to the collection. But apart from that - WHAT IS THAT TEST DOING???!!! It's absolutely horrible. It has no place in that class. (Sorry guys, I just hadn't looked at the tests for Commons Collections before this). This is why mock object libraries were created - to ensure that the method under test is the method under test. When testing CollectionUtils, we have no business using reflective Closure implementations, and then testing the bounds of those to ensure they work correctly. If I were to write that test: ClosureNumber testClosure = EasyMock.createMock(Closure.class); IterableLong col = new ArrayListLong(); col.add(1); col.add(2); testClosure.execute(1); //Record the expectation that '1' will be processed testClosure.execute(2); //Record the expectation that '2' will be processed EasyMock.replay(testClosure); CollectionUtils.forAllDo(col, testClosure); EasyMock.verify(testClosure); There - less than half the lines, clear about what it's testing, won't break in the future, unless the method under test breaks, etc, etc. If we were to go ahead with proxied mock based testing (which I would strongly recommend), then I have a (IMHO) really good helper test class for making it even easier than above, and I'd be able to show the really correct way of doing it, without being too much more verbose - lines 2-4 should be something like: IteratorLong iterator = EasyMock.createMock(Iterator.class); IterableLong col= EasyMock.createMock(Iterable.class); EasyMock.expect(col.iterator()).andReturn(iterator); EasyMock.expect(iterator.next()).andReturn(1); EasyMock.expect(iterator.next()).andReturn(2); This would set up the exact way that we want CollectionUtils methods to work (which is what we want in THIS case), and would be extracted to a separate iterableSetUp() method. So, can we import EasyMock as well as Junit4? Our tests should be far more like deterministic mathematical proofs than they are at the moment. Stephen Smith wrote: Hi, Does anyone have any example JUnit 3.x test cases for testing compilation failures on generifying collections? For example, the end of the current test case TestCollectionUtils#testForAllDo asserts that adding invoking CollectionUtils#forAllDo(Collection c, Closure cl) fails when cl is defined to accept Collection and c is defined to contain Strings. After generifying CollectionUtils#forAllDo(CollectionT c, ClosureT cl), the test case will no longer compile and I'd prefer to replace it with a JSE5 compatible assertion rather than delete it - does anyone have any thoughts on this? Steve. - 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: Changing the groupId for commons-io
I've failed to be convinced by any argument to change any groupId. It really doesn't seem to cause any harm leaving it as is, so lets leave it as is. Stephen Henri Yandell wrote: I've given up having any clue. If I'm the RM for IO whatever and the changed groupId becomes a blocker, then I'll roll it back. Otherwise sure why not. Hen On 3/13/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, would anyone mind if I change the groupId of commons-io to org.apache.commons? Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - 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: Changing the groupId for commons-io
Jochen Wiedmann wrote: On 3/14/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I've failed to be convinced by any argument to change any groupId. It really doesn't seem to cause any harm leaving it as is, so lets leave it as is. Don't you believe that the Maven 1 conventions were changed with a good reason? It's absolutely plausible that the system of a root directory with hundreds or thousands of groupId's doesn't scale well. By all means, change the id for projects that haven't been released yet. But changing it for existing projects? I'm unconvinced. Apart from that, you are using a tool that draws its power from the conventions to which you adhere. So, why not adhere to it? Maven is a tool which provides power and pain in equal measure. I'm afraid my trust in the tool was lost a long while ago. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-243) generic versions of some more classes
[ https://issues.apache.org/jira/browse/COLLECTIONS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480199 ] Stephen Colebourne commented on COLLECTIONS-243: With all of these cases, you also need to ask if there really are any valid use cases for the collection - TransformedXxx in this case. generic versions of some more classes - Key: COLLECTIONS-243 URL: https://issues.apache.org/jira/browse/COLLECTIONS-243 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: Generics Environment: OS X Reporter: Edwin Tellman Priority: Minor Fix For: Generics Attachments: collections_06_03_11.patch I added generics to some more classes and fixed some compilation problems. The generic version of Transformer required the input and output types to be identical. This seemed to me to reduce the usefulness of transformed collections, as transforming one type into another seems like it would be a fairly common operation. I'm not sure how to fix this, however, as it also doesn't seem feasible to have a generic TransformedCollection with different input and output types that implements CollectionE. Anyway, this patch de-generifies TransformedCollection, which also fixes some compilation problems. Please disregard this change if you disagree and have a better solution. -- 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: [collections] VOTE: Collections-java5 direction
Stephen Smith wrote: Stephen C: earlier in this thread, you mentioned that we'll need to throw away my current ramblings in the existing generics branch, but thats no bad thing - how far did you get with your own work on generifying/genericising (have we even settled on a word for what we're doing yet?), and why exactly do we want to bin it? Well, as much as anything, I don't remember how far I got, or what state its in. I don't think it was that far, but if someone wants to analyse and compare the generics branch to the main branch then go ahead. Perhaps it can be saved. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Committing to collections-java5 branch
OK Stephens (and anyone else!), I'm not in a position to just grant commit access (I wish I could, but thats not the Apache way). However, I am willing to review and apply patches to get generified collections off the ground. We already have a generics branch which is intended to be a 'reboot' of collections rather than a port to generics. The first decision that needs to be made is whether you want to work on a port or a 'reboot'. There is merit in both, and I'm willing to go with the group decision. So start discussing!!! Stephen PS. As a general point, I get the sense that Java 5 is now really in the ascendant, and we could do with generified versions of other commons components sooner rather than later in order to stay relevant. Stephen Smith wrote: Stephen C, if you're looking for volunteers you can count me in - although 3 Stephens working on the same code might get a bit complicated. :) On Fri Mar 9 8:28 , Stephen Kestle sent: Hi, I'd like to help work on the generics stuff for collections, as I've benefited in the past from it. Stephen (C), it looks like you're quite busy and could use a hand, so let me know... Cheers Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Committing to collections-java5 branch
Stephen Smith wrote: 01. Removing all deprecated code - let's take the opportunity to shrink the size of the Commons Collections JAR while we can. +1 02. Removing (*not* deprecating) methods specifically related to type safety pre-JSE5. I'm thinking of classes such as MapUtils here, whose methods such as MapUtils#getDouble have probably had their day. +1, so long as we use a new package name 03. Checking our test case coverage, although I don't remember off the top of my head if Cobertura is plugged into standard Jakarta Commons components. Question: do we want to upgrade our test cases to JUnit 4 as well? I've not used JUnit4 or TestNG, so can't comment on their usefulness 04. Porting generics into the remaining codebase. +1 I think that this is a good balanced approach, although it will be interesting to hear other feedback. BTW, we'll need to throw away my current ramblings in the existing generics branch, but thats no bad thing. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] VOTE: Collections-java5 direction
For example. if we're really going to push the boat out on this, what about hiding public constructors in static utility classes? It's the sort of thing CheckStyle whines about, and normally with good reason. I've never understood why CollectionUtils#CollectionUtils is public, even with a comment along the lines of should not normally be used. If every method is static (and the class is therefore potentially finalised), when would it ever be used? Tools like Velocity need an instance as they can't handle static methods. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Committing to collections-java5 branch
Oliver Zeigermann wrote: Could you explain what your understanding of a 'reboot' is? As opposed to the port to generics? A brand new implementation based on the same idea. StarTrek TNG, Battlestar Galactica, ... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-242) Add Equator interface for more powerful collections
[ https://issues.apache.org/jira/browse/COLLECTIONS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479762 ] Stephen Colebourne commented on COLLECTIONS-242: I think such an interface is a useful extension to the collections framework. Add Equator interface for more powerful collections --- Key: COLLECTIONS-242 URL: https://issues.apache.org/jira/browse/COLLECTIONS-242 Project: Commons Collections Issue Type: Improvement Components: Comparator Reporter: Stephen Kestle Fix For: Generics Java has Comparable and Comparator to compare objects, and objects have an equals() method. But there is no interface for when an object has multiple ways of being equal. e.g.: an database object that has a name, code and a value. Equality could be based on: * database id * code * name and code * case-insensitive name When extended to collections, this allows us to search for specific values (with an EqualsPredicate that takes an Equator), and implement Maps and Sets that use specific equators to determine uniqueness. I propose that it has two methods: boolean equate(); int hash(); I shall upload some files when I next get some time. NB: This ticket is a summary of the email conversation begun on 5 Jan 2007: equator interface (http://archives.devshed.com/forums/java-118/equator-interface-2126195.html). Stephen C made reference there to creating a FlexiMap, but in my mind, that's additional to this issue (this interface still needs to be created to be able to stand alone). -- 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]
[OT] JSR-310 - Date and Time API
Hi all, As you may have seen, I am now the co-spec lead for JSR-310, Date and Time API. This will take forward my work on Joda-Time, hopefully into Java 7. Obviously, this is liable to take up a good proportion of my time (!), so I'll be less able to add stuff or review in commons. Of the places I've worked on in commons, [collections] is the one that needs the most work (generics and lots of open issues). So if anyone has an itch... For anyone who'd like to help out on the JSR, the process will be open mailing list and open wiki (unlike most JSRs). See http://wiki.java.net/bin/view/Projects/DateTimeAPI Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
Jochen Wiedmann wrote: On 2/16/07, Jörg Schaible [EMAIL PROTECTED] wrote: (1) The md5 files do not contain the file name, which is standard for commons components (see section 2 of [1]). This is the way Maven 2 generates *and* checks it. So if you change those, I am quite sure, that every M2 user will get always a warning because of the checksum! I believe that Olivers and your concerms can be resolved by proposing that the files that go into /www/www.apache.org/dist are distributed as proposed by Oliver. OTOH, the files that go into the Maven repository won't have a file name. See commons-io in the maven2 repository: http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/1.3/commons-io-1.3.jar.md5 The *filename part is present. Does it cause any issues? I don't know, I don't use maven 2. I doubt it though as no ones ever complained. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 3.0 thoughts again
I'd like to know how much of 2.x is deprecated. We may need 3.x to be JDK1.3 compatible but without the deprecations. And thus 4.x () to be JDK1.5. Anyway, for me, the project and version number should depend on compatibility. We shouldn't release any new version, even of a major version number, that isn't fully binary compatible. The only thing we can do is remove deprecated methods. (Adding generics can be binary compatible) Stephen - Original Message From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Thursday, 15 February, 2007 8:46:38 AM Subject: [lang] 3.0 thoughts again So... I'd like to: * Move to JDK 1.5 as a minimum (generating class 49 jars to stop accidental usage on pre 1.5). * Remove deprecated code. * Look into other code to deprecate based on the move to JDK 1.5. * Create a CI site, as opposed to a user site. * Move to an m2 build (dropping ant/m1). Based on previous discussions, I'm presuming some of this will raise opinions. Does anyone mind if I start playing with the above on an experimental -3.0 branch (trunk would become 2.4-SNAPSHOT)? 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] 3.0 thoughts again
From: Henri Yandell [EMAIL PROTECTED] So enum package would be removed and enums package would be deprecated as it has a JDK replacement. We would then add functionality around the JDK enums to provide some/all of the value back. maybe. Adding binary compatible generics is a pain in the arse though, right? yes. The best and simplest approach is to create lang5 with a different package, recognising that JDK5 is effectively a separate language as far as library like lang is concerned. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 3.0 thoughts again
Henri Yandell wrote: I would like to avoid the silliness of 'Lang5 1.0, much nicer to emulate Sun's silliness and jump to Lang 5.0, so it sounds like: I suspect that Lang5 1.0 is clearer. 1) Create a branch in Lang for the Lang5 version. 2) Change package name to be org.apache.commons.lang5 or org.apache.commons5.lang. While I quite like the idea of the latter, the s5 looks bad. 3) Change groupId to org.apache.commons [or commons5] because we don't want transitive anyway (nice and easy :) ). 4) The Lang website would contain both the 2.x legacy version and the 5.x future version. Until the 5.x one is released the 2.x release would be the one from which the website is generated; when 5.0 is released it'll switch to being released from the 5.x branch (same time that 5.x and trunk switch). Links would be kept to old javadoc, release notes etc. May be easier to be a new top level component at commons. Or maybe not. It depends on what proportion of difference we're expecting. Does that sound right? Is that what is planned for Collections5? Collections5 was going to be more of a rewrite and rearchitecture. But I doubt I'll have the time for this now. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3.1 (RC3)
+1 We probably should mark the static changed method as @since 1.3.1, but that is not a blocker. Stephen 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]
Re: [VOTE] IO 1.3.1 (RC1)
The release notes have the wrong JIRA number in the incompatability section. Stephen [EMAIL PROTECTED] wrote: Henri Yandell [EMAIL PROTECTED] wrote: I screwed up the 1.3 release, so here's a 1.3.1 release: http://people.apache.org/~bayard/commons-io/1.3.1-rc1/ +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471523 ] Stephen Colebourne commented on IO-113: --- I think that we can probably get away with option (b) if we are quick enough. FileUtils.readFileToString is not static Key: IO-113 URL: https://issues.apache.org/jira/browse/IO-113 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3 Reporter: Raul Acevedo Fix For: 1.4 FileUtils.readFileToString isn't static. It should be; since the constructor for FileUtils says Instances should NOT be constructed in standard programming, this makes readFileToString unusable. Right now I'm using FileUtils.readBytesToByteArray(file).toString(). -- 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] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471117 ] Stephen Colebourne commented on IO-113: --- Problem is that the fix is binary incompatible :-( It is source compatible though. Two choices: a) use a different method name b) produce 1.3.1 now with the binary incompatible change as 1.3 was only just completed FileUtils.readFileToString is not static Key: IO-113 URL: https://issues.apache.org/jira/browse/IO-113 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3 Reporter: Raul Acevedo Fix For: 1.4 FileUtils.readFileToString isn't static. It should be; since the constructor for FileUtils says Instances should NOT be constructed in standard programming, this makes readFileToString unusable. Right now I'm using FileUtils.readBytesToByteArray(file).toString(). -- 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] Lang 2.3 (RC2)
Missing LICENSE and NOTICE in -sources.jar and -javadoc.jar. Missing pom.xml in src bundle. Stephen Henri Yandell wrote: Here's the 2nd release candidate for Lang 2.3: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Vote to close on Saturday if it gets 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: VOTE: Release commons-fileupload 1.2 (3rd attempt)
LICENSE and NOTICE missing from -sources.jar and -javadoc.jar Website has lost a lot of stuff compared to existing website Stephen Jochen Wiedmann wrote: On 2/7/07, Oliver Heger [EMAIL PROTECTED] wrote: Hm, I probably did not follow this thread in the past, so can you please point me to where I find the files of this rc? Awfully sorry, and thanks for asking. The files are available from http://people.apache.org/~jochen/commons-fileupload/dist/ A file rat.txt (RAT report) is included. The proposed site is at http://people.apache.org/~jochen/commons-fileupload/site/ Clirr and checkstyle reports are included in the site. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] PassiveTimeOutMapDecorator
This sounds a little too specific for me. I suspect that most people that want an expiring map will want it to be active not passive. Stephen Elifarley wrote: I've developed a Map decorator which passively evicts expired entries once their expiry time has been reached. When putting an item in the map, the decorator calls the 'expiryTime' method, passing the key and the value as parameters, and uses the returned value as the expiry time for that entry. The default implementation of 'expiryTime' just assigns a time 60 seconds in the future for every entry, but subclasses can provide their own policy. When getting the value for an entry, its expiry time is checked, and if its greater than the current time, the value is returned. Otherwise, the entry is removed from the decorated map, and null is returned. Doing so, there's no need to have a separate, active thread (hence the name 'passive') to check expiry times - the check is performed on demand. I've developed it for my own use, but maybe this could be useful to others too. Any thoughts ? Regards, Elifarley - 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 2.3 (RC2)
Its at the RMs discretion as to whether he wants a new RC. James Carman wrote: Is that a -1? On 2/7/07, Stephen Colebourne [EMAIL PROTECTED] wrote: Missing LICENSE and NOTICE in -sources.jar and -javadoc.jar. Missing pom.xml in src bundle. Stephen Henri Yandell wrote: Here's the 2nd release candidate for Lang 2.3: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Vote to close on Saturday if it gets 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] - 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] exceptions and localization
I'm sorry, but I find this extremely complicated and unreasonable. It really, really, really isn't a direction I want commons to take. Firstly, the use of a static will annoy the IoC (Spring) crowd, so that aspect of the proposal seems flawed. Secondly, this proposes adding a whole ream of new interfaces, classes, resources, factories and strategies to achieve this. All of this additional code will need to be documented in detail, with explanations of how to customise each part. Thirdly, we can be sure that you haven't met all the weird requirements that the users of the library will come up with. They will start asking for changes which will add even more bloat. Fourthly, since none of this is standard, each commons library will probably do it slightly differently, making using all of them together nigh on impossible. Let me be clear, this is a (mostly) well-designed solution to the perceived set of requirements. Its just that the requirements are in my view completely inappropriate. Exceptions are a programming tool. They are used by developers. They are not intended for user interaction. Ever. Adding ANY kind of localization behaviour to [math] or any other commons component is completely OUT OF SCOPE!!! [math] is a library of mathematics routines. Under no circumstances should I need to know or learn or have to worry about this or that localized configuration. Localization is completely orthogonal to the concept of well-tested robust mathematical routines. Finally, what is being proposed here is the creation of a FRAMEWORK. I am so opposed to this because I believe it is the antithesis of what the best commons components are, which is LIBRARIES. A library is simple. It does what it says it does. Without complication or need to buy into its specific religion. A framework is religious. You have to agree to its terms, and its way of doing things. Or choose not to use it. Commons has done pretty well in resisting the complications and religions of frameworks - we are a repository of libraries. So, what is appropriate? It is good to have multiple different exception classes, even as many as one for each different possible error. It is also good for those classes to store the data that caused the error as instance variables accessed by get methods. (http://joda-time.sourceforge.net/xref/org/joda/time/IllegalFieldValueException.html) But they should only have one error message, and no way to localize it (ie. there should be no error code for looking up resources). That is the role of the application/framework that embeds the library - and it can use the exception classname and get methods to access the data if required. Why? because every application/framework that does want to localize wants to do it differently. And in all probability, 90%+ of applications/frameworks don't want to localize at all. Stephen Luc Maisonobe wrote: Two main classes would be used: the MathException base class and a MessageFactory base class. MathException would delegate to MessageFactory the task to build the message from its String key and Object[] parameters (point 2). Both the key, parameters and message would be available with appropriate getters (point 4 and 5). A static method in MathException would allow upper layers to prepend a customized MessageFactory instance (point 1) in front of already registered factories following a chain of responsibility. The initial chain would contain three different MessageFactory instances : - a LocalizedMessageFactory using the key to retrieve a pattern from a ResourceBundle for the default Locale (Locale.geDefault()) and MessageFormat to build the message (point 3) - a NonLocalizedMessageFactory using the key directly as a pattern for MessageFormat - a RawMessageFormat simply concatenating everything with toString The chain of responsibility is intended to provide robustness (point 6): the first message factory providing a non null message is used. If a factory fails, the next one is used. The last factory cannot fail. A user who simply wants to get messages localized for a Locale which is not the default one would therefore only need to do : MathException.prependMessageFactory(new LocalizedMessageFactory(myLocale)); This would work even if its locale is not supported as its factory would always fail but the following ones would be triggered as needed. I think an appropriate policy would be to always use US-english patterns as keys as it would allow to get meaningful messages even if everything else fails, and as it would help the translators tasks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 RC1
Rahul Akolkar wrote: On 2/2/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 2/1/07, Henri Yandell [EMAIL PROTECTED] wrote: What do people think - update PROPOSALs or delete them? Neither - leave it unchanged. It is historical and I think it is obvious it is, many (most?) components have them and I've never seen it raised as a cause for confusion. snap/ Archival is good, I read proposals. But from trunk. One way to avoid potential confusion is to not make it part of the distros, if indeed it is added there. I think the proposal should no longer be part of the website or distro, but left unchanged in SVN. There may be a case for an updated scope doc on the website (ie. a new xdoc). Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 RC1
+1 Although compared to [io] we probably should have a sources and javadoc jar in the zips as well. Stephen Henri Yandell wrote: Next up - Lang 2.3. Here's the release candidate: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc1/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Vote to close on Monday if it gets that far. There is an open issue in JIRA currently: http://issues.apache.org/jira/browse/LANG-69 I'm keeping it open for a little bit longer in case anyone has any opinions on my fix to this. 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 2.3 RC1
Any chance you could unzip the site? Stephen Henri Yandell wrote: Next up - Lang 2.3. Here's the release candidate: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc1/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Vote to close on Monday if it gets that far. There is an open issue in JIRA currently: http://issues.apache.org/jira/browse/LANG-69 I'm keeping it open for a little bit longer in case anyone has any opinions on my fix to this. 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] exceptions and localization
Jörg Schaible wrote: My bottom line: If you build an application, you have to do localization (of exception and logging) at the application layer, because only there you can give the user a context, that is really useful. This implies catching exceptions from libraries and wrapping them with your own and it implies also, that you should have access to the basic parts of the exception (e.g. the file name) easily i.e. usign the exeption's API. This part can be provided by common lib (and the JDK fails here often enough badly), but it cannot serve the requirements of an application it has no knowledge of. I believe that the provision of access to the basic parts of the exception, as described here, is not unreasonable. Its not one I consider essential however. If it can be achieved without over-complicating the exception then fine, however I suspect that to achieve the goal will require many more classes and methods than this actually justifies. This is a case for KISS. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] exceptions and localization
Phil Steitz wrote: I am interested in what others have to say about this as a general practice for commons. For [math] specifically, I think it is important that we can fit seamlessly into localized applications, and we are refactoring our exceptions hierarchy anyway, so I say go for it. I disagree strongly with the whole concept of localized exception messages. Localization for users yes, but developers no. On 1/28/07, Luc Maisonobe [EMAIL PROTECTED] wrote: As a non-native english speaker, I am quite eager to provide users with libraries that can be embedded seemlessly into localized applications. IMO, a localized application actually means localization for users, and implies nothing for developers. Adding localized error messages is another place for the application to go wrong, so you're going to have to test this fully. After all, if you get it wrong, you could lose the real exception and just get a meaningless failed to localize exception. And thats a terrible outcome. For the record, I would -1 any code commit to add localized error messages to a component I actively commit to. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3 (RC3)
+1 Stephen Henri Yandell wrote: I've made a third release candidate of IO 1.3, tagged IO_1_3_RC3. Available at: http://people.apache.org/~bayard/commons-io/1.3-rc3/ Various build files, clirr/jardiff reports and the proposed site. [ ] +1 [ ] -1 Vote to end on Monday (if it makes it that far). The only difference from RC2 are the two build issues Stephen found: 1) MANIFEST contains 1.3 and not 1.2. 2) Javadoc jar for Maven includes LICENSE and NOTICE. 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: (IO-109) FileSystemUtils freeSpaceUnix does not work for HP-UX 11
[
https://issues.apache.org/jira/browse/IO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467701
]
Stephen Colebourne commented on IO-109:
---
The new IO v1.3 release is going to use -kP. Let us know if this works.
FileSystemUtils freeSpaceUnix does not work for HP-UX 11
Key: IO-109
URL: https://issues.apache.org/jira/browse/IO-109
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 1.2
Environment: uname -a
HP-UX mbfwdv B.11.11 U 9000/800 3509210950 unlimited-user license
Reporter: Christopher Olsen
Attachments: FileSystemUtils-HP-UX.fix
The freeSpaceUnix method does not work under HP-UX. The df command under
HP-UX is the old System V varient and the fields are not in the correct
order. This diff modifies the code to use the 'bdf' command when HP-UX is
detected:
--- FileSystemUtils.java2006-03-19 12:42:48.0 -0800
+++ FileSystemUtils-HP-UX-Fix.java 2007-01-11 13:05:34.844269000 -0800
@@ -51,13 +51,15 @@
private static final int WINDOWS = 1;
/** Operating system state flag for Unix. */
private static final int UNIX = 2;
+/** Unix variant name */
+ private static String osName = null;
/** The operating system flag. */
private static final int OS;
static {
int os = OTHER;
try {
-String osName = System.getProperty(os.name);
+osName = System.getProperty(os.name);
if (osName == null) {
throw new IOException(os.name not found);
}
@@ -287,9 +289,18 @@
}
path = FilenameUtils.normalize(path);
+ // HP-UX sucks we need to use bdf instead
+ String dfCmd = df;
+ String dfOpts = -k;
+ if (osName.indexOf(hp-ux) != -1)
+ {
+ dfCmd = bdf;
+ dfOpts = ;
+ }
+
// build and run the 'dir' command
String[] cmdAttribs =
-(kb ? new String[] {df, -k, path} : new String[] {df,
path});
+(kb ? new String[] {dfCmd, dfOpts, path} : new String[] {dfCmd,
path});
// read the output from the command until we come to the second line
long bytes = -1;
--
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] IO 1.3 (RC2)
Two points a) The manifest says version 1.2. Must be fixed. b) The javadoc jar soesn't contain the LICENSE.txt or NOTICE.txt. Not sure if this matters. Stephen Henri Yandell wrote: 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: [collections] additions
Matt Benson wrote: What's the current status of collections? It needs to be broken into smaller pieces before any more weight can be added? Yes, I believe thats a good approach. And the Java 5 branch needs finshing. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
From: Henri Yandell [EMAIL PROTECTED] Yeah, I'm quite interested in what the response is to having this in the API. It's novel (for me), but could be interesting to release IO as is and see what feedback we get from users on the feature. That would seem rather irresponsible. They will almost certainly tell us nothing. If they do oppose it then there will be nothing we can do as its backwards incompatible to change it. I would have just checked in the change last night if I wasn't so busy talking about Java 7 language changes Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
Henri Yandell wrote: So consensus so far seems to be towards leaving it in. Well I'll remove my vote -1 then. But I still think its poor design. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
From: Henri Yandell [EMAIL PROTECTED] This helps with naming, but without the scoping, you're left with the Javadocs as the only way to specify that the exception is intended to be used only within the DirectoryWalker class. Of course, a public static inner class can be used elsewhere as well, but the relationship with the enclosing class makes a clear statement of intent. We can agree to disagree, though - I was mostly just interested in what the arguments are against using inner classes, given that I see very clear and meaningful reasons for using them. Ditto. Your arguments are good, so I'm quite happy to go with whatever consensus is on this one. I think the other argument is that the JDK doesn't have inner exception classes (well, maybe it does, but I can't think of any well-known ones ATM). Since [io] is a JDK+ library, I'd say we should have no inner exceptions. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3 RC1
-1, here's why... After reviewing the javadoc, I realised that having an inner class as an exception is A Bad Idea. It looks wrong in Javadoc, and will look wrong in code. I propose that this exception is promoted to a top level class, and renamed to DirectoryWalkCancelledException. Since we need to build a new RC for Niall's fix, this shouldn't be a big problem if people agree. If people disagree with my analysis, then I will of course re-evaluate this -1 (for which I apologise...) Stephen Henri Yandell wrote: I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1. Available at: http://people.apache.org/~bayard/commons-io/1.3-rc1/ 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: [io] Inner class exception
Martin Cooper wrote: Could you say more about this, please? I happen to disagree on exceptions as inner classes being a bad idea; FileUpload has done this for years, without any problems. But I'm always interested in hearing new perspectives... I guess its stylistic, and therefore subjective. But I see an exception as a critical system object, and not one that should be relegated to inner class status. I pretty much only use inner classes for the internals of the main class. Details that shouldn't be exposed as part of the public API, except for very specialist users. Catching a cancellation exception doesn't seem to be a special case. For example, I also dislike Map.Entry, and think it should be MapEntry. (Well, actually I think map entries are the biggest mistake in the collections framework but thats another story...) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1 Henri Yandell wrote: As you can see on the list, Matt would like to help out with JXPath. Matt's been an Ant committer since Feb 2004. He's been active on the dev/user lists over the last couple of years, so not a new face here either. [ ] +1 [ ] -1 Will end the vote on Tuesday morning. 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: [jxpath] 1.3
Matt Benson wrote: Can somebody (Henri?) offer advice on what I and/or other members of the (user and/or Apache committer) community might do to get the ball rolling? Some things to think about: - updating the license in each source file to the latest ASF standards - update the xdocs site generation to fit better with other components: -- see http://wiki.apache.org/jakarta-commons/MavenWebsiteStucture -- update home page with documentation/releases/support section -- add cvs-usage.xml, issue-tracking.xml - compare project.xml to other components Generally, take a look at [io] or [lang], compare and update as appropriate. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ang] pre 2.3 build
Henri Yandell wrote: Anything need fixing up before doing the real build? I don't like the new table on the home page. I think it provides too much information, and mainly information that isn't that relevant. Its also inconsistent with the other similar commons sites, notably in that releases is now above documentation. (Yes, I know this is minor, but all this helps consistency. If we do change this, we should change it elsewhere too.) If it is to be kept then perhaps the release notes column should always have the text 'release notes'? and the javadoc column 'javadoc'. Perhaps there should be a download column? Also, javadoc for 1.0 isn't online, so a symlink to 1.0.1 would need to be created. And if we do keep it, then perhaps the releases and documentation section should be merged. I think the best solution would be to move the data to a separate release history page? The home page then just references the download and javadoc of the latest version, probably in a combined releases and documentation section. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Collections] Equator interface
Stephen Kestle wrote: If an Equator is determined to be something worthwhile for the next (generic) version of Collections, I can provide interfaces, default implementations tests etc. I certainly think that there are multiple ways to to equals checks. In my day job we compare by ==, equals and id. Done well, this would make a good enhancement in the 'new' collections. BTW, I favour trying to create a 'FlexiMap' map implementation, which has pluggable hashcode/equals/weakReference/softReference/... So, if anyone wants to give that a go feel free! Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-306) Extra StrBuilder methods
[ https://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated LANG-306: Attachment: lang.patch Extra StrBuilder methods Key: LANG-306 URL: https://issues.apache.org/jira/browse/LANG-306 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: 2.3 Attachments: lang.patch, StrBuilder.java Append all the elements in a collection with no separator: StrBuilder.appendAll(Collection) StrBuilder.appendAll(Object[]) StrBuilder.appendAll(Iterator) Append the data followed by a new line: StrBuilder.appendln(...) Append a separator if the buffer is not empty: StrBuilder.appendSeparator(String) Append a separator if the index 0: StrBuilder.appendSeparator(String, index) -- 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: [io] Pre 1.3 build
Jörg Schaible wrote: M2 creates -sources.jar files :) Personally, I like -src-ide.zip, but I can't be bothered to fight the maven god on this. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-310) BooleanUtils isNotTrue/isNotFalse
BooleanUtils isNotTrue/isNotFalse - Key: LANG-310 URL: https://issues.apache.org/jira/browse/LANG-310 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Assigned To: Stephen Colebourne Priority: Minor Fix For: 2.3 Add two methods to BooleanUtils - isNotTrue - isNotFalse These make writing if statements a lot clearer when handling nulls. -- 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] Closed: (LANG-310) BooleanUtils isNotTrue/isNotFalse
[ https://issues.apache.org/jira/browse/LANG-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne closed LANG-310. --- Resolution: Fixed svn commit C:\dev\commons\lang\RELEASE-NOTES.txt C:\dev\commons\lang\src\java\org\apache\commons\lang\BooleanUtils.java C:\dev\commons\lang\src\test\org\apache\commons\lang\BooleanUtilsTest.java -N -m LANG-310 - BooleanUtils isNotTrue/isNotFalse --username scolebourne M C:\dev\commons\lang\RELEASE-NOTES.txt M C:\dev\commons\lang\src\java\org\apache\commons\lang\BooleanUtils.java M C:\dev\commons\lang\src\test\org\apache\commons\lang\BooleanUtilsTest.java Transmitting file data: C:\dev\commons\lang\RELEASE-NOTES.txt Transmitting file data: C:\dev\commons\lang\src\java\org\apache\commons\lang\BooleanUtils.java Transmitting file data: C:\dev\commons\lang\src\test\org\apache\commons\lang\BooleanUtilsTest.java Committed revision 492361 * BooleanUtils isNotTrue/isNotFalse - Key: LANG-310 URL: https://issues.apache.org/jira/browse/LANG-310 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Assigned To: Stephen Colebourne Priority: Minor Fix For: 2.3 Add two methods to BooleanUtils - isNotTrue - isNotFalse These make writing if statements a lot clearer when handling nulls. -- 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] Closed: (LANG-306) Extra StrBuilder methods
[ https://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne closed LANG-306. --- Resolution: Fixed Assignee: Stephen Colebourne svn commit C:\dev\commons\lang\RELEASE-NOTES.txt C:\dev\commons\lang\src\java\org\apache\commons\lang\text\StrBuilder.java C:\dev\commons\lang\src\test\org\apache\commons\lang\text\StrBuilderAppendInsertTest.java -N -m LANG-306 - StrBuilder appendln/appendAll/appendSeparator --username scolebourne M C:\dev\commons\lang\RELEASE-NOTES.txt M C:\dev\commons\lang\src\java\org\apache\commons\lang\text\StrBuilder.java M C:\dev\commons\lang\src\test\org\apache\commons\lang\text\StrBuilderAppendInsertTest.java Transmitting file data: C:\dev\commons\lang\RELEASE-NOTES.txt Transmitting file data: C:\dev\commons\lang\src\java\org\apache\commons\lang\text\StrBuilder.java Transmitting file data: C:\dev\commons\lang\src\test\org\apache\commons\lang\text\StrBuilderAppendInsertTest.java Committed revision 492369 Extra StrBuilder methods Key: LANG-306 URL: https://issues.apache.org/jira/browse/LANG-306 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Assigned To: Stephen Colebourne Priority: Minor Fix For: 2.3 Attachments: lang.patch, StrBuilder.java Append all the elements in a collection with no separator: StrBuilder.appendAll(Collection) StrBuilder.appendAll(Object[]) StrBuilder.appendAll(Iterator) Append the data followed by a new line: StrBuilder.appendln(...) Append a separator if the buffer is not empty: StrBuilder.appendSeparator(String) Append a separator if the index 0: StrBuilder.appendSeparator(String, index) -- 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] Closed: (LANG-275) Add a pair of StringUtils.substringsBetween;String[] methods
[ https://issues.apache.org/jira/browse/LANG-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne closed LANG-275. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.3 Assignee: Stephen Colebourne svn commit C:\dev\commons\lang\RELEASE-NOTES.txt C:\dev\commons\lang\project.xml C:\dev\commons\lang\src\java\org\apache\commons\lang\StringUtils.java C:\dev\commons\lang\src\test\org\apache\commons\lang\StringUtilsSubstringTest.java -N -m LANG-275 - StringUtils substringsBetween, implemented by Dave Meikle --username scolebourne M C:\dev\commons\lang\RELEASE-NOTES.txt M C:\dev\commons\lang\project.xml M C:\dev\commons\lang\src\java\org\apache\commons\lang\StringUtils.java M C:\dev\commons\lang\src\test\org\apache\commons\lang\StringUtilsSubstringTest.java Transmitting file data: C:\dev\commons\lang\RELEASE-NOTES.txt Transmitting file data: C:\dev\commons\lang\project.xml Transmitting file data: C:\dev\commons\lang\src\java\org\apache\commons\lang\StringUtils.java Transmitting file data: C:\dev\commons\lang\src\test\org\apache\commons\lang\StringUtilsSubstringTest.java Committed revision 492377 Add a pair of StringUtils.substringsBetween;String[] methods Key: LANG-275 URL: https://issues.apache.org/jira/browse/LANG-275 Project: Commons Lang Issue Type: Wish Reporter: Henri Yandell Assigned To: Stephen Colebourne Priority: Minor Fix For: 2.3 Attachments: LANG-275.patch I found myself wanting a version of substringBetween(String, String, String) that would return a String[] of the ones between and not just the single String for the first match. -- 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: [lang] svn commit: r492361 - in /jakarta/commons/proper/lang/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/lang/BooleanUtils.java src/test/org/apache/commons/lang/BooleanUtilsTest.java
Rahul Akolkar wrote:
+ * BooleanUtils.isNotTrue(Boolean.TRUE) = true
+ * BooleanUtils.isNotTrue(Boolean.FALSE) = false
+ * BooleanUtils.isNotTrue(null) = true
+ */
+public static boolean isNotFalse(Boolean bool) {
+return !isFalse(bool);
+}
+
snap/
Javadoc for this method (pre section) has incorrect method name.
Fixed, ta!
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-309) Add ArrayUtils.addFirst methods.
[ https://issues.apache.org/jira/browse/LANG-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462109 ] Stephen Colebourne commented on LANG-309: - The problem with the arrays methods is that there are a lot of them. Personally, this one doesn't rock my boat, as writing '0' comes pretty naturally. And I'd say that inserting an item at the start of an array is probably pretty rare anyway. 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]
[jira] Created: (LANG-306) Extra StrBuilder methods
Extra StrBuilder methods Key: LANG-306 URL: http://issues.apache.org/jira/browse/LANG-306 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: 2.3 Append all the elements in a collection with no separator: StrBuilder.appendAll(Collection) StrBuilder.appendAll(Object[]) StrBuilder.appendAll(Iterator) Append the data followed by a new line: StrBuilder.appendln(...) Append a separator if the buffer is not empty: StrBuilder.appendSeparator(String) Append a separator if the index 0: StrBuilder.appendSeparator(String, index) -- 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-306) Extra StrBuilder methods
[ http://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated LANG-306: Attachment: StrBuilder.java Extra StrBuilder methods Key: LANG-306 URL: http://issues.apache.org/jira/browse/LANG-306 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: 2.3 Attachments: StrBuilder.java Append all the elements in a collection with no separator: StrBuilder.appendAll(Collection) StrBuilder.appendAll(Object[]) StrBuilder.appendAll(Iterator) Append the data followed by a new line: StrBuilder.appendln(...) Append a separator if the buffer is not empty: StrBuilder.appendSeparator(String) Append a separator if the index 0: StrBuilder.appendSeparator(String, index) -- 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: [pool] Stable links to javadoc for released versions
Phil Steitz wrote: The [dbcp] javadoc includes links to [pool] APIs. Currently, [dbcp]'s maven.javadoc.links points to http://jakarta.apache.org/commons/pool/apidocs, which is no good, since this will in general point to the current development API. I was going to fix this by following the convention that we use in [math] that /math/api-x.y/ will be a stable URL for the x.yrelease javadoc. Currently, [lang], [io], [collections] and [primitives] also do this, so its already quite a convention. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] What's in a distribution?
Dennis Lundberg wrote: 1. What should a source distribution include? Two things: - commons-foo-1.0.jar - the binary jar - The entire svn tree for the project I include the binary jar file in the source distribution as I want to ensure that the maximum number of people possible get the genuine binary jar as created by us and no-one else (eg. minimises JDK1.3 vs JDK1.6 issues) 2. What should a binary distribution include? Three things: - commons-foo-1.0.jar - the binary jar - commons-foo-1.0-src-ide.zip - the source code - The javadoc I include the source zip in the binary distribution as I think most people want to attach the source to their jar files, at least in commons. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r491956 - /jakarta/commons/proper/lang/trunk/build.xml
I think it may allow the jar to be created on JDK1.3, and the dist on JDK1.4, but you'll need to check that. [EMAIL PROTECTED] wrote: Author: bayard Date: Tue Jan 2 14:47:03 2007 New Revision: 491956 URL: http://svn.apache.org/viewvc?view=revrev=491956 Log: Don't get the point of 'dist' and 'dist-build' being separate, so merging them - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-306) Extra StrBuilder methods
[ http://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461869 ] Stephen Colebourne commented on LANG-306: - Decision of the Release Manager. I wasn't expecting that they would make it in. Especially as they don't have tests yet, and its late... Extra StrBuilder methods Key: LANG-306 URL: http://issues.apache.org/jira/browse/LANG-306 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: 2.3 Attachments: StrBuilder.java Append all the elements in a collection with no separator: StrBuilder.appendAll(Collection) StrBuilder.appendAll(Object[]) StrBuilder.appendAll(Iterator) Append the data followed by a new line: StrBuilder.appendln(...) Append a separator if the buffer is not empty: StrBuilder.appendSeparator(String) Append a separator if the index 0: StrBuilder.appendSeparator(String, index) -- 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-238) [lang] Add equals(type[]) to NumberUtils
[ http://issues.apache.org/jira/browse/LANG-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461614 ] Stephen Colebourne commented on LANG-238: - This newly defined method seems a little unusual - is it really a generic use case? How often do you need to test that all elements in an array are the same? A more general related method might be: containsOnly(arrayToTest, arrayOfPermittedValues) [lang] Add equals(type[]) to NumberUtils Key: LANG-238 URL: http://issues.apache.org/jira/browse/LANG-238 Project: Commons Lang Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: other Platform: Other Reporter: Paul Benedict Priority: Minor Fix For: 3.0 It would be useful to add an equals() method like the current min and max methods which take an array type and determine if all the values are equal. I have found myself in need of this often. I have to retrieve objects from multiple data sources in parallel to build an array of complex object. To ensure validity, I always compare that my sub-retrievals returned the same number of objects as expected. -- 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
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]
Re: svn commit: r491359 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java
This was a recent bug fix. Do we have tests to show that removing this cast doesn't cause the bug to reappear? Stephen [EMAIL PROTECTED] wrote: Author: ggregory Date: Sat Dec 30 17:08:34 2006 New Revision: 491359 URL: http://svn.apache.org/viewvc?view=revrev=491359 Log: Remove unnecessary cast from long to long. Modified: jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java Modified: jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java?view=diffrev=491359r1=491358r2=491359 == --- jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java (original) +++ jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java Sat Dec 30 17:08:34 2006 @@ -224,7 +224,7 @@ ( ( data[ offset + 5 ] 0xff ) 8 ) + ( ( data[ offset + 6 ] 0xff ) 16 ) + ( ( data[ offset + 7 ] 0xff ) 24 ); -return ((long) high 32) + (0xL low); +return (high 32) + (0xL low); } /** - 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: (IO-99) FileCleaner thread never ends and cause memory leak in AS
[ http://issues.apache.org/jira/browse/IO-99?page=all ] Stephen Colebourne resolved IO-99. -- Resolution: Fixed Assignee: Stephen Colebourne I took a look at getTrackerCount(), but its already synchronized because the list is a Vector. I added a few comments about synchronization to the file to help clarify. Closing the call as fixed. FileCleaner thread never ends and cause memory leak in AS - Key: IO-99 URL: http://issues.apache.org/jira/browse/IO-99 Project: Commons IO Issue Type: Bug Affects Versions: 1.2 Environment: JBOssPortal with commons.fileupload Reporter: Vera Mickaël Assigned To: Stephen Colebourne Priority: Critical Fix For: 1.3 Attachments: IO-99.patch FileCleaner opens a thread and no solution is given to the user to end it. So when an application is undeployed in an Application Server, a thread is still alive. The WebApp can't be undeployed and this results in a classloader leak that will cause an OutOfMemoryError. I think the API should be extended so that a user can end the thread. A better way would be to provide a class that cleans everything for commons IO. -- 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: (IO-97) Trivial performance improvements to ByteArrayOutputStream
[ http://issues.apache.org/jira/browse/IO-97?page=all ] Stephen Colebourne resolved IO-97. -- Fix Version/s: 1.3 (was: 1.4) Resolution: Fixed Assignee: Stephen Colebourne Trivial performance improvements to ByteArrayOutputStream - Key: IO-97 URL: http://issues.apache.org/jira/browse/IO-97 Project: Commons IO Issue Type: Improvement Components: Streams/Writers Affects Versions: 1.2 Reporter: Holger Hoffstätte Assigned To: Stephen Colebourne Fix For: 1.3 Attachments: BAOS.patch Found a few trivial ways to improve performance in ByteArrayOutputStream by fast paths: - write(int) does not have to be synchronized - write(byte[]..) does not have to be synchronized as a whole either; it's enough to synchonize the code that follows the first paramter-checking if-then statement (so parameter checks can pop out quickly) - toByteArray() could just check if count == 0 and quickly return an empty static final byte[] instead of returning a new zero-sized one, doing useless System.arraycopy() etc. A somewhat more involved optimization would be to implement write(int) without the new byte[1] since just poking the byte into the right page is going to be much faster than what happens in write(byte[]..); I'll see if I can do a patch for that. -- 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]
