[jira] Updated: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-362: - Attachment: ExtendedMessageFormatTest.java Attaching a test case for ExtendedMessageFormat that I think should replace the existing four test classes. Note this includes a couple of tests for custom sub-formats which currently fail. > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, > ExtendedMessageFormatTest.java, FormatFactory.java > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened LANG-362: -- OK I have a couple of points - Custom sub-formats are not supported - so if I embed a "custom" format in a choice format it throws an IllegalArgumentException. Do we want to support that scenario or document clearly that it doesn't work? (I did make this point in https://issues.apache.org/jira/browse/LANG-362?focusedCommentId=12564290#action_12564290) - Now the setFormats(), setFormat(), and setFormatByArgumentIndex() all throw UnsupportedOperationException I don't see the need for the logic to re-create the pattern - much simpler to just cache the pattern the EMF was created with and return that value in toPattern() - or am I missing something? - the test cases could (and IMO should) be simpler - currently there are four classes to test EMF (AbstractMessageFormatTest, ExtendedMessageFormatBaselineTest, MessageFormatExtensionTest. and MessageFormatTest) and I don't see why we don't just have one ExtendedMessageFormatTest). Tests are often a good way to look at how something works - so the simpler the better both for those maintaining it and users wanting to understand how to use it. > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, > FormatFactory.java > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-156) add methods normalizePreserveSepartor and normalizePreserverSepartorNoEndseparator
[ https://issues.apache.org/jira/browse/IO-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570208#action_12570208 ] Niall Pemberton commented on IO-156: Do we really need this - you can use the normalize() / normalizeNoEndSeparator() methods in combination with either separatorsToWindows() or separatorsToUnix() to achieve this. > add methods normalizePreserveSepartor and > normalizePreserverSepartorNoEndseparator > -- > > Key: IO-156 > URL: https://issues.apache.org/jira/browse/IO-156 > Project: Commons IO > Issue Type: New Feature >Affects Versions: 1.3.2 >Reporter: Michael >Priority: Minor > > Those are the same methods as normalize(String filename) and > normalizeNoEndSeparator(String filename) but without converting path > separator to the platform. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-118) Change forceDelete API to return the boolean success
[ https://issues.apache.org/jira/browse/IO-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570196#action_12570196 ] Niall Pemberton commented on IO-118: I don't see the point of this now since deleteQuietly was introduced in 1.4 - why break compatibility on forceDelete to make it work like deleteQuietly - when people can just use deleteQuietly? Seems to me like we now provide two good options with both forceDelete() and deleteQuietly() for whatever people prefer - either return a boolean or throw an exception. I think this ticket just predated deleteQuietly() (IO-135) and we should now close it as WONT FIX. > Change forceDelete API to return the boolean success > > > Key: IO-118 > URL: https://issues.apache.org/jira/browse/IO-118 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 1.3.1 >Reporter: Henri Yandell > Fix For: 2.x > > > (Though I imagine it'll be 2.0 for API versioning, but reporting anyway). > Would be nice to return the boolean that the delete method returns in > forceDelete. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-192) Operator precedence driven parser
[ https://issues.apache.org/jira/browse/MATH-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569730#action_12569730 ] Niall Pemberton commented on MATH-192: -- Just to clarify - this is currently part of the matheclipse sourceforge project? http://www.matheclipse.org/ Also was the parser generated using JavaCC or ANTLR or some other such tool - if so which? > Operator precedence driven parser > -- > > Key: MATH-192 > URL: https://issues.apache.org/jira/browse/MATH-192 > Project: Commons Math > Issue Type: New Feature > Environment: Tested with commons-math-1.2-RC1-src >Reporter: Axel Kramer >Priority: Minor > Attachments: parser.zip > > > Attached are sources for an operator precedence driven parser as described > here: > http://en.wikipedia.org/wiki/Operator-precedence_parser > At the moment the used syntax for the math expressions is very similar to the > Mathematica input syntax > and must probably be reworked for the common maths needs. > Mainly the parser is driven by the arrays HEADER_STRINGS, OPERATOR_STRINGS > and OPERATORS in the: > org.matheclipse.parser.operator.ASTNodeFactory > class. > There's a utility class > org.matheclipse.parser.util.GenerateOperatorArrays > which generates the above arrays for operator sets defined in a textfile like > for example > /org.matheclipse.parser/eval/src/operators.txt > JUnit test classes for testing the pure parser without any evaluations: > /org.matheclipse.parser.test/src/org/matheclipse/parser/test/AllParserTests.java > JUnit test classes for testing the evaluation in double or Complex > calculation mode: > /org.matheclipse.parser.test/src/org/matheclipse/parser/test/eval/AllEvalTests.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COMMONSSITE-25) http://commons.apache.org/license.html problems
[ https://issues.apache.org/jira/browse/COMMONSSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved COMMONSSITE-25. Resolution: Fixed > http://commons.apache.org/license.html problems > --- > > Key: COMMONSSITE-25 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-25 > Project: Commons All > Issue Type: Bug > Components: Site >Reporter: Sebb > > The page > http://commons.apache.org/license.html > displays incorrectly as a single column rather than as left hand navigation > with content on the right. > The HTML Title says: "Commons Build Plugin - Project License" which looks > wrong. > The Overview says: > "Typically the licenses listed for the project are that of the project > itself, and not of dependencies." > which does not seem very helpful - how does one distinguish the atypical > cases? > Anyway, surely ALL commons code is released under the AL license (1.0 or 2.0). > Also, why have a separate copy of the license? Surely it would be better to > link to the ASF version at: > http://www.apache.org/licenses/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-25) http://commons.apache.org/license.html problems
[ https://issues.apache.org/jira/browse/COMMONSSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569705#action_12569705 ] Niall Pemberton commented on COMMONSSITE-25: Apologies - my mistake, the license page didn't generate properly for commons-build-plugin so I re-generated it and looks like I uploaded it to the wrong place. I have corrected this and (hopefully) commons-build-plugin. Should be OK at the next sync. > http://commons.apache.org/license.html problems > --- > > Key: COMMONSSITE-25 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-25 > Project: Commons All > Issue Type: Bug > Components: Site >Reporter: Sebb > > The page > http://commons.apache.org/license.html > displays incorrectly as a single column rather than as left hand navigation > with content on the right. > The HTML Title says: "Commons Build Plugin - Project License" which looks > wrong. > The Overview says: > "Typically the licenses listed for the project are that of the project > itself, and not of dependencies." > which does not seem very helpful - how does one distinguish the atypical > cases? > Anyway, surely ALL commons code is released under the AL license (1.0 or 2.0). > Also, why have a separate copy of the license? Surely it would be better to > link to the ASF version at: > http://www.apache.org/licenses/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-303) Merge Capabilities
[ https://issues.apache.org/jira/browse/BEANUTILS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-303: -- Fix Version/s: LATER THAN 1.8.0 > Merge Capabilities > -- > > Key: BEANUTILS-303 > URL: https://issues.apache.org/jira/browse/BEANUTILS-303 > Project: Commons BeanUtils > Issue Type: Improvement >Reporter: Rodrigo di Lorenzo Lopes >Priority: Minor > Fix For: LATER THAN 1.8.0 > > Attachments: patch.txt > > Original Estimate: 24h > Remaining Estimate: 24h > > BeanUtils doesn't offer an adequate way to merge values from two JavaBeans. > Ex: > From different sources, let there be two partially populated JavaBeans > (each in different properties) . How to combine these JavaBeans ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-301) In ArrayConverter, the allowedChars array should (possibly) include the underscore character
[ https://issues.apache.org/jira/browse/BEANUTILS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-301. --- Resolution: Won't Fix > In ArrayConverter, the allowedChars array should (possibly) include the > underscore character > > > Key: BEANUTILS-301 > URL: https://issues.apache.org/jira/browse/BEANUTILS-301 > Project: Commons BeanUtils > Issue Type: Improvement > Components: ConvertUtils & Converters >Affects Versions: 1.8.0-BETA > Environment: All >Reporter: Martin Bartlett >Priority: Minor > > An array value passed as: > this_is_my_first_value,this_is_my_second_value > should (could: please) result in a two-element array - currently the "_" is > not recognized as a word character and thus results in the StreamTokenizer > splitting each string at the underscore. Maybe ALL Java symbol characters > should be recognized? This would avoid unnecessary quoting ala > "this_is_my_first_value","this_is_my_second_value" > (note there is also a BUG related to this, since parsing the above string > also results in an NPE in the current BETA- report to follow) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-298) MethodUtils.getAccessibleMethod(Method method) could not find right public method
[
https://issues.apache.org/jira/browse/BEANUTILS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated BEANUTILS-298:
--
Fix Version/s: 1.8.0
> MethodUtils.getAccessibleMethod(Method method) could not find right public
> method
> -
>
> Key: BEANUTILS-298
> URL: https://issues.apache.org/jira/browse/BEANUTILS-298
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.7.0, 1.8.0-BETA
> Environment: Java 1.5, Windows XP
>Reporter: Roman Mukhin
>Priority: Minor
> Fix For: 1.8.0
>
>
> Let assume follows:
> public interface IX {
> getName();
> }
> class BaseX {
> public getName();
> }
> class ImplX extends BaseX implements IX {
> }
> For some reason I do not want that BaseX implements IX, but if we have a bean
> of type ImplX we can call getName().
> PropertyUtils.getProperty(beanOfTypeBaseX, "name") could not get the value,
> because the method MethodUtils.getAccessibleMethod(Method method) looks up
> only throunght supercalsses and interfaces of implementing class but not the
> subclasses and interfaces that they implement!
> So PropertyUtils.getProperty(beanOfTypeBaseX, "name") throws an Exception
> that the method is not accessible, but at the same time I can call
> beanOfTypeBaseX.getName()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-299) ConvertingWrapDynaBean should allow custom BeanUtilsBean
[
https://issues.apache.org/jira/browse/BEANUTILS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated BEANUTILS-299:
--
Component/s: DynaBean
Fix Version/s: LATER THAN 1.8.0
> ConvertingWrapDynaBean should allow custom BeanUtilsBean
>
>
> Key: BEANUTILS-299
> URL: https://issues.apache.org/jira/browse/BEANUTILS-299
> Project: Commons BeanUtils
> Issue Type: Improvement
> Components: DynaBean
>Reporter: Heikki Vesalainen
> Fix For: LATER THAN 1.8.0
>
>
> ConvertingWrapDynaBean should accept as constructor parameter a custom
> BeanUtilsBean and use that instead of the static BeanUtils.
> like so:
> BeanUtilsBean beanUtils;
> public ConvertingWrapDynaBean(Object instance, BeanUtilsBean beanUtils) {
> super(instance);
> this.beanUtils = beanUtils;
> }
> public ConvertingWrapDynaBean(Object instance) {
> this(instance, new BeanUtilsBean);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-294) BeanUtilsBean.setProperty() does not support nested map
[ https://issues.apache.org/jira/browse/BEANUTILS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-294: -- Fix Version/s: 1.8.0 Yes you're right, I'll put this on the list for 1.8.0 > BeanUtilsBean.setProperty() does not support nested map > --- > > Key: BEANUTILS-294 > URL: https://issues.apache.org/jira/browse/BEANUTILS-294 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.0-BETA >Reporter: Stephen Leung >Priority: Critical > Fix For: 1.8.0 > > > I tried to call BeanUtilsBean.setProperty() with a DynaActionForm as the > "bean" and "someMap(x)(y)" as the "name". In BeanUtilsBean.setProperty(), > after the while loop at line 900, target became "null" and name became = > "(y)". And consequently IllegalArgumentException is thrown at line 930 when > setProperty() tried to getPropertyDescriptor() of a null bean. Specifically, > the following is the stack trace. Could somebody look into it? > Thanks. > java.lang.IllegalArgumentException: No bean specified > at > org.apache.common.beanutils.PropertyUtilsBean.getPropertyDescriptor(PropertyUtilsBean.java:871) > at > org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:930) > at > org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:829) > at > org.apache.commons.beanutils.BeanUtils.populate(BeanUtilsBean.java:433) > at org.apache.struts.util.RequestUtils.pouplate(RequestUtils.java:467) > .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-306) LocaleConvertUtilsBean.convert throws NPE on null Locale when debug logging is enabled
[ https://issues.apache.org/jira/browse/BEANUTILS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-306. --- Resolution: Fixed Fix Version/s: 1.8.0 Assignee: Niall Pemberton Fixed thanks! http://svn.apache.org/viewvc?view=rev&revision=628158 > LocaleConvertUtilsBean.convert throws NPE on null Locale when debug logging > is enabled > -- > > Key: BEANUTILS-306 > URL: https://issues.apache.org/jira/browse/BEANUTILS-306 > Project: Commons BeanUtils > Issue Type: Bug > Components: Locale BeanUtils / Converters >Affects Versions: 1.7.0, 1.8.0-BETA >Reporter: Lucian Chirita >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.8.0 > > > LocaleConvertUtilsBean.convert(String value, Class clazz, Locale locale, > String pattern) generally works with a null Locale argument, as the > lookup(Locale locale) method checks whether the argument is null and uses the > default locale in that case. > However, if debug logging is enabled for LocaleConvertUtils, the method > throws NullPointerException on null locale because the debug message does > locale.toString(). > The same thing happens with the convert(String values[], Class clazz, Locale > locale, String pattern) method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-409) StringUtils.isText to check in a null safe way if a String has (real) text
[ https://issues.apache.org/jira/browse/LANG-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568247#action_12568247 ] Niall Pemberton commented on LANG-409: -- Validator has GenericValidator.minLength(String, int) - but it doesn't do the "ignoring whitespace" bit: http://tinyurl.com/2ne6qk > StringUtils.isText to check in a null safe way if a String has (real) text > -- > > Key: LANG-409 > URL: https://issues.apache.org/jira/browse/LANG-409 > Project: Commons Lang > Issue Type: Improvement >Reporter: Jörg Gottschling >Priority: Minor > > I used something similar from the Spring Framework and it was useful. I > suggest two methods where the second is a little more advanced then theirs. > First a method StringUtils.isText(String text) : boolean which checks if the > String is not null and contains a least one not whitespace character. (In > Spring it's "hasText", but "isText" seams to be more consistent within > commons lang.) > The second method could be StringUtils.isText(String text, int n) : boolean > which checks if the String is not null and contains a least n not whitespace > characters. > Question: What happens if a (stupid ;-) developer checks for -5 characters? I > think it should throw an IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-305) PropertyUtilsBean.isWritable() returns false when the property is mapped and there is a mapped write method available
[
https://issues.apache.org/jira/browse/BEANUTILS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-305.
---
Resolution: Duplicate
Fix Version/s: 1.8.0-BETA
> PropertyUtilsBean.isWritable() returns false when the property is mapped and
> there is a mapped write method available
> --
>
> Key: BEANUTILS-305
> URL: https://issues.apache.org/jira/browse/BEANUTILS-305
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.7.0
> Environment: jdk 1.4.2
>Reporter: Stuart Brown
> Fix For: 1.8.0-BETA
>
>
> PropertyUtilsBean.isWritable returns false when there is a mapped property
> write method. It does not do this on indexed properties, I am not sure why
> mapped properties would be handled differently, but I do not believe they
> should be. Also this means there is no method in the class to test for
> writable mapped properties.
> Also PropertyUtilsBean.isReadable has the same issue and the fix is similar.
> Following code should work :
> 1185Method writeMethod = desc.getWriteMethod();
> 1186if ((writeMethod == null) &&
> 1187(desc instanceof IndexedPropertyDescriptor)) {
> 1188writeMethod = ((IndexedPropertyDescriptor)
> desc).getIndexedWriteMethod();
> 1189}
> + if (( writeMethod==null) &&
> + (desc instanceof MappedPropertyDescriptor)) {
> + writeMethod =
> ((MappedPropertyDescriptor)desc).getMappedWriteMethod();
> +}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-119) Convenience "Builder" for creating complex FileFilter conditions
[
https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567596#action_12567596
]
Niall Pemberton commented on IO-119:
@Gary - I agree with your general principles about clarity and writing and
maintaining code, but IMO you can have both - terse code thats clearer.
Personally I dislike IDE code formatting, it always seems to screw up and make
things less readable - which IMO is a bigger hinderance to maintaining the code
long term.
Anyway, this is an alternative option for people who do prefer it - those that
don't can use the FileFilterUtils or the implementations directly.
> Convenience "Builder" for creating complex FileFilter conditions
>
>
> Key: IO-119
> URL: https://issues.apache.org/jira/browse/IO-119
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 1.3.1
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
> Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java
>
>
> I'd like to add a new convenience "builder" class (FileFilterBuilder) to make
> it easier to create complex FileFilter using Commons IO's IOFileFilter
> implementations.
> Heres an example of how it can be used to create a IOFileFilter for the
> following conditions:
> - Either, directories which are not hidden and not named ".svn"
> - or, files which have a suffix of ".java"
> IOFileFilter filter = FileFilterBuilder.orBuilder()
> .and().isDirectory().isHidden(false).not().name(".svn").end()
> .and().isFile().suffix(".java").end()
> .getFileFilter();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-119) Convenience "Builder" for creating complex FileFilter conditions
[
https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567488#action_12567488
]
Niall Pemberton commented on IO-119:
Mine is reduce typing, makes it very easy with auto-complete - just keep
hitting period and one or two letters to add another condition.
> Convenience "Builder" for creating complex FileFilter conditions
>
>
> Key: IO-119
> URL: https://issues.apache.org/jira/browse/IO-119
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 1.3.1
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
> Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java
>
>
> I'd like to add a new convenience "builder" class (FileFilterBuilder) to make
> it easier to create complex FileFilter using Commons IO's IOFileFilter
> implementations.
> Heres an example of how it can be used to create a IOFileFilter for the
> following conditions:
> - Either, directories which are not hidden and not named ".svn"
> - or, files which have a suffix of ".java"
> IOFileFilter filter = FileFilterBuilder.orBuilder()
> .and().isDirectory().isHidden(false).not().name(".svn").end()
> .and().isFile().suffix(".java").end()
> .getFileFilter();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567485#action_12567485 ] Niall Pemberton commented on MATH-180: -- I don't think so, I re-built math yesteray and checked that nothing had changed OSGi wise (and none of the commits since affect it) - so looks good to go from my PoV > Add support for OSGi to Commons Math > > > Key: MATH-180 > URL: https://issues.apache.org/jira/browse/MATH-180 > Project: Commons Math > Issue Type: Task >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 1.2 > > > I saw mentioned that Commons Math 1.2 is on the horizon and it would be good > to add support for OSGi. Is the release likely to be done using Maven1 or > Maven2? I can provide a patch for either, but if its m2 then will probably > hold off until nearer the release to see if we get anything done in the > commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (IO-119) Convenience "Builder" for creating complex FileFilter conditions
[
https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567257#action_12567257
]
niallp edited comment on IO-119 at 2/8/08 5:05 PM:
Isn't that what we already have in FileFilterUtils?
http://commons.apache.org/io/api-release/org/apache/commons/io/filefilter/FileFilterUtils.html
New version attached - I don't think theres an intuitive way to do and/or
together - so I've simplified by removing that, add singleton instances for
AND/OR, added regex and provided better size / lastmodified methods.
So for example, to create a file filter for the following conditions
- Either, directories which are not hidden and not named ".svn"
- or, files which have a suffix of ".java"
{code}
FileFilterBuilder directoryBuilder = FileFilterBuilder.AND
.isDirectory()
.isNotHidden()
.not().name(".svn");
FileFilterBuilder fileBuilder = FileFilterBuilder.AND
.isFile()
.suffix(".java");
FileFilter filter = FileFilterBuilder.OR
.add(directoryBuilder)
.add(fileBuilder)
.toFileFilter();
{code}
was (Author: niallp):
Isn't that what we already have in FileFilterUtils?
http://commons.apache.org/io/api-release/org/apache/commons/io/filefilter/FileFilterUtils.html
New version attached - I don't think theres an intuitive way to do and/or
together - so I've simplified by removing that, add singleton instances for
AND/OR, added regex and provided better size / lastmodified methods.
So for example, to create a file filter for the following conditions
- Either, directories which are not hidden and not named ".svn"
- or, files which have a suffix of ".java"
FileFilterBuilder directoryBuilder = FileFilterBuilder.AND
.isDirectory()
.isHidden(false)
.not().name(".svn");
FileFilterBuilder fileBuilder = FileFilterBuilder.AND
.isFile()
.suffix(".java");
FileFilter filter = FileFilterBuilder.OR
.add(directoryBuilder)
.add(fileBuilder)
.toFileFilter();
> Convenience "Builder" for creating complex FileFilter conditions
>
>
> Key: IO-119
> URL: https://issues.apache.org/jira/browse/IO-119
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 1.3.1
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
> Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java
>
>
> I'd like to add a new convenience "builder" class (FileFilterBuilder) to make
> it easier to create complex FileFilter using Commons IO's IOFileFilter
> implementations.
> Heres an example of how it can be used to create a IOFileFilter for the
> following conditions:
> - Either, directories which are not hidden and not named ".svn"
> - or, files which have a suffix of ".java"
> IOFileFilter filter = FileFilterBuilder.orBuilder()
> .and().isDirectory().isHidden(false).not().name(".svn").end()
> .and().isFile().suffix(".java").end()
> .getFileFilter();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-119) Convenience "Builder" for creating complex FileFilter conditions
[
https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated IO-119:
---
Attachment: (was: FileFilterBuilderTestCase.java)
> Convenience "Builder" for creating complex FileFilter conditions
>
>
> Key: IO-119
> URL: https://issues.apache.org/jira/browse/IO-119
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 1.3.1
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
> Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java
>
>
> I'd like to add a new convenience "builder" class (FileFilterBuilder) to make
> it easier to create complex FileFilter using Commons IO's IOFileFilter
> implementations.
> Heres an example of how it can be used to create a IOFileFilter for the
> following conditions:
> - Either, directories which are not hidden and not named ".svn"
> - or, files which have a suffix of ".java"
> IOFileFilter filter = FileFilterBuilder.orBuilder()
> .and().isDirectory().isHidden(false).not().name(".svn").end()
> .and().isFile().suffix(".java").end()
> .getFileFilter();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-119) Convenience "Builder" for creating complex FileFilter conditions
[
https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated IO-119:
---
Attachment: (was: FileFilterBuilder.java)
> Convenience "Builder" for creating complex FileFilter conditions
>
>
> Key: IO-119
> URL: https://issues.apache.org/jira/browse/IO-119
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 1.3.1
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
> Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java
>
>
> I'd like to add a new convenience "builder" class (FileFilterBuilder) to make
> it easier to create complex FileFilter using Commons IO's IOFileFilter
> implementations.
> Heres an example of how it can be used to create a IOFileFilter for the
> following conditions:
> - Either, directories which are not hidden and not named ".svn"
> - or, files which have a suffix of ".java"
> IOFileFilter filter = FileFilterBuilder.orBuilder()
> .and().isDirectory().isHidden(false).not().name(".svn").end()
> .and().isFile().suffix(".java").end()
> .getFileFilter();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-119) Convenience "Builder" for creating complex FileFilter conditions
[
https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated IO-119:
---
Attachment: FileFilterBuilderTestCase.java
FileFilterBuilder.java
Isn't that what we already have in FileFilterUtils?
http://commons.apache.org/io/api-release/org/apache/commons/io/filefilter/FileFilterUtils.html
New version attached - I don't think theres an intuitive way to do and/or
together - so I've simplified by removing that, add singleton instances for
AND/OR, added regex and provided better size / lastmodified methods.
So for example, to create a file filter for the following conditions
- Either, directories which are not hidden and not named ".svn"
- or, files which have a suffix of ".java"
FileFilterBuilder directoryBuilder = FileFilterBuilder.AND
.isDirectory()
.isHidden(false)
.not().name(".svn");
FileFilterBuilder fileBuilder = FileFilterBuilder.AND
.isFile()
.suffix(".java");
FileFilter filter = FileFilterBuilder.OR
.add(directoryBuilder)
.add(fileBuilder)
.toFileFilter();
> Convenience "Builder" for creating complex FileFilter conditions
>
>
> Key: IO-119
> URL: https://issues.apache.org/jira/browse/IO-119
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 1.3.1
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
> Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java
>
>
> I'd like to add a new convenience "builder" class (FileFilterBuilder) to make
> it easier to create complex FileFilter using Commons IO's IOFileFilter
> implementations.
> Heres an example of how it can be used to create a IOFileFilter for the
> following conditions:
> - Either, directories which are not hidden and not named ".svn"
> - or, files which have a suffix of ".java"
> IOFileFilter filter = FileFilterBuilder.orBuilder()
> .and().isDirectory().isHidden(false).not().name(".svn").end()
> .and().isFile().suffix(".java").end()
> .getFileFilter();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-142) Retrieve Directory File List in Timestamp Order
[ https://issues.apache.org/jira/browse/IO-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-142: --- Attachment: IO-142-listfiles-v1.patch Atttaching a patch which includes 4 new methods in FileUtils: - public static Iterable listFiles(File, FileFilter, Comparator) - public static Iterable listFiles(String, FileFilter, Comparator) - public static Iterable listFilesRecursive(File, FileFilter, Comparator) - public static Iterable listFilesRecursive(String, FileFilter, Comparator) These provide the option to filter an sort the files from either a single directory or recursviely thru the directory structure. Using these with IO's packages of Filters and Comparators implementations, would be pretty powerful: http://commons.apache.org/io/api-release/org/apache/commons/io/filefilter/package-summary.html http://commons.apache.org/io/api-release/org/apache/commons/io/comparator/package-summary.html Needs test cases > Retrieve Directory File List in Timestamp Order > --- > > Key: IO-142 > URL: https://issues.apache.org/jira/browse/IO-142 > Project: Commons IO > Issue Type: New Feature > Components: Utilities > Environment: Java SE 5 - Windows, Linux >Reporter: Al Scherer > Attachments: IO-142-listfiles-v1.patch > > > I searched your current Commons-IO issues/feature requests and did not find > the following so I'd like to propose it as a feature request. > Given a filename filter and dir name, the method would return a List of > the files that match the filter in last-modified timestamp order. > Sun explicitly does not provide this functionality - from the Sun Java SE 5 > API Javadocs, File's listFiles() method descriptions include the following > disclaimer: > "There is no guarantee that the name strings in the resulting array > will appear in any specific order; they are not, in particular, guaranteed to > appear in alphabetical order." > I needed the files in last-modified order so I wrote code to do it and would > be glad to share the code with the commons project if you feel it would be > useful. > The signature is: > - public List getFileListInTimestampOrder(FilenameFilter filter, String > dirName) > I've already written, tested and used code to do this. > There are additional flavors that might be worthwhile, too. > - public List getFileListInTimestampOrderReversed(FilenameFilter > filter, String dirName) > - public List getFileListInNameOrder(FilenameFilter filter, String > dirName) > - public List getFileListInNameOrderReversed(FilenameFilter filter, > String dirName) > BTW, I originally posted this on commons-lang but was given feedback that it > might be a better fit here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
[
https://issues.apache.org/jira/browse/IO-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved IO-89.
---
Resolution: Won't Fix
> Inconsistency in SizeFileFilter and AgeFileFilter implementations
> -
>
> Key: IO-89
> URL: https://issues.apache.org/jira/browse/IO-89
> Project: Commons IO
> Issue Type: Bug
> Components: Filters
>Affects Versions: 1.2
>Reporter: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
>
> Theres an inconsistency (bug?) in the implementation of SizeFileFilter and
> AgeFileFilter.
> In SizeFileFilter, using an "acceptLarger" parameter of true actually accepts
> files with a size equal to and larger, whereas
> specifying an "acceptLarger" parameter of false only accepts smaller files.
> The same is true for AgeFileFilter, using an "acceptOlder" parameter of true
> actually accepts files either the same age or older, whereas
> specifying an "acceptOlder" parameter of false only accepts newer files.
> A big benefit of resolving these inconsistencies would mean that creating
> filters for any condition (i.e. <, >, <=, >= or =) becomes
> alot easier. For example if the AgeFileFilter did only do either newer or
> older, then creating a filters for "the same age or older"
> or "the same age or younger" could be done in the following way:
> IOFileFilter equalOlder = new NotFileFilter(new AgeFileFilter(cutoff,
> false));
> IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff,
> true));
> For SizeFileFilter I propose changing the logic to the following:
> if (acceptLarger) {
> return file.length() >= size;
> } else {
> return file.length() <= size;
> }
> (This would mean that "new SizeFileFilter(cutoff)" would operate the same way)
> I have added isOlderFile() methods to FileUtils and propose that
> AgeFileFilter is changed to the following:
> if (acceptOlder) {
> return FileUtils.isFileOlder(file, cutoff);
> } else {
> return FileUtils.isFileNewer(file, cutoff);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-154) Throw IllegalArgumentException when parameters are null (and explicitly checked)
[ https://issues.apache.org/jira/browse/IO-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-154. Resolution: Won't Fix Don't think there was any interest in doing this > Throw IllegalArgumentException when parameters are null (and explicitly > checked) > > > Key: IO-154 > URL: https://issues.apache.org/jira/browse/IO-154 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 2.x > > > IO is currently inconsistent with it explicitly throwing either a > NullPointerException or IllegalArgumentException when a methods arguments are > null - see discussion on IO-77. Review and change IO to only explcitly throw > IllegalArgumentException in this scenario. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-140) IO 2.0 - Move to JDK 1.5
[ https://issues.apache.org/jira/browse/IO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-140: --- Fix Version/s: (was: 2.x) 2.0 Summary: IO 2.0 - Move to JDK 1.5 (was: IO 2.0 - remove deprecations and move to JDK 1.5) OK I've applied all the JDK 1.5 changes, except I added the "CharSequence" flavour methods to IOUtils and FileUtils, rather than changing the signature of the existing methods: - Use generics: http://svn.apache.org/viewvc?view=rev&revision=619103 - Use StringBuilder (non-sync) in place of StringBuffer : http://svn.apache.org/viewvc?view=rev&revision=619112 - Add new JDK 1.5 Read/Writer methods: http://svn.apache.org/viewvc?view=rev&revision=619135 - Add CharSequence flavour methods to IOUtils / FileUtils: http://svn.apache.org/viewvc?view=rev&revision=619188 - Replace StringWriter with StringBuilderWriter in IOUtils: http://svn.apache.org/viewvc?view=rev&revision=619195 So far AFAIK none of these are incompatible changes - clirr is only showing an issue with the LineIterator next() method returning a String rather than Object - but I think this is a false positive? Stephen mentioned a couple of other points (Collections to Iterable, and removing arrays) here: http://commons.markmail.org/message/xcplvzf3p4odbckx > IO 2.0 - Move to JDK 1.5 > > > Key: IO-140 > URL: https://issues.apache.org/jira/browse/IO-140 > Project: Commons IO > Issue Type: Wish >Reporter: Niall Pemberton > Fix For: 2.0 > > Attachments: IO-2.0-deprecate-and-jdk5.patch > > > I just created IO-139 for a StringBuilder Writer implementation that requies > JDK 1.5. So I thought I would look at the impact on IO of 1) Removing all > deprecations and 2) Making appropriate JDK 1.5 changes (generics, using > StringBuilder and new Appendable for Writers). Below is a summary, thought it > could be a starting point for discussion about IO 2.0 > 1) DEPRECATIONS > - CopyUtils > - FileCleaner > - WildcardFilter > - FileSystemUtils freeSpace(String) > - IOUtils toByteArray(String), toString(byte[]), toString(byte[], String) > 2) JDK 1.5 > - ConditionalFileFilter List (and also AndFileFilter and OrFileFilter > implementations > - getFileFilters() and setFileFilters() use generic List > - Constructor for NameFileFilter, PrefixFileFilter, SuffixFileFilter, > WildcardFileFilter use generic List > - replace StringBuffer with StringBuilder where appropriate > (FilenameUtils, FileSystemUtils, HexDump,IOUtils > - FileUtils > - convertFileCollectionToFileArray() --> Collection > - listFiles() --> Collection > - listFiles() --> Collection > - writeStringToFile String-->CharSequence (JDK 1.4+) > - ProxyReader - add read(CharBuffer) > - IOUtils > - readLines(Reader) return List > - toInputStream(String) --> toInputStream(CharSequence) (JDK 1.4+) > - write(String data, OutputStream) and write(StringBuffer data, > OutputStream) --> write(CharSequence data, OutputStream) > - write(String, Writer) and write(StringBuffer, Writer) --> > write(CharSequence data, Writer) > - LineIterator Iterator --> Iterator - NullWriter - add "Appendable" methods > - ProxyWriter - add "Appendable" methods -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-155) use NIO for copyFile when running on java 1.4
[ https://issues.apache.org/jira/browse/IO-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-155. Resolution: Fixed Fix Version/s: (was: 2.x) 2.0 Assignee: Niall Pemberton Fixed thanks http://svn.apache.org/viewvc?view=rev&revision=619156 > use NIO for copyFile when running on java 1.4 > - > > Key: IO-155 > URL: https://issues.apache.org/jira/browse/IO-155 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.4 >Reporter: nicolas de loof >Assignee: Niall Pemberton >Priority: Trivial > Fix For: 2.0 > > Attachments: IO-155.patch > > > CopyFile can rely on java.nio when runtime is java 1.4 + -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-139) StringBuilder Writer implementation
[ https://issues.apache.org/jira/browse/IO-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-139. Resolution: Fixed Fix Version/s: (was: 2.x) 2.0 Fixed: http://svn.apache.org/viewvc?view=rev&revision=619141 > StringBuilder Writer implementation > --- > > Key: IO-139 > URL: https://issues.apache.org/jira/browse/IO-139 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 2.0 > > Attachments: StringBuilderWriter.java, StringBuilderWriterTest.java > > > This implementation, as an alternative to java.io.StringWriter, provides an > un-synchronized (i.e. for use in a single thread) implementation for better > performance. StringBuilder is a JDK 1.5+ feature -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565458#action_12565458 ] Niall Pemberton commented on LANG-362: -- Yes that would greatly simplify things - how does that sit though with something thats completely compatible with MessageFormat? Works for me, but I thought you wanted a drop in replacement? > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, > FormatFactory.java > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-302) NPE in ArrayConverter when converting a non-quoted string with underscores to a string array
[ https://issues.apache.org/jira/browse/BEANUTILS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-302. --- Resolution: Fixed Fix Version/s: (was: 1.8.0-BETA) 1.8.0 Assignee: Niall Pemberton Thanks for reporting this, now fixed: http://svn.apache.org/viewvc?view=rev&revision=618207 > NPE in ArrayConverter when converting a non-quoted string with underscores to > a string array > > > Key: BEANUTILS-302 > URL: https://issues.apache.org/jira/browse/BEANUTILS-302 > Project: Commons BeanUtils > Issue Type: Bug > Components: ConvertUtils & Converters >Affects Versions: 1.8.0-BETA > Environment: All >Reporter: Martin Bartlett >Assignee: Niall Pemberton > Fix For: 1.8.0 > > > An array value passed as: > this_is_my_first_value,this_is_my_second_value > causes an NPE after the first token is returned: > java.lang.NullPointerException > at > org.apache.commons.beanutils.converters.ArrayConverter.parseElements(ArrayConverter.java:440) > at > org.apache.commons.beanutils.converters.ArrayConverter.convertToCollection(ArrayConverter.java:343) > at > org.apache.commons.beanutils.converters.ArrayConverter.convertToType(ArrayConverter.java:279) > at > org.apache.commons.beanutils.converters.AbstractConverter.convert(AbstractConverter.java:171) > at > org.apache.commons.beanutils.converters.ConverterFacade.convert(ConverterFacade.java:60) > at > org.apache.commons.beanutils.BeanUtilsBean.convert(BeanUtilsBean.java:1079) > at > org.apache.commons.beanutils.BeanUtilsBean.copyProperty(BeanUtilsBean.java:437) > at > org.apache.commons.beanutils.BeanUtilsBean.copyProperties(BeanUtilsBean.java:270) > at > org.apache.commons.beanutils.BeanUtils.copyProperties(BeanUtils.java:137) > The parse list being built contains "this". The sval field of the > StreamTokenizer is indeed null - presumably because it has found the the > underscore. > Workaround is to quote the string. See BEANUTILS-301 for an improvement > request to allow _ as part of the default word character set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-301) In ArrayConverter, the allowedChars array should (possibly) include the underscore character
[
https://issues.apache.org/jira/browse/BEANUTILS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565288#action_12565288
]
Niall Pemberton commented on BEANUTILS-301:
---
You can configure the allowed characters to recognize the underscore:
ArrayConverter converter = new ArrayConverter(String[].class, new
StringConverter());
converter.setAllowedChars(new char[] {'.', '-', '_'});
then register your configured converter:
ConvertUtils.register(converter, String[].class);
> In ArrayConverter, the allowedChars array should (possibly) include the
> underscore character
>
>
> Key: BEANUTILS-301
> URL: https://issues.apache.org/jira/browse/BEANUTILS-301
> Project: Commons BeanUtils
> Issue Type: Improvement
> Components: ConvertUtils & Converters
>Affects Versions: 1.8.0-BETA
> Environment: All
>Reporter: Martin Bartlett
>Priority: Minor
>
> An array value passed as:
> this_is_my_first_value,this_is_my_second_value
> should (could: please) result in a two-element array - currently the "_" is
> not recognized as a word character and thus results in the StreamTokenizer
> splitting each string at the underscore. Maybe ALL Java symbol characters
> should be recognized? This would avoid unnecessary quoting ala
> "this_is_my_first_value","this_is_my_second_value"
> (note there is also a BUG related to this, since parsing the above string
> also results in an NPE in the current BETA- report to follow)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-406) Add FractionFormat to oacl.text
[ https://issues.apache.org/jira/browse/LANG-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565266#action_12565266 ] niallp edited comment on LANG-406 at 2/3/08 8:47 PM: -- I'm not sure why we have Fraction in both Lang and Math - I guess historically they just evolved separately. The duplication does seem like a waste of effort though and Math IMO is a better location - also Math already has a FractionFormat implementation. Perhaps would be a good idea to compare both Fraction implementations and ensure that one supports all features of the other and then deprecate one. http://svn.apache.org/repos/asf/commons/proper/math/trunk/src/java/org/apache/commons/math/fraction/ http://svn.apache.org/repos/asf/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/ was (Author: niallp): I'm not sure why we have Fraction in both Lang and Math - I guess historically they just evolved separately. The duplication does seem like a waste of effort though and Math IMO is a better location - also Math already has a FractionFormat implementation. Perhaps would be a good idea to compare both Fraction implementations and ensure that one supports all features of the other and then deprecate one. > Add FractionFormat to oacl.text > --- > > Key: LANG-406 > URL: https://issues.apache.org/jira/browse/LANG-406 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: FractionFormat.java, FractionFormatTest.java, > FractionToString.patch.txt > > > I'd like to add a FractionFormat implementation, capable of formatting > Numbers including oacl.math.Fraction to fractions, and of parsing fraction > representation (and standalone integers) into oacl.math.Fraction instances. > Implementation and test forthcoming; opinions welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-406) Add FractionFormat to oacl.text
[ https://issues.apache.org/jira/browse/LANG-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565266#action_12565266 ] Niall Pemberton commented on LANG-406: -- I'm not sure why we have Fraction in both Lang and Math - I guess historically they just evolved separately. The duplication does seem like a waste of effort though and Math IMO is a better location - also Math already has a FractionFormat implementation. Perhaps would be a good idea to compare both Fraction implementations and ensure that one supports all features of the other and then deprecate one. > Add FractionFormat to oacl.text > --- > > Key: LANG-406 > URL: https://issues.apache.org/jira/browse/LANG-406 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: FractionFormat.java, FractionFormatTest.java, > FractionToString.patch.txt > > > I'd like to add a FractionFormat implementation, capable of formatting > Numbers including oacl.math.Fraction to fractions, and of parsing fraction > representation (and standalone integers) into oacl.math.Fraction instances. > Implementation and test forthcoming; opinions welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-366) add MultiFormat
[ https://issues.apache.org/jira/browse/LANG-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565264#action_12565264 ] Niall Pemberton commented on LANG-366: -- Something I missed earlier was the fact that MultiFormat is being used as a core part of EMF - I saw it originally as just another format implementation for users. Since date and number are the most commonly used, then the fact that it doesn't work is still an issue. Even if my proposal is dismissed (I actually think that having something that works that doesn't fully adhere strictly to the API is preferable than the reverse) then providing a broken implementation is not a good idea. I agree we need to see the outcome of EMF - but if this remains in its current state and still required by EMF then perhaps it shouldn't be part of the public API > add MultiFormat > --- > > Key: LANG-366 > URL: https://issues.apache.org/jira/browse/LANG-366 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson > Fix For: 2.4 > > Attachments: multiFormat.patch.txt, MultiFormat2.java > > > this started as a part of LANG-362. That PR depends on this one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[
https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565260#action_12565260
]
niallp edited comment on LANG-362 at 2/3/08 8:31 PM:
--
You're right it hadn't hit my radar about toPattern() reconstructing the
pattern from internal state and so my suggestion reflects only half the
equation, i.e. pattern-to-Format and not Format-to-pattern.
The first thought I have about this is that one option would be to only support
toPattern() for 1) existing MessageFormat compatiblity (i.e. the four
"standard" built in formats) and 2) those configured through the pattern (i.e.
not "non-standard" formats configured using the setFormat() methods). I believe
this would be fairly straight forward to do and since EMF is providing a
mechanism for using any format thru' the pattern then the use of setFormat()
methods becomes unnecessary.
Having said that even if full toPattern() support is an absolute must I still
think the use of "meta formats" and the current implementation over-complicates
things and my thinking goes along the following lines:
- Using a meta "Format" implementation for the pattern<-->Format conversion is
confusing in itself. I think this is where my Factory suggestion has merit
since the idea of registering a "format factory" and then EMF looking-up a
registered factory to create a Format is much more straight forward concept for
users to grasp.
- The current implementation does this kind of "look-up" (using
NameKeyMetaFormat) but in an overcomplicated way - by creating an aggregated
MultiFormat which tries to parse using delegated NameKeyMetaFormat which in
turn delegates again if the format itself has arguments. Since the
FormatElement part of message format's pattern is always {index, FormatType,
args} then why have every meta-format repeatedly parse that info trying to
match - my suggestion involved EMF extracting out the FormatType, looking up a
registered factory for it and if found the factory then just parsing the
arguments component. Surely this is simpler and less error prone than having to
repeat the whole parsing of the FormatElement in every meta format?
- If I didn't convice you with my earlier reasoning about whether full
toPattern() support is really required then I think this can also be supported
using the factory concept. It would reguire the "registry" to be more than a
simple Map (i.e. be able to lookup a factory based on a Format, as well as
name) and the FormatFactory would need additional method(s) to support
re-creating the pattern - but I think that is doable as well.
Anyway I'm not wedded to my proposal (I generally try not to just throw out
criticism since IMO what counts at the ASF is not talking, but doing) and have
no problem it being dismissed - but I'm not convinced that what is there
currently should be included in an official release. I think the concept is
great, but supporting the code and users for this I think will be a headache
that we regret down the line.
was (Author: niallp):
You're right it hadn't hit my radar about toPattern() reconstructing the
pattern from internal state and so my suggestion reflects only half the
equation, i.e. pattern-->Format and not Format-->pattern.
The first thought I have about this is that one option would be to only support
toPattern() for 1) existing MessageFormat compatiblity (i.e. the four
"standard" built in formats) and 2) those configured through the pattern (i.e.
not "non-standard" formats configured using the setFormat() methods). I believe
this would be fairly straight forward to do and since EMF is providing a
mechanism for using any format thru' the pattern then the use of setFormat()
methods becomes unnecessary.
Having said that even if full toPattern() support is an absolute must I still
think the use of "meta formats" and the current implementation over-complicates
things and my thinking goes along the following lines:
- Using a meta "Format" implementation for the pattern<-->Format conversion is
confusing in itself. I think this is where my Factory suggestion has merit
since the idea of registering a "format factory" and then EMF looking-up a
registered factory to create a Format is much more straight forward concept for
users to grasp.
- The current implementation does this kind of "look-up" (using
NameKeyMetaFormat) but in an overcomplicated way - by creating an aggregated
MultiFormat which tries to parse using delegated NameKeyMetaFormat which in
turn delegates again if the format itself has arguments. Since the
FormatElement part of message format's pattern is always {index, FormatType,
args} then why have every meta-format repeatedly parse that info trying to
match - my suggestion involved EMF extracting out the FormatType, looking up a
registered factory for it and if found the factor
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[
https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565260#action_12565260
]
Niall Pemberton commented on LANG-362:
--
You're right it hadn't hit my radar about toPattern() reconstructing the
pattern from internal state and so my suggestion reflects only half the
equation, i.e. pattern-->Format and not Format-->pattern.
The first thought I have about this is that one option would be to only support
toPattern() for 1) existing MessageFormat compatiblity (i.e. the four
"standard" built in formats) and 2) those configured through the pattern (i.e.
not "non-standard" formats configured using the setFormat() methods). I believe
this would be fairly straight forward to do and since EMF is providing a
mechanism for using any format thru' the pattern then the use of setFormat()
methods becomes unnecessary.
Having said that even if full toPattern() support is an absolute must I still
think the use of "meta formats" and the current implementation over-complicates
things and my thinking goes along the following lines:
- Using a meta "Format" implementation for the pattern<-->Format conversion is
confusing in itself. I think this is where my Factory suggestion has merit
since the idea of registering a "format factory" and then EMF looking-up a
registered factory to create a Format is much more straight forward concept for
users to grasp.
- The current implementation does this kind of "look-up" (using
NameKeyMetaFormat) but in an overcomplicated way - by creating an aggregated
MultiFormat which tries to parse using delegated NameKeyMetaFormat which in
turn delegates again if the format itself has arguments. Since the
FormatElement part of message format's pattern is always {index, FormatType,
args} then why have every meta-format repeatedly parse that info trying to
match - my suggestion involved EMF extracting out the FormatType, looking up a
registered factory for it and if found the factory then just parsing the
arguments component. Surely this is simpler and less error prone than having to
repeat the whole parsing of the FormatElement in every meta format?
- If I didn't convice you with my earlier reasoning about whether full
toPattern() support is really required then I think this can also be supported
using the factory concept. It would reguire the "registry" to be more than a
simple Map (i.e. be able to lookup a factory based on a Format, as well as
name) and the FormatFactory would need additional method(s) to support
re-creating the pattern - but I think that is doable as well.
Anyway I'm not wedded to my proposal (I generally try not to just throw out
criticism since IMO what counts at the ASF is not talking, but doing) and have
no problem it being dismissed - but I'm not convinced that what is there
currently should be included in an official release. I think the concept is
great, but supporting the code and users for this I think will be a headache
that we regret down the line.
> Add ExtendedMessageFormat to org.apache.commons.lang.text
> -
>
> Key: LANG-362
> URL: https://issues.apache.org/jira/browse/LANG-362
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Matt Benson
>Assignee: Matt Benson
>Priority: Minor
> Fix For: 2.4
>
> Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt,
> extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java,
> FormatFactory.java
>
>
> Discussed on dev@ (
> http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL
> PROTECTED] ); adding here for tracking purposes and in case anyone has any
> serious objections to my implementation. Patch forthcoming...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564821#action_12564821 ] Niall Pemberton commented on MATH-180: -- I have configured the m2 build to add OSGi to the jar's manifest: http://svn.apache.org/viewvc?view=rev&revision=617551 A few notes on this: - I did it manually adding manifest entries thru' the jar plugin configuration rather than the Felix bundleplugin. This was because the released bundleplugin adds alot of "uses" statements which when the next version of the bnd tool is available (Bnd 0.0.236) will not happen. - I did run the bundleplugin to check what it produced and used that as a basis to configure the manifest entires - Commons Logging is listed as a dependency, but only used thru' Commons Discovery. The bundleplugin didn't include it in the "import" statement, so I haven't either - Once we have a released commons parent with the bundleplugin configured we can remove the config I've added here for math > Add support for OSGi to Commons Math > > > Key: MATH-180 > URL: https://issues.apache.org/jira/browse/MATH-180 > Project: Commons Math > Issue Type: Task >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 1.2 > > > I saw mentioned that Commons Math 1.2 is on the horizon and it would be good > to add support for OSGi. Is the release likely to be done using Maven1 or > Maven2? I can provide a patch for either, but if its m2 then will probably > hold off until nearer the release to see if we get anything done in the > commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564536#action_12564536 ] Niall Pemberton commented on MATH-181: -- I have no idea - it was in the original constructor and my math is rubbish compare to you guys. > Specify the maximum of digits when parsing a Fraction > - > > Key: MATH-181 > URL: https://issues.apache.org/jira/browse/MATH-181 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Attachments: MATH-181-FractionDigitsLimit-v2.patch, > MATH-181-FractionDigitsLimit.patch, MATH-181-FractionMaxDenominator.patch > > > Firstly, thanks for the Fraction code - I've adapated it for something I'm > working on and I didn't have a clue how to convert a decimal to a fraction :) > Excel spreadsheets have the facility to specify a fraction format where you > specify the maximum number of denominator digits to display. > So for example: > format "?/?" displays decimal values formatted in the range 1/2 to n/9 > format "??/??" displays decimal values formatted in the range 1/2 to n/99 > format "???/???" displays decimal values formatted in the range 1/2 to > n/999 etc > In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively > for the above 3 formats. > I'm attaching a patch for the Fraction class which adds a new constructor > where the maximum number of digits can be specified, rather than the epsilon > value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-23) commons-parent-8 pom changes (OSGi)
[ https://issues.apache.org/jira/browse/COMMONSSITE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-23: --- Attachment: (was: COMMONSSITE-23-commons-parent-v1.patch) > commons-parent-8 pom changes (OSGi) > --- > > Key: COMMONSSITE-23 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-23 > Project: Commons All > Issue Type: New Feature > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-23-commons-components-v1.patch, > COMMONSSITE-23-commons-parent-v2.patch > > > Opening this to discuss changes for the next commons-parent release. > The felix project has released the OSGi bundle plugin (version 1.2.0) and > specifying that in commons-parent makes it easy for components to be "OSGi > enabled" with little effort. Documentation about the plugin is here: > http://felix.apache.org/site/maven-bundle-plugin-bnd.html > Also, notes for Commons OSGi are here: > http://wiki.apache.org/commons/CommonsOsgi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-23) commons-parent-8 pom changes (OSGi)
[ https://issues.apache.org/jira/browse/COMMONSSITE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-23: --- Attachment: COMMONSSITE-23-commons-parent-v2.patch Attaching a new commons-parent patch - Net had "examples" packages and Launcher had "default" package classes - I changed the export instruction From "*" (i.e. export all packages to "org.apache.commons.*" - so we only export commons scoped packages. This was from feedback from Martin Oberhuber on the dev list - http://commons.markmail.org/message/zblr2p2yn4dujum4 > commons-parent-8 pom changes (OSGi) > --- > > Key: COMMONSSITE-23 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-23 > Project: Commons All > Issue Type: New Feature > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-23-commons-components-v1.patch, > COMMONSSITE-23-commons-parent-v1.patch, COMMONSSITE-23-commons-parent-v2.patch > > > Opening this to discuss changes for the next commons-parent release. > The felix project has released the OSGi bundle plugin (version 1.2.0) and > specifying that in commons-parent makes it easy for components to be "OSGi > enabled" with little effort. Documentation about the plugin is here: > http://felix.apache.org/site/maven-bundle-plugin-bnd.html > Also, notes for Commons OSGi are here: > http://wiki.apache.org/commons/CommonsOsgi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564293#action_12564293 ] Niall Pemberton commented on LANG-362: -- P.S. This is pretty much all your code with in ExtendedMessageFormat2 with a bit of simplification and couple of additions > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, > FormatFactory.java > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[
https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-362:
-
Attachment: DateFormatFactory.java
FormatFactory.java
ExtendedMessageFormat2.java
OK I'm attaching the following implementations
- ExtendedMessageFormat2
- FormatFactory
- DateFormatFactory
The DateFormatFactory is an example FormatFactory implementation that supports
the existing "date" and "time" format types, but also adds a new "datetime"
type. (btw its written as it is so that it can be used to implement Lang's
FastDateFormat implementation - by just overriding the protected methods).
So to use the new "datetime" type, all thats required is the following:
Map registry = new HashMap();
registry.put("datetime", new DateFormatFactory());
String pattern = "Date: {0,date,short} Time: {0,time,medium} Date/Time:
{0,datetime,long}";
ExtendedMessageFormat2 fmt = new ExtendedMessageFormat2(pattern,
registry);
System.out.println(fmt.format(new Object[] {new Date()}));
Note that the "date" and "time" types are not being handled by our custom
factory - the standard MessageFormat functionality is doing that. If we wanted
we could register custom formats for those standard types as well.
Maybe I'm missing something, but is this not achieving the same goal?
> Add ExtendedMessageFormat to org.apache.commons.lang.text
> -
>
> Key: LANG-362
> URL: https://issues.apache.org/jira/browse/LANG-362
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Matt Benson
>Assignee: Matt Benson
>Priority: Minor
> Fix For: 2.4
>
> Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt,
> extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java,
> FormatFactory.java
>
>
> Discussed on dev@ (
> http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL
> PROTECTED] ); adding here for tracking purposes and in case anyone has any
> serious objections to my implementation. Patch forthcoming...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564290#action_12564290 ] Niall Pemberton commented on LANG-362: -- OK I'll try and summarize the overall approach of your implementation: - ExtendedMessageFormat strips out all the "type" and "style" components from format elements leaving only the 'placeholding' argument indexes and applies that pattern to the MessageFormat it extends - ExtendedMessageFormat then parses the pattern again extracting the format element components and uses the "meta format" to parse each format elements type and style and create a Format for that element - These created formats are then set for the MessageFormat it extends. This is obviously a simplification, but in order to achieve the second step (i.e. creating the formats) it requires combing all the "meta format" implementations into a MultiFormat to generate all the format types currently supported by MessageFormat, plus any custom format types. So we have meta format implementations for date, time and number - plus a "factory" for these standard types. On top of that we have NameKeyedMetaFormat for anyone wanting to implement a custom format type and a couple of abstract support classes. - MetaFormatSupport - MultiFormat - ExtendedMessageFormat - NameKeyedMetaFormat - DefaultMetaFormatFactory - DateMetaFormat - DateMetaFormatSupport - NumberMetaFormat - TimeMetaFormat Working out how this all hung together took me some time and I think it will be difficult for users to grasp, difficult to support (I tried looking at the test cases to see how it worked, but its not quick to see from them either - you have to scan thru' quite a bit of code to find a real example of what you want to do). IMO this can be a whole lot simpler - both in terms of code quantity and complexity and in terms of concepts for users to grasp: I believe we only need two types to support this functionality: - an ExtendedMessageFormat implementation - a (v. simple) FormatFactory interface The FormatFactory interface has a single method as follows: Format getFormat(String name, String arguments, Locale locale); It works something like this: - create a "registry" (i.e. java.util.Map) of additional format type factories (additional to what MessageFormat already supports). - create an ExtendedMessageFormat instance with the "registry" - parse the pattern and for any format element types that have a factory registered, remove the "type" and "style" components from the pattern and pass them to the factory to create the format. - apply the modified pattern and set the formats for any created I have hacked your ExtendedMessageFormat implementation to do this and will attach it here. Its not properly tested and doesn't handle sub-formats ATM, but I believe it proves the concept and will attach in a minute > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened LANG-362: -- I started looking at the extended message format - I like the concept but first impression is the implementation is over complex and difficult to work out what its doing. I will try to find some time to document in detail what I thinks wrong with it - but at this point I would vote -1 on a release of Lang that included it. > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-366) add MultiFormat
[ https://issues.apache.org/jira/browse/LANG-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-366: - Attachment: MultiFormat2.java Attaching an alternative implementation that resolves the issues I raised. Its not properly tested - but it works with the current MutliFormat test without the GuardedFormat and whichever way round the formats are specified. Also clone is implemented. > add MultiFormat > --- > > Key: LANG-366 > URL: https://issues.apache.org/jira/browse/LANG-366 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson > Fix For: 2.4 > > Attachments: multiFormat.patch.txt, MultiFormat2.java > > > this started as a part of LANG-362. That PR depends on this one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (LANG-366) add MultiFormat
[ https://issues.apache.org/jira/browse/LANG-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened LANG-366: -- I've had a look at the new MultiFormat and IMO it needs work before its ready to be in a release (and I would probably vote -1 on a release if included in its current state). The biggest issue IMO is that currently it doesn't always work: - Formatting: a special "GuardedFormat" had to be created in MultiFormatTest to get the "testFormatNumber" to pass because the date format can handle numbers. Looks to me like MultiFormat needs the logic in "GuardedFormat" otherwise users are going to hit exactly that problem. - Parsing: in certains situations, implementations such as DecimalFormat and SimpleDateFormat stop when they hit an invalid character and don't indicate an error. For example if I parse "1/1/1970" with an integer format, it doesn't cause an error and returns a number of value "1". So in the MultiFormatTest "testParseDate" only works when the date format is before the number format - reverse the order and the test fails. The solution IMO is to check that all of the parsed input String has been "consumed". Other points are: - the tests for error conditions should be improved - Format implements Cloneable and therefore this implementation should implement the clone method and create a copy of the delegate array and clone each Format in it. > add MultiFormat > --- > > Key: LANG-366 > URL: https://issues.apache.org/jira/browse/LANG-366 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson > Fix For: 2.4 > > Attachments: multiFormat.patch.txt > > > this started as a part of LANG-362. That PR depends on this one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-23) commons-parent-8 pom changes (OSGi)
[ https://issues.apache.org/jira/browse/COMMONSSITE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-23: --- Attachment: COMMONSSITE-23-commons-components-v1.patch COMMONSSITE-23-commons-parent-v1.patch COMMONSSITE-23-commons-parent-v1.patch shows proposed changes to commons-parent (requires a property to be set in the component pom) COMMONSSITE-23-commons-components-v1.patch shows component pom changes I have run "mvn package" for all the components (except attributes, jelly and logging) with the above patches - generated jar files and manifests are here: http://people.apache.org/~niallp/commons-osgi/ Couple of Notes: - Chain and FileUpload have custom configurations for dynamic import of javax.portlet - Collections and BeanUtils produce more than 1 jar - do we need to do anything about the others? - CLI bundle symbolic name is "org.apache.commons.cli2" (seemed appropriate) - Launcher has one class with no package - causes "." in the import - Net has "examples" packages - do we want to exclude these? For the components - do we have any with packages that shouldn't be "exposed" - these can be labelled private if required. > commons-parent-8 pom changes (OSGi) > --- > > Key: COMMONSSITE-23 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-23 > Project: Commons All > Issue Type: New Feature > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-23-commons-components-v1.patch, > COMMONSSITE-23-commons-parent-v1.patch > > > Opening this to discuss changes for the next commons-parent release. > The felix project has released the OSGi bundle plugin (version 1.2.0) and > specifying that in commons-parent makes it easy for components to be "OSGi > enabled" with little effort. Documentation about the plugin is here: > http://felix.apache.org/site/maven-bundle-plugin-bnd.html > Also, notes for Commons OSGi are here: > http://wiki.apache.org/commons/CommonsOsgi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COMMONSSITE-23) commons-parent-8 pom changes (OSGi)
commons-parent-8 pom changes (OSGi) --- Key: COMMONSSITE-23 URL: https://issues.apache.org/jira/browse/COMMONSSITE-23 Project: Commons All Issue Type: New Feature Components: Commons Parent Pom Reporter: Niall Pemberton Opening this to discuss changes for the next commons-parent release. The felix project has released the OSGi bundle plugin (version 1.2.0) and specifying that in commons-parent makes it easy for components to be "OSGi enabled" with little effort. Documentation about the plugin is here: http://felix.apache.org/site/maven-bundle-plugin-bnd.html Also, notes for Commons OSGi are here: http://wiki.apache.org/commons/CommonsOsgi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated MATH-181: - Attachment: MATH-181-FractionMaxDenominator.patch Thanks Luc - when I submitted this I was only thinking of my own simple use-case but perhaps its better (and allows finer grained control) to just be able to specify the maximum denominator value in the constructor - it avoids the overflow issue altogether. Attaching a patch, although it meets my needs as it is. > Specify the maximum of digits when parsing a Fraction > - > > Key: MATH-181 > URL: https://issues.apache.org/jira/browse/MATH-181 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Attachments: MATH-181-FractionDigitsLimit-v2.patch, > MATH-181-FractionDigitsLimit.patch, MATH-181-FractionMaxDenominator.patch > > > Firstly, thanks for the Fraction code - I've adapated it for something I'm > working on and I didn't have a clue how to convert a decimal to a fraction :) > Excel spreadsheets have the facility to specify a fraction format where you > specify the maximum number of denominator digits to display. > So for example: > format "?/?" displays decimal values formatted in the range 1/2 to n/9 > format "??/??" displays decimal values formatted in the range 1/2 to n/99 > format "???/???" displays decimal values formatted in the range 1/2 to > n/999 etc > In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively > for the above 3 formats. > I'm attaching a patch for the Fraction class which adds a new constructor > where the maximum number of digits can be specified, rather than the epsilon > value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated MATH-181: - Attachment: MATH-181-FractionDigitsLimit-v2.patch version 2 patch attached with (hopefully) improved JavaDocs > Specify the maximum of digits when parsing a Fraction > - > > Key: MATH-181 > URL: https://issues.apache.org/jira/browse/MATH-181 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Attachments: MATH-181-FractionDigitsLimit-v2.patch, > MATH-181-FractionDigitsLimit.patch > > > Firstly, thanks for the Fraction code - I've adapated it for something I'm > working on and I didn't have a clue how to convert a decimal to a fraction :) > Excel spreadsheets have the facility to specify a fraction format where you > specify the maximum number of denominator digits to display. > So for example: > format "?/?" displays decimal values formatted in the range 1/2 to n/9 > format "??/??" displays decimal values formatted in the range 1/2 to n/99 > format "???/???" displays decimal values formatted in the range 1/2 to > n/999 etc > In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively > for the above 3 formats. > I'm attaching a patch for the Fraction class which adds a new constructor > where the maximum number of digits can be specified, rather than the epsilon > value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-404) Add Calendar flavour format methods to DateFormatUtils
[ https://issues.apache.org/jira/browse/LANG-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-404. -- Resolution: Fixed Fixed http://svn.apache.org/viewvc?view=rev&revision=615243 > Add Calendar flavour format methods to DateFormatUtils > -- > > Key: LANG-404 > URL: https://issues.apache.org/jira/browse/LANG-404 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 2.4 > > > Add Calendar flavour format methods to DateFormatUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-404) Add Calendar flavour format methods to DateFormatUtils
Add Calendar flavour format methods to DateFormatUtils -- Key: LANG-404 URL: https://issues.apache.org/jira/browse/LANG-404 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 2.4 Add Calendar flavour format methods to DateFormatUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562022#action_12562022 ] Niall Pemberton commented on MATH-180: -- OK, once the RM and tool (m1 or m2) is decided we can then sort out OSGi. Are there any packages of Commons Math that are consider "for internal use" and not really for end-users? I ask because you can specify for those parts in OSGi and AIUI these are then not available to other bundles which import Math. > Add support for OSGi to Commons Math > > > Key: MATH-180 > URL: https://issues.apache.org/jira/browse/MATH-180 > Project: Commons Math > Issue Type: Task >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 1.2 > > > I saw mentioned that Commons Math 1.2 is on the horizon and it would be good > to add support for OSGi. Is the release likely to be done using Maven1 or > Maven2? I can provide a patch for either, but if its m2 then will probably > hold off until nearer the release to see if we get anything done in the > commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562019#action_12562019 ] Niall Pemberton commented on MATH-181: -- Yes, I mostly just copied the existing constructor and didn't put any effort - sorry :( Its an either or situation and not optimal (which is why I made it private) - but it means that with a couple of slight modifications the same code can be (re)used either with an epsilon or specified max. denominator digits. I can either submit another patch with improved JavaDoc or spearate out the two cases, duplicating the double-->fraction code. Which would you prefer? > Specify the maximum of digits when parsing a Fraction > - > > Key: MATH-181 > URL: https://issues.apache.org/jira/browse/MATH-181 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Attachments: MATH-181-FractionDigitsLimit.patch > > > Firstly, thanks for the Fraction code - I've adapated it for something I'm > working on and I didn't have a clue how to convert a decimal to a fraction :) > Excel spreadsheets have the facility to specify a fraction format where you > specify the maximum number of denominator digits to display. > So for example: > format "?/?" displays decimal values formatted in the range 1/2 to n/9 > format "??/??" displays decimal values formatted in the range 1/2 to n/99 > format "???/???" displays decimal values formatted in the range 1/2 to > n/999 etc > In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively > for the above 3 formats. > I'm attaching a patch for the Fraction class which adds a new constructor > where the maximum number of digits can be specified, rather than the epsilon > value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated MATH-181: - Attachment: MATH-181-FractionDigitsLimit.patch > Specify the maximum of digits when parsing a Fraction > - > > Key: MATH-181 > URL: https://issues.apache.org/jira/browse/MATH-181 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Attachments: MATH-181-FractionDigitsLimit.patch > > > Firstly, thanks for the Fraction code - I've adapated it for something I'm > working on and I didn't have a clue how to convert a decimal to a fraction :) > Excel spreadsheets have the facility to specify a fraction format where you > specify the maximum number of denominator digits to display. > So for example: > format "?/?" displays decimal values formatted in the range 1/2 to n/9 > format "??/??" displays decimal values formatted in the range 1/2 to n/99 > format "???/???" displays decimal values formatted in the range 1/2 to > n/999 etc > In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively > for the above 3 formats. > I'm attaching a patch for the Fraction class which adds a new constructor > where the maximum number of digits can be specified, rather than the epsilon > value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-181) Specify the maximum of digits when parsing a Fraction
Specify the maximum of digits when parsing a Fraction - Key: MATH-181 URL: https://issues.apache.org/jira/browse/MATH-181 Project: Commons Math Issue Type: Improvement Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Attachments: MATH-181-FractionDigitsLimit.patch Firstly, thanks for the Fraction code - I've adapated it for something I'm working on and I didn't have a clue how to convert a decimal to a fraction :) Excel spreadsheets have the facility to specify a fraction format where you specify the maximum number of denominator digits to display. So for example: format "?/?" displays decimal values formatted in the range 1/2 to n/9 format "??/??" displays decimal values formatted in the range 1/2 to n/99 format "???/???" displays decimal values formatted in the range 1/2 to n/999 etc In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively for the above 3 formats. I'm attaching a patch for the Fraction class which adds a new constructor where the maximum number of digits can be specified, rather than the epsilon value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561482#action_12561482 ] Niall Pemberton commented on MATH-180: -- P.S. See http://wiki.apache.org/commons/CommonsOsgi > Add support for OSGi to Commons Math > > > Key: MATH-180 > URL: https://issues.apache.org/jira/browse/MATH-180 > Project: Commons Math > Issue Type: Task >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 1.2 > > > I saw mentioned that Commons Math 1.2 is on the horizon and it would be good > to add support for OSGi. Is the release likely to be done using Maven1 or > Maven2? I can provide a patch for either, but if its m2 then will probably > hold off until nearer the release to see if we get anything done in the > commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-180) Add support for OSGi to Commons Math
Add support for OSGi to Commons Math Key: MATH-180 URL: https://issues.apache.org/jira/browse/MATH-180 Project: Commons Math Issue Type: Task Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Fix For: 1.2 I saw mentioned that Commons Math 1.2 is on the horizon and it would be good to add support for OSGi. Is the release likely to be done using Maven1 or Maven2? I can provide a patch for either, but if its m2 then will probably hold off until nearer the release to see if we get anything done in the commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-179) Fraction tests for double Constructor
[ https://issues.apache.org/jira/browse/MATH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561452#action_12561452 ] Niall Pemberton commented on MATH-179: -- Sorry ignore the m2 comment, must have been a one-off glitch - re-running works fine > Fraction tests for double Constructor > - > > Key: MATH-179 > URL: https://issues.apache.org/jira/browse/MATH-179 > Project: Commons Math > Issue Type: Test >Reporter: Niall Pemberton >Priority: Minor > Attachments: MATH-FractionConstructorDouble.patch > > > I was looking at borrowing some code from Fraction and the constructor that > takes a double doesn't seem to have much tests. Attaching a patch - if I've > missed something or these tests are a waste of time or its covered well > elsewhere then please ignore this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-179) Fraction tests for double Constructor
[ https://issues.apache.org/jira/browse/MATH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated MATH-179: - Attachment: MATH-FractionConstructorDouble.patch P.S. The m2 build seems to be broken btw (m1 works fine) I'll try to see why > Fraction tests for double Constructor > - > > Key: MATH-179 > URL: https://issues.apache.org/jira/browse/MATH-179 > Project: Commons Math > Issue Type: Test >Reporter: Niall Pemberton >Priority: Minor > Attachments: MATH-FractionConstructorDouble.patch > > > I was looking at borrowing some code from Fraction and the constructor that > takes a double doesn't seem to have much tests. Attaching a patch - if I've > missed something or these tests are a waste of time or its covered well > elsewhere then please ignore this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-179) Fraction tests for double Constructor
Fraction tests for double Constructor - Key: MATH-179 URL: https://issues.apache.org/jira/browse/MATH-179 Project: Commons Math Issue Type: Test Reporter: Niall Pemberton Priority: Minor I was looking at borrowing some code from Fraction and the constructor that takes a double doesn't seem to have much tests. Attaching a patch - if I've missed something or these tests are a waste of time or its covered well elsewhere then please ignore this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-240) Broken link for 'Naming' project in docs
[ https://issues.apache.org/jira/browse/DBCP-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560274#action_12560274 ] Niall Pemberton commented on DBCP-240: -- Its still there in directory's site structure, but something is preventing it being seen. And in svn its in their "dormant-subprojects" area: http://svn.apache.org/viewvc/directory/sandbox/dormant-subprojects/ > Broken link for 'Naming' project in docs > > > Key: DBCP-240 > URL: https://issues.apache.org/jira/browse/DBCP-240 > Project: Commons Dbcp > Issue Type: Bug >Reporter: Luis Parravicini >Priority: Minor > > The page at http://commons.apache.org/dbcp/guide/jndi-howto.html talks about > Naming, with a link to > http://directory.apache.org/subprojects/naming/index.html which gives a 404. > Moreover, I couldn't find the Naming subproject from Apache Directory, it > seems it doesn't exist anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-22) Maven2 Plugin to generate custom component pages
[ https://issues.apache.org/jira/browse/COMMONSSITE-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559917#action_12559917 ] Niall Pemberton commented on COMMONSSITE-22: Generated Download Page Notes: - Some binary distros use the -bin prefix for binary distros, others don't - Commons BeanUtils and Collections currently have two release versions listed - Daemon only has tar.gz files - Latka lists a single zip file - Email also lists javadoc and sources jars - Launcher has examples distros - Proxy has a download page, but isn't yet released > Maven2 Plugin to generate custom component pages > > > Key: COMMONSSITE-22 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-22 > Project: Commons All > Issue Type: Improvement > Components: Commons Build >Reporter: Niall Pemberton >Assignee: Niall Pemberton > > I've been playing with a Maven2 Ant plugin which is a possible solution for > generating the component's download pages - currently handled by m1. As an > addition it also does custom "Issue Tracking" pages, of the style most m1 > sites use (and better than the current m2 generated one). > The advantage of this plugin is that it creates the page in the component's > site - which is better IMO than having a page in "commons general" outside > the component's site. I'm going to add this to the sandbox shortly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-402) OSGi-ify Lang
[ https://issues.apache.org/jira/browse/LANG-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-402: - Attachment: LANG-402-OSGi-jar-maniest.patch At the moment the Felix project's maven2 bundle plugin has not been released - so attaching a patch to configure the m2 build through the jar plugin. If Lang 2.4 is going to use m1, I can supply a patch for that too. See also http://wiki.apache.org/commons/CommonsOsgi > OSGi-ify Lang > - > > Key: LANG-402 > URL: https://issues.apache.org/jira/browse/LANG-402 > Project: Commons Lang > Issue Type: Task >Reporter: Henri Yandell >Assignee: Niall Pemberton > Fix For: 2.4 > > Attachments: LANG-402-OSGi-jar-maniest.patch > > > Pre-release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COMMONSSITE-22) Maven2 Plugin to generate custom component pages
Maven2 Plugin to generate custom component pages Key: COMMONSSITE-22 URL: https://issues.apache.org/jira/browse/COMMONSSITE-22 Project: Commons All Issue Type: Improvement Components: Commons Build Reporter: Niall Pemberton Assignee: Niall Pemberton I've been playing with a Maven2 Ant plugin which is a possible solution for generating the component's download pages - currently handled by m1. As an addition it also does custom "Issue Tracking" pages, of the style most m1 sites use (and better than the current m2 generated one). The advantage of this plugin is that it creates the page in the component's site - which is better IMO than having a page in "commons general" outside the component's site. I'm going to add this to the sandbox shortly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-192) Split camel case strings
[ https://issues.apache.org/jira/browse/LANG-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-192: - Summary: Split camel case strings (was: [lang] split camel case strings) > Split camel case strings > > > Key: LANG-192 > URL: https://issues.apache.org/jira/browse/LANG-192 > Project: Commons Lang > Issue Type: Improvement > Environment: Operating System: All > Platform: All >Reporter: Anthony Perritano >Priority: Minor > Fix For: 2.4 > > Attachments: StringUtils.patch, StringUtilsTest.patch > > > Have the ability to split up any entered camel cased string. > example: > entering stepListFirst would return step List First. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-257) Add new splitByWholeSeparatorPreserveAllTokens() methods to StringUtils
[ https://issues.apache.org/jira/browse/LANG-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-257: - Summary: Add new splitByWholeSeparatorPreserveAllTokens() methods to StringUtils (was: [Patch] - added new methods to StringUtil) > Add new splitByWholeSeparatorPreserveAllTokens() methods to StringUtils > --- > > Key: LANG-257 > URL: https://issues.apache.org/jira/browse/LANG-257 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Cameron Whitehead >Priority: Minor > Fix For: 2.4 > > Attachments: LANG-257.patch, StringUtils-enhancements.patch > > > I added two methods I found helpful. > public static String[] splitByWholeSeparatorPreserveAllTokens(String str, > String separator, int max) > public static String[] splitByWholeSeparatorPreserveAllTokens(String str, > String separator) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) Add convenience moveFile() / moveDirectory methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557666#action_12557666
]
Niall Pemberton commented on IO-77:
---
OK I reverted to NPE since only Henri voted since and other committers wanted
it that way:
http://svn.apache.org/viewvc?view=rev&revision=610810
> Add convenience moveFile() / moveDirectory methods to FileUtils
> ---
>
> Key: IO-77
> URL: https://issues.apache.org/jira/browse/IO-77
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.3.2
> Environment: Operating System: other
> Platform: Other
>Reporter: nicolas de loof
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 1.4
>
> Attachments: IO-77-nio.patch, IO-77.patch, patch_io.txt
>
>
> I'm using FileUtils as it partially solves the missing "move" method for File,
> that is so simple to do in unix shell.
> A full implementation in FileUtils may be great :
> static boolean FileUtils.move(File src, File dest)
> throws IOException
> {
> boolean rename = src.renameTo(dest);
> if (!rename)
> {
> copyFile(file, dest);
> file.delete();
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-155) use NIO for copyFile when running on java 1.4
[ https://issues.apache.org/jira/browse/IO-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-155: --- Fix Version/s: (was: 1.4) AFTER-1.4 IMO better to not have the JDK 1.4 hack and just put this into the next release. Also we have a small script to check that JDK 1.4 features haven't crept in (excluding the new implementations that require it) - if we put this in then we would have to exclude IOUtils and everything that depends on it - then theres no way for people reviewing the release to verify easily for themselves that we are still JDK 1.3 compliant for everything except the four new implementations. > use NIO for copyFile when running on java 1.4 > - > > Key: IO-155 > URL: https://issues.apache.org/jira/browse/IO-155 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.4 >Reporter: nicolas de loof >Priority: Trivial > Fix For: AFTER-1.4 > > Attachments: IO-155.patch > > > CopyFile can rely on java.nio when runtime is java 1.4 + -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) Add convenience moveFile() / moveDirectory methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557648#action_12557648
]
Niall Pemberton commented on IO-77:
---
Thanks Nicolas, can you open a new issue ticket for this please? Also this will
have to go into the next Commons IO release because, although we have added new
JKD 1.4 dependant implementations in Commons IO we are retaining compatibility
with JDK 1.3 (thru' the compiler source/target options) for existing classes
such as IOUtils.
Also your patch has *alot* of noise in it - as was the last one which took me a
while to remove all the un-related/formatting changes. Small focused patches
are much more likely to get applied since they take much less effort to review.
> Add convenience moveFile() / moveDirectory methods to FileUtils
> ---
>
> Key: IO-77
> URL: https://issues.apache.org/jira/browse/IO-77
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.3.2
> Environment: Operating System: other
> Platform: Other
>Reporter: nicolas de loof
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 1.4
>
> Attachments: IO-77-nio.patch, IO-77.patch, patch_io.txt
>
>
> I'm using FileUtils as it partially solves the missing "move" method for File,
> that is so simple to do in unix shell.
> A full implementation in FileUtils may be great :
> static boolean FileUtils.move(File src, File dest)
> throws IOException
> {
> boolean rename = src.renameTo(dest);
> if (!rename)
> {
> copyFile(file, dest);
> file.delete();
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) Add convenience moveFille() / moveDirectory methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557285#action_12557285
]
Niall Pemberton commented on IO-77:
---
@Henri
LineIterator was in the last release - also isFileNewer() / isFileOlder() in
FileUtils throw IllegalArgumentException so we have code in the vicinity doing
both. Also what do you think about changing them all to IAE in IO 2.0
(backward-incompatible JDK 1.5 version) as I propose in IO-154 - I think if
we're going to do that then we should create the minimum disruption and use IAE
here. IMO a -1 vote here should also be a -1 vote to IO-154.
> Add convenience moveFille() / moveDirectory methods to FileUtils
>
>
> Key: IO-77
> URL: https://issues.apache.org/jira/browse/IO-77
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.3.2
> Environment: Operating System: other
> Platform: Other
>Reporter: nicolas de loof
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 1.4
>
> Attachments: IO-77.patch, patch_io.txt
>
>
> I'm using FileUtils as it partially solves the missing "move" method for File,
> that is so simple to do in unix shell.
> A full implementation in FileUtils may be great :
> static boolean FileUtils.move(File src, File dest)
> throws IOException
> {
> boolean rename = src.renameTo(dest);
> if (!rename)
> {
> copyFile(file, dest);
> file.delete();
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-137) Added method for getting InputStream from ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation and copy
[ https://issues.apache.org/jira/browse/IO-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-137: --- Fix Version/s: (was: 1.4) AFTER-1.4 > Added method for getting InputStream from ByteArrayOutputStream & IOUtils > avoiding unnecessary array allocation and copy > > > Key: IO-137 > URL: https://issues.apache.org/jira/browse/IO-137 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers, Utilities >Affects Versions: 1.3.2 > Environment: Any OS with appropriate JVM >Reporter: Nikunj Trivedi > Fix For: AFTER-1.4 > > Attachments: baos_to_inputstream.patch, baos_toIstream.patch > > > Patch inclues following two methods and test cases for both. > 1) New Method: ByteArrayOutputStream.toInputStream > ByteArrayOutputStream exposes its byte buffers by toByteArray(), which > creates a fresh buffer and copy existing data to it. > A new method toInputStream() available in patch returns the current contents > of baos, as an InputStream, avoiding unnecessary allocation and copying. > 2) New Method: IOUtils.toFullyBufferedInputStream > There are situations where the InputStream source is available and it has to > be passed to different modules for processing. > It is needed to fetch the full contents of the InputStream in internal > buffer(IOUtils.toByteArray() ), convert this buffer to ByteArrayInputStream > and use that stream instead. But this is wasteful since toByteArray() > requires one fresh allocation and copy operation. > New method copies InputStream to ByteArrayOutputStream and returns > baos.toInputStream(), avoiding unnecessary memory allocation and copy. > Testcases are available in respective classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) Add convenience moveFille() / moveDirectory methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557184#action_12557184
]
Niall Pemberton commented on IO-77:
---
So where are we at with this, I'd like to put it to bed.
I don't want to take out the explict check/throw for nulls since its a PITA for
users to have to look up a line number to find out whats causing the exception.
Consistency is good, but seems that we don't have that - so I suggest we leave
it as it is (throwing IllegalArgumentException) and sort out the consistency in
IO 2.0 - I've created IO-154 to remember to do this.
If this isn't satisfactory then I suggest people vote on this here:
[ ] -1 I don't agree, revert to throwing NullpointerException
[ ] +1 leave it as it is throwing IllegalArgumentException
> Add convenience moveFille() / moveDirectory methods to FileUtils
>
>
> Key: IO-77
> URL: https://issues.apache.org/jira/browse/IO-77
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.3.2
> Environment: Operating System: other
> Platform: Other
>Reporter: nicolas de loof
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 1.4
>
> Attachments: IO-77.patch, patch_io.txt
>
>
> I'm using FileUtils as it partially solves the missing "move" method for File,
> that is so simple to do in unix shell.
> A full implementation in FileUtils may be great :
> static boolean FileUtils.move(File src, File dest)
> throws IOException
> {
> boolean rename = src.renameTo(dest);
> if (!rename)
> {
> copyFile(file, dest);
> file.delete();
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-154) Throw IllegalArgumentException when parameters are null (and explicitly checked)
Throw IllegalArgumentException when parameters are null (and explicitly checked) Key: IO-154 URL: https://issues.apache.org/jira/browse/IO-154 Project: Commons IO Issue Type: Improvement Affects Versions: 1.4 Reporter: Niall Pemberton Priority: Minor Fix For: AFTER-1.4 IO is currently inconsistent with it explicitly throwing either a NullPointerException or IllegalArgumentException when a methods arguments are null - see discussion on IO-77. Review and change IO to only explcitly throw IllegalArgumentException in this scenario. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-127) Move to a minimum of JDK 1.4
[ https://issues.apache.org/jira/browse/IO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-127. Resolution: Fixed Assignee: Niall Pemberton > Move to a minimum of JDK 1.4 > > > Key: IO-127 > URL: https://issues.apache.org/jira/browse/IO-127 > Project: Commons IO > Issue Type: Task >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > Attachments: commons-io-jdk-1_3-check.patch > > > There was a discussion a while back on moving Commons IO to a minimum JDK > version of 1.4 - see [1] below. The majority view was this was a good idea. > Jorg Schaible suggested[2] that the compiler options be kept at JDK 1.3 so > that, apart from new JDK 1.4 dependant features, Commons IO would still > operate under JDK 1.3. This seems like a good idea and resolves the issue of > whether this would require a major version change. > There was also a view that we should move to JDK 1.5 instead - I have no > issue with that, but would advocate that theres no point in doing so until > there are people wanting to commit JDK 1.5 dependant features. > This change is targeted at Commons IO 1.4 - and a Commons IO 1.3 branch has > been created for anyone still desiring future JDK 1.3 only releases. > [1] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL > PROTECTED] > [2] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-153. Resolution: Fixed Assignee: Stephen Colebourne > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Assignee: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: FileWriterWithEncoding.java, > io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-51) Throttled input and output stream classes
[ https://issues.apache.org/jira/browse/IO-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-51: -- Fix Version/s: (was: 1.4) AFTER-1.4 This was discussed recently in the following thread: http://commons.markmail.org/message/zooudrehscpblxul Needs review and (possibly) some work so moving to post 1.4 > Throttled input and output stream classes > - > > Key: IO-51 > URL: https://issues.apache.org/jira/browse/IO-51 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Affects Versions: 1.0 > Environment: Operating System: other > Platform: All >Reporter: Gareth Davis >Priority: Minor > Fix For: AFTER-1.4 > > Attachments: throttle-example.jar, throttle-source.jar, > throttle-source.jar > > > Additional classes for the commons-io package. > Three new classes, the new test classes and one example class. > io.Limiter - Core class shared between the input and output streams that > provides the central functions > for the throttle io streams > io.input.ThrottledInputStream - Input Stream implementation > io.output.ThrottledOutputStream - Output Stream implementation > Gareth -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-77) Add convenience moveFille() / moveDirectory methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated IO-77:
--
Fix Version/s: 1.4
Assignee: Niall Pemberton
> Add convenience moveFille() / moveDirectory methods to FileUtils
>
>
> Key: IO-77
> URL: https://issues.apache.org/jira/browse/IO-77
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.3.2
> Environment: Operating System: other
> Platform: Other
>Reporter: nicolas de loof
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 1.4
>
> Attachments: IO-77.patch, patch_io.txt
>
>
> I'm using FileUtils as it partially solves the missing "move" method for File,
> that is so simple to do in unix shell.
> A full implementation in FileUtils may be great :
> static boolean FileUtils.move(File src, File dest)
> throws IOException
> {
> boolean rename = src.renameTo(dest);
> if (!rename)
> {
> copyFile(file, dest);
> file.delete();
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-77) Add convenience moveFille() / moveDirectory methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated IO-77:
--
Fix Version/s: (was: 1.4)
Affects Version/s: (was: 1.0)
1.3.2
Summary: Add convenience moveFille() / moveDirectory methods to
FileUtils (was: [io] add a convenience FileUtils.move(File src, File dest))
> Add convenience moveFille() / moveDirectory methods to FileUtils
>
>
> Key: IO-77
> URL: https://issues.apache.org/jira/browse/IO-77
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.3.2
> Environment: Operating System: other
> Platform: Other
>Reporter: nicolas de loof
>Priority: Minor
> Attachments: IO-77.patch, patch_io.txt
>
>
> I'm using FileUtils as it partially solves the missing "move" method for File,
> that is so simple to do in unix shell.
> A full implementation in FileUtils may be great :
> static boolean FileUtils.move(File src, File dest)
> throws IOException
> {
> boolean rename = src.renameTo(dest);
> if (!rename)
> {
> copyFile(file, dest);
> file.delete();
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-149) Make FilenameUtils.EXTENSION_SEPARATOR public
[ https://issues.apache.org/jira/browse/IO-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-149. Resolution: Fixed Fixed http://svn.apache.org/viewvc?view=rev&revision=609870 > Make FilenameUtils.EXTENSION_SEPARATOR public > - > > Key: IO-149 > URL: https://issues.apache.org/jira/browse/IO-149 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 1.3.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 1.4 > > > We declare the same field as FilenameUtils.EXTENSION_SEPARATOR in our util > package. Does anyone see why this should not be made public? What about > adding a String version as well? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556818#action_12556818 ] Niall Pemberton commented on IO-153: OK I've applied your patch with the JDK 1.4 modifications (and non-encoding constructors removed): http://svn.apache.org/viewvc?view=rev&revision=609864 > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: FileWriterWithEncoding.java, > io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-21) commons-parent-6 pom changes
[ https://issues.apache.org/jira/browse/COMMONSSITE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556811#action_12556811 ] Niall Pemberton commented on COMMONSSITE-21: @Dennis - sorry for annoying you Dennis - I heres my opnions on your four points: - 1) I agree - 2) I agree - 3) I agree, but it also says ".txt" extensions are acceptable and the best solution IMO for Commons is an alternative bundle as I propose in MRRESOURCES-31[1] - 4) I disagree because I don't think any components should be using it until the issues with generation and what to do about the source/binary distros are resolved. So is there a way to include the generated NOTICE / LICENSE files in the source and binary distros? [1] http://jira.codehaus.org/browse/MRRESOURCES-31 > commons-parent-6 pom changes > > > Key: COMMONSSITE-21 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-21 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: commons-valdiator-generated-NOTICE.txt, > COMMONSSITE-21-commons-parent-pom-v1.patch, > COMMONSSITE-21-commons-parent-pom-v2.patch > > > Opening this ticket to discuss changes for Version 6 of the commons-parent > pom. > See thread: http://tinyurl.com/39eo9z for related discussion/issues -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-21) commons-parent-6 pom changes
[ https://issues.apache.org/jira/browse/COMMONSSITE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556810#action_12556810 ] Niall Pemberton commented on COMMONSSITE-21: I posted this issue ticket (probably in the wrong place) : http://jira.codehaus.org/browse/MRRESOURCES-31 > commons-parent-6 pom changes > > > Key: COMMONSSITE-21 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-21 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: commons-valdiator-generated-NOTICE.txt, > COMMONSSITE-21-commons-parent-pom-v1.patch, > COMMONSSITE-21-commons-parent-pom-v2.patch > > > Opening this ticket to discuss changes for Version 6 of the commons-parent > pom. > See thread: http://tinyurl.com/39eo9z for related discussion/issues -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) [io] add a convenience FileUtils.move(File src, File dest)
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556632#action_12556632
]
Niall Pemberton commented on IO-77:
---
I generally use IllegalArgumentException, but you're right, looking thru
FileUtils and IOUtiles the vast majority throw a NullPointerException - either
explicitly or otherwise. I'll leave this for the moment for further discussion
to see if anyone else chimes in - if not I'll revert
> [io] add a convenience FileUtils.move(File src, File dest)
> --
>
> Key: IO-77
> URL: https://issues.apache.org/jira/browse/IO-77
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.0
> Environment: Operating System: other
> Platform: Other
>Reporter: nicolas de loof
>Priority: Minor
> Fix For: 1.4
>
> Attachments: IO-77.patch, patch_io.txt
>
>
> I'm using FileUtils as it partially solves the missing "move" method for File,
> that is so simple to do in unix shell.
> A full implementation in FileUtils may be great :
> static boolean FileUtils.move(File src, File dest)
> throws IOException
> {
> boolean rename = src.renameTo(dest);
> if (!rename)
> {
> copyFile(file, dest);
> file.delete();
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) [io] add a convenience FileUtils.move(File src, File dest)
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556620#action_12556620
]
Niall Pemberton commented on IO-77:
---
Holger, Julien,
Thanks for the feedback - I've changed this as you suggest:
http://svn.apache.org/viewvc?view=rev&revision=609683
> [io] add a convenience FileUtils.move(File src, File dest)
> --
>
> Key: IO-77
> URL: https://issues.apache.org/jira/browse/IO-77
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.0
> Environment: Operating System: other
> Platform: Other
>Reporter: nicolas de loof
>Priority: Minor
> Fix For: 1.4
>
> Attachments: IO-77.patch, patch_io.txt
>
>
> I'm using FileUtils as it partially solves the missing "move" method for File,
> that is so simple to do in unix shell.
> A full implementation in FileUtils may be great :
> static boolean FileUtils.move(File src, File dest)
> throws IOException
> {
> boolean rename = src.renameTo(dest);
> if (!rename)
> {
> copyFile(file, dest);
> file.delete();
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) [io] add a convenience FileUtils.move(File src, File dest)
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556577#action_12556577
]
Niall Pemberton commented on IO-77:
---
Thanks for the new patch Nicolas - I've applied it with some modifications:
http://svn.apache.org/viewvc?view=rev&revision=609622
I renamed the "move" method to "moveFile" so that its consistent with the
existing copyFile/copyDirectory methods we have. I also added
"moveFileToDirectory", "moveDirectoryToDirectory" and "moveToDirectory" method
flavours with the same idea as their copy equivalents.
Theres are a few other minor changes (like throwing IOException instead of
IllegalArgumentException) . I'll leave this open for now for feedback
Niall
> [io] add a convenience FileUtils.move(File src, File dest)
> --
>
> Key: IO-77
> URL: https://issues.apache.org/jira/browse/IO-77
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.0
> Environment: Operating System: other
> Platform: Other
>Reporter: nicolas de loof
>Priority: Minor
> Fix For: 1.4
>
> Attachments: IO-77.patch, patch_io.txt
>
>
> I'm using FileUtils as it partially solves the missing "move" method for File,
> that is so simple to do in unix shell.
> A full implementation in FileUtils may be great :
> static boolean FileUtils.move(File src, File dest)
> throws IOException
> {
> boolean rename = src.renameTo(dest);
> if (!rename)
> {
> copyFile(file, dest);
> file.delete();
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556459#action_12556459 ] Niall Pemberton commented on IO-153: Your're right the dummy object isn't using it as designed so probably not a good idea and it doesn't change how it works anyway so not worth arguing over (sorry!). How about you commit what you have - if that includes the Charset etc. stuff great, if not I'll modify it after. > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: FileWriterWithEncoding.java, > io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-105) Add a FileUtils copyDirectory method that makes use of FileFilter
[ https://issues.apache.org/jira/browse/IO-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-105. Resolution: Fixed Fixed: http://svn.apache.org/viewvc?view=rev&revision=609471 > Add a FileUtils copyDirectory method that makes use of FileFilter > - > > Key: IO-105 > URL: https://issues.apache.org/jira/browse/IO-105 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Henri Yandell >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > Attachments: IO-105-FileUtils_copyDirectory_filtered.patch > > > For potential source, see: > https://svn.codehaus.org/plexus/plexus-utils/trunk/src/main/java/org/codehaus/plexus/util/FileUtils.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-105) Add a FileUtils copyDirectory method that makes use of FileFilter
[ https://issues.apache.org/jira/browse/IO-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-105: --- Assignee: Niall Pemberton Priority: Minor (was: Major) Summary: Add a FileUtils copyDirectory method that makes use of FileFilter (was: Add a FileUtils.copyDirectoryStructure method) > Add a FileUtils copyDirectory method that makes use of FileFilter > - > > Key: IO-105 > URL: https://issues.apache.org/jira/browse/IO-105 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Henri Yandell >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > Attachments: IO-105-FileUtils_copyDirectory_filtered.patch > > > For potential source, see: > https://svn.codehaus.org/plexus/plexus-utils/trunk/src/main/java/org/codehaus/plexus/util/FileUtils.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-148) IOException with constructors which take a cause
[ https://issues.apache.org/jira/browse/IO-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-148. Resolution: Fixed Assignee: Gary Gregory > IOException with constructors which take a cause > > > Key: IO-148 > URL: https://issues.apache.org/jira/browse/IO-148 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Gary Gregory >Priority: Minor > Fix For: 1.4 > > > Add an IOException implementation that has constructors which take a cause > (see TIKA-104). Constructors which take a cause (Throwable) were not added to > IOException until JDK 1.6 but the initCause() method was added to Throwable > in JDK 1.4. > We should copy the Tika implementation and test case here: > http://svn.apache.org/repos/asf/incubator/tika/trunk/src/main/java/org/apache/tika/exception/CauseIOException.java > http://svn.apache.org/repos/asf/incubator/tika/trunk/src/test/java/org/apache/tika/exception/CauseIOExceptionTest.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556438#action_12556438 ] Niall Pemberton commented on IO-153: On the JDK 1.3 compatibility the majority agreed with moving to JDK 1.4 for the IO 1.4 release (see IO-127) - however we haven't actually done that, but instead retained JDK 1.3 compatibility for all but three (and this would be a fourth) new implementations. I could understand it i it for this implementation if it was just the FileOutputStream constructor, which gains nothing from using it - but theres an opportunity to support the new Charset and CharsetEncoder features in this impl - so I think we should do that. I don't understand you saying that using ProxyWriter is more complex - doing so removes the need for the writer variable and the following seven methods: - write(int) - write(char[]) - write(char[], int, int) - write(String) - write(String, int, int) - flush() - close() ...and replaces that with a "dummy" object in the super constructor and initializing one additional variable (i.e. "lock") - how is that more complex? Another point is that JDK 1.5 introduces new append() methods in JDK 1.5 which I suggested we should add to ProxyWriter when we move to JDK 1,5 (see IO-140) - which with no effort this impl. would inherit - although maybe delegating to the proxy's append() methods compared to letting the default Writer append methods (which call write()) is a minor point. The main one is no duplicating code around. > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: FileWriterWithEncoding.java, > io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-152) Add ByteArrayOutputStream.readFrom(InputStream)
[ https://issues.apache.org/jira/browse/IO-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556429#action_12556429 ] Niall Pemberton commented on IO-152: I understand the logical symmetry, but it still seems wrong that what is essentially a "write" method method is named "read" rather than "write" and I do think it fits in eactly with all the other "write" methods. On the IOException point then we should make this clear in the javadocs > Add ByteArrayOutputStream.readFrom(InputStream) > --- > > Key: IO-152 > URL: https://issues.apache.org/jira/browse/IO-152 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: IO-152.patch > > > It would be useful to have a ByteArrayOutputStream.readFrom(InputStream) > method to mirror the existing writeTo(OutputStream) method. A call like > baos.readFrom(in) would be semantically the same as IOUtils.copy(in, baos), > but would avoid an extra in-memory copy of the stream contents, as it could > read bytes from the input stream directly into the internal > ByteArrayOutputStream buffers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-153: --- Attachment: FileWriterWithEncoding.java I have a few comments/questions: - I don't understand why encoding is optional and there are four constructors without an encoding parameter. To use the default encoding people could/should just use FileWriter directly rather than this impl - Why not use the FileOutputStream constructor which takes a File rather than passing file.getAbsolutePath() to its String constructor? - We could use ProxyWriter and pass a dummy lock/writer to the constructor and reset "lock" and "out" (protected) variables after calling super - This only deals with String characterset names - would be good to provide Charset and CharsetEncoder constructors as well. I realize these require JDK 1.4 - but we already have three JDK 1.4 dependant implementations in this release. Attaching a suggested alternative version with the above points. Currently only has "File" constructors - may want to add String file name constructors as well for convenience. > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: FileWriterWithEncoding.java, > io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-135) Add convenience deleteQuietly to FileUtils
[ https://issues.apache.org/jira/browse/IO-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-135. Resolution: Fixed Assignee: Niall Pemberton Fixed in http://svn.apache.org/viewvc?view=rev&revision=609253 > Add convenience deleteQuietly to FileUtils > -- > > Key: IO-135 > URL: https://issues.apache.org/jira/browse/IO-135 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Kevin Conaway >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > Attachments: IO-135-FileUtils_deleteQuietly.patch, io-135.patch > > > It is occasionally useful to delete a file or directory and not care whether > that call succeeds or not. I'm not quite sure what others do when deleting > a file or directory fails but most often the case is to simply log the event > and move on. > The attached patch includes a new method deleteQuietly() and supporting test > cases -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-135) Add convenience deleteQuietly to FileUtils
[ https://issues.apache.org/jira/browse/IO-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556321#action_12556321 ] Niall Pemberton commented on IO-135: Sorry didn't see your comment - think I was uploading my suggested patch at the time - I'd prefer returning the boolean. > Add convenience deleteQuietly to FileUtils > -- > > Key: IO-135 > URL: https://issues.apache.org/jira/browse/IO-135 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Kevin Conaway >Priority: Minor > Fix For: 1.4 > > Attachments: IO-135-FileUtils_deleteQuietly.patch, io-135.patch > > > It is occasionally useful to delete a file or directory and not care whether > that call succeeds or not. I'm not quite sure what others do when deleting > a file or directory fails but most often the case is to simply log the event > and move on. > The attached patch includes a new method deleteQuietly() and supporting test > cases -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-135) Add convenience deleteQuietly to FileUtils
[ https://issues.apache.org/jira/browse/IO-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-135: --- Attachment: IO-135-FileUtils_deleteQuietly.patch Attaching an alternative patch that handles nulls and returns a boolean if the file/directory is deleted > Add convenience deleteQuietly to FileUtils > -- > > Key: IO-135 > URL: https://issues.apache.org/jira/browse/IO-135 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Kevin Conaway >Priority: Minor > Fix For: 1.4 > > Attachments: IO-135-FileUtils_deleteQuietly.patch, io-135.patch > > > It is occasionally useful to delete a file or directory and not care whether > that call succeeds or not. I'm not quite sure what others do when deleting > a file or directory fails but most often the case is to simply log the event > and move on. > The attached patch includes a new method deleteQuietly() and supporting test > cases -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on FilenameUtils.equalsNormalizedOnSystem()
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-128: --- Fix Version/s: (was: 1.4) AFTER-1.4 Moving this to post 1.4 - needs someone to step up and do the work > NPE on FilenameUtils.equalsNormalizedOnSystem() > --- > > Key: IO-128 > URL: https://issues.apache.org/jira/browse/IO-128 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2 >Reporter: Antonio Gallardo >Assignee: Niall Pemberton > Fix For: AFTER-1.4 > > Attachments: IO-128-v2.patch > > > The following code in commons-io (1.3.2) throws an NPE exception: > org.apache.commons.io.FilenameUtils > .equalsNormalizedOnSystem( > "//a.html", > "//ab.html"); > And here is the exception: > java.lang.NullPointerException: The strings must not be null >at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141) >at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984) >at > org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956) >at CodeSnippet_32.run(CodeSnippet_32.java:4) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:585) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35) > I think it is wrong a message "The strings must not be null", since there is > not a null string involved in the call. > Interesting is if both or 1 of the strings is null, it did not throws an > exception. > Additional comment from Niall Pemberton (on the dev mail list): > The problem is that the FilenameUtils's normalize(String) method > returns "null" if it thinks the file names are invalid - which in your > case it seems to be doing so for both file names. > So I guess theres two issues here - you're right the error is > misleading and FilenameUtils should check the names again after > calling normalize() for nulls and throw a more appropriate message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (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:all-tabpanel
]
Niall Pemberton updated IO-109:
---
As theres been no response can we close this as fixed in 1.3?
> 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
> Fix For: 1.4
>
> 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.
[jira] Resolved: (IO-145) File Comparator implementations
[ https://issues.apache.org/jira/browse/IO-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-145. Resolution: Fixed > File Comparator implementations > --- > > Key: IO-145 > URL: https://issues.apache.org/jira/browse/IO-145 > Project: Commons IO > Issue Type: New Feature >Affects Versions: 1.3.2 >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > Attachments: DefaultFileComparator.java, > ExtensionFileComparator.java, LastModifiedFileComparator.java, > LengthFileComparator.java, NameFileComparator.java, PathFileComparator.java, > ReverseFileComparator.java > > > Add file comparator implementations - prompted by IO-142 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-79) [IO][PATCH] - file and directory pollers
[ https://issues.apache.org/jira/browse/IO-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-79: -- Fix Version/s: (was: 1.4) AFTER-1.4 > [IO][PATCH] - file and directory pollers > > > Key: IO-79 > URL: https://issues.apache.org/jira/browse/IO-79 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.1 > Environment: Operating System: other > Platform: Other >Reporter: Jim Harrington >Priority: Minor > Fix For: AFTER-1.4 > > Attachments: file_directory_poller.jar > > > Add classes that will monitor a file/directory and notify registered > observers > creation, deletion and content change events occur. Source is in the > attachement file_directory_poller.jar as they are all new files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
