[jira] [Commented] (LANG-1088) Fix FastDateParse to do case-blind time zone matching?

2015-03-23 Thread Charles Honton (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14377193#comment-14377193
 ] 

Charles Honton commented on LANG-1088:
--

Revisions 1589446, 1589508,  1590054, 1590059 make the FastDateParser case 
insensitive for TimeZone.  Revisions 1589446 and 1589508 incorrectly stated 
that they dealt with LANG-966. These commit messages were updated to say 
LANG-1088.

> Fix FastDateParse to do case-blind time zone matching?
> --
>
> Key: LANG-1088
> URL: https://issues.apache.org/jira/browse/LANG-1088
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Sebb
>Assignee: Charles Honton
> Fix For: 3.x
>
>
> It looks like SimpleDataFormat does not care what case is used for time zones.
> However, this does not appear to be documented.
> Should FastDateParser copy this behaviour?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (VALIDATOR-364) Email Validator does not support quoted/escaped character in the local part of the email address

2015-03-23 Thread teo bran (JIRA)
teo bran created VALIDATOR-364:
--

 Summary: Email Validator does not support quoted/escaped character 
in the local part of the email address
 Key: VALIDATOR-364
 URL: https://issues.apache.org/jira/browse/VALIDATOR-364
 Project: Commons Validator
  Issue Type: Bug
  Components: Routines
Affects Versions: 1.4.1 Release
Reporter: teo bran


Currently the email address validator doesn't support to quote (or escape) a 
character in the local part of the address.

Examples:
{noformat}
Abc\@d...@example.com
Fred\ blo...@example.com
Joe.\\b...@example.com
{noformat}

Source: [RFC 3696 | http://tools.ietf.org/html/rfc3696#section-3]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the "left" side string. This would have a method that accepts the "right" side string to test.

2015-03-23 Thread Bruno P. Kinoshita (JIRA)

[ 
https://issues.apache.org/jira/browse/SANDBOX-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375917#comment-14375917
 ] 

Bruno P. Kinoshita commented on SANDBOX-492:


Great! That will make review/merging the changes much easier. 

IIRC, I didn't merge your pull request because a new class had been introduced 
in the project (StringMetricFrom?) and I wanted to play with it before merging 
:-) Will try to review your PR within the next days. 

> Create StringDistanceFrom class that contains a StringMetric and the "left" 
> side string.  This would have a method that accepts the "right" side string 
> to test.
> 
>
> Key: SANDBOX-492
> URL: https://issues.apache.org/jira/browse/SANDBOX-492
> Project: Commons Sandbox
>  Issue Type: Improvement
>  Components: Commons Text
>Reporter: Jonathan Baker
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the "left" side string. This would have a method that accepts the "right" side string to test.

2015-03-23 Thread Jonathan Baker (JIRA)

[ 
https://issues.apache.org/jira/browse/SANDBOX-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375906#comment-14375906
 ] 

Jonathan Baker commented on SANDBOX-492:


Pulled in SANDBOX-491 and SANDBOX0493 into SANDBO-492 and finished unit tests.  
Please review.  Thank you.

> Create StringDistanceFrom class that contains a StringMetric and the "left" 
> side string.  This would have a method that accepts the "right" side string 
> to test.
> 
>
> Key: SANDBOX-492
> URL: https://issues.apache.org/jira/browse/SANDBOX-492
> Project: Commons Sandbox
>  Issue Type: Improvement
>  Components: Commons Text
>Reporter: Jonathan Baker
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the "left" side string. This would have a method that accepts the "right" side string to test.

2015-03-23 Thread Jonathan Baker (JIRA)

[ 
https://issues.apache.org/jira/browse/SANDBOX-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375906#comment-14375906
 ] 

Jonathan Baker edited comment on SANDBOX-492 at 3/23/15 1:56 PM:
-

Pulled in SANDBOX-491 and SANDBOX-493 into SANDBO-492 and finished unit tests.  
Please review.  Thank you.


was (Author: jbaker):
Pulled in SANDBOX-491 and SANDBOX0493 into SANDBO-492 and finished unit tests.  
Please review.  Thank you.

> Create StringDistanceFrom class that contains a StringMetric and the "left" 
> side string.  This would have a method that accepts the "right" side string 
> to test.
> 
>
> Key: SANDBOX-492
> URL: https://issues.apache.org/jira/browse/SANDBOX-492
> Project: Commons Sandbox
>  Issue Type: Improvement
>  Components: Commons Text
>Reporter: Jonathan Baker
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (SANDBOX-492) Create StringDistanceFrom class that contains a StringMetric and the "left" side string. This would have a method that accepts the "right" side string to test.

2015-03-23 Thread Jonathan Baker (JIRA)

[ 
https://issues.apache.org/jira/browse/SANDBOX-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375906#comment-14375906
 ] 

Jonathan Baker edited comment on SANDBOX-492 at 3/23/15 1:56 PM:
-

Pulled in SANDBOX-491 and SANDBOX-493 into SANDBOX-492 and finished unit tests. 
 Please review.  Thank you.


was (Author: jbaker):
Pulled in SANDBOX-491 and SANDBOX-493 into SANDBO-492 and finished unit tests.  
Please review.  Thank you.

> Create StringDistanceFrom class that contains a StringMetric and the "left" 
> side string.  This would have a method that accepts the "right" side string 
> to test.
> 
>
> Key: SANDBOX-492
> URL: https://issues.apache.org/jira/browse/SANDBOX-492
> Project: Commons Sandbox
>  Issue Type: Improvement
>  Components: Commons Text
>Reporter: Jonathan Baker
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CSV-93) Allow the handling of NULL values

2015-03-23 Thread Georg Tsakumagos (JIRA)

[ 
https://issues.apache.org/jira/browse/CSV-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375783#comment-14375783
 ] 

Georg Tsakumagos edited comment on CSV-93 at 3/23/15 1:04 PM:
--

The current state does not honor the specification. It is not possible to 
distinguish between an empty string and a null value. The applied solution is 
not usable in that case. I've reviewed the unittest and see that it does not 
test with an empty string. The generic strategy to map null values to a 
configurable string is very generic but leads to problems interpreting the data.

Thats why i choose the semantic way im my fist approach to use the quotes to 
signal an empty string. Replacing an null value with an string e.g. NULL leads 
to the problem where the text NULL is allowed data.


was (Author: geo):
The current state does not honor the specification. It is not possible to 
distinguish between an empty string and a null value. The applied solution is 
not usable in that case.

> Allow the handling of NULL values
> -
>
> Key: CSV-93
> URL: https://issues.apache.org/jira/browse/CSV-93
> Project: Commons CSV
>  Issue Type: Improvement
>  Components: Documentation, Parser, Printer
>Affects Versions: 1.0
>Reporter: Georg Tsakumagos
> Fix For: 1.0
>
> Attachments: CSV-93.diff, patch.txt
>
>
> h5. Requirement
> To use the CSV parser and printer for SQL Dumps it would be nice if they 
> could handle *null* values. 
> h5. Specification
> To distinguish between an *empty* or *null* value empty values always gets 
> quoted to denote an empty string. The absence of an quote denotes a *null* 
> value
> h5. Configuration
> To activate the behavior call the method _withNullObjectPatternEnabled_ of 
> the _CSVFormat_ with parameter _true_.
> h5. Modifications
> See attached patch.
> h5. Example
> This example using as base the _DEFAULT_ _CSVFormat_ modified by the 
> NullObjectPattern behavior.
> || Array-Data || CSV-Data ||
> | \{null,"","A"," "\}; |,"A",""," " |
> | \{"",null,"A"," "\} |"",,"A"," " |
> | \{"","A",null\} |"","A", |
> h5. NULL in DBMS proprietary CSV formats
> || Product || Strategy || Documentation / Link ||
> | PostgreSQL | If NULL should be preserved all non NULL values gets quoted | 
> [PostgreSQL 8.1 
> Manual|http://www.postgresql.org/docs/8.1/static/sql-copy.html] |
> | MySQL | NULL Values will be replaced by the letters NULL or escaped by \n | 
> not found, verified with MySQL Workbench | 
> | MS SQL | NULL values will be exported as empty strings (no quotes). Strings 
> will be quoted if needed. Import can interpret them as null | 
> [MSDN|http://msdn.microsoft.com/en-us//library/ms187887] | 
> | Oracle | NULL Values will be replaced by the letters NULL | 
> [Manual|http://docs.oracle.com/cd/B25329_01/doc/admin.102/b25107/impexp.htm] |



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Reopened] (CSV-93) Allow the handling of NULL values

2015-03-23 Thread Georg Tsakumagos (JIRA)

 [ 
https://issues.apache.org/jira/browse/CSV-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Georg Tsakumagos reopened CSV-93:
-

The current state does not honor the specification. It is not possible to 
distinguish between an empty string and a null value. The applied solution is 
not usable in that case.

> Allow the handling of NULL values
> -
>
> Key: CSV-93
> URL: https://issues.apache.org/jira/browse/CSV-93
> Project: Commons CSV
>  Issue Type: Improvement
>  Components: Documentation, Parser, Printer
>Affects Versions: 1.0
>Reporter: Georg Tsakumagos
> Fix For: 1.0
>
> Attachments: CSV-93.diff, patch.txt
>
>
> h5. Requirement
> To use the CSV parser and printer for SQL Dumps it would be nice if they 
> could handle *null* values. 
> h5. Specification
> To distinguish between an *empty* or *null* value empty values always gets 
> quoted to denote an empty string. The absence of an quote denotes a *null* 
> value
> h5. Configuration
> To activate the behavior call the method _withNullObjectPatternEnabled_ of 
> the _CSVFormat_ with parameter _true_.
> h5. Modifications
> See attached patch.
> h5. Example
> This example using as base the _DEFAULT_ _CSVFormat_ modified by the 
> NullObjectPattern behavior.
> || Array-Data || CSV-Data ||
> | \{null,"","A"," "\}; |,"A",""," " |
> | \{"",null,"A"," "\} |"",,"A"," " |
> | \{"","A",null\} |"","A", |
> h5. NULL in DBMS proprietary CSV formats
> || Product || Strategy || Documentation / Link ||
> | PostgreSQL | If NULL should be preserved all non NULL values gets quoted | 
> [PostgreSQL 8.1 
> Manual|http://www.postgresql.org/docs/8.1/static/sql-copy.html] |
> | MySQL | NULL Values will be replaced by the letters NULL or escaped by \n | 
> not found, verified with MySQL Workbench | 
> | MS SQL | NULL values will be exported as empty strings (no quotes). Strings 
> will be quoted if needed. Import can interpret them as null | 
> [MSDN|http://msdn.microsoft.com/en-us//library/ms187887] | 
> | Oracle | NULL Values will be replaced by the letters NULL | 
> [Manual|http://docs.oracle.com/cd/B25329_01/doc/admin.102/b25107/impexp.htm] |



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (LANG-1091) Shutdown thread pools in test cases

2015-03-23 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375669#comment-14375669
 ] 

ASF GitHub Bot commented on LANG-1091:
--

GitHub user CodingFabian opened a pull request:

https://github.com/apache/commons-lang/pull/58

LANG-1091 fixes shutdown of ExecutorPools used in Tests.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/CodingFabian/commons-lang LANG-1091

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/58.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #58


commit 0cd7fda27649a20d96359257506302d9a950e035
Author: Fabian Lange 
Date:   2015-03-23T10:15:41Z

LANG-1091 fixes shutdown of ExecutorPools used in Tests.




> Shutdown thread pools in test cases
> ---
>
> Key: LANG-1091
> URL: https://issues.apache.org/jira/browse/LANG-1091
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.builder.*, lang.concurrent.*
>Affects Versions: 3.3.2
> Environment: Linux, JDK 7
>Reporter: Jesper Öqvist
> Fix For: Patch Needed, 3.4
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The tests, in for example 
> org.apache.commons.lang3.builder.ToStringStyleConcurrencyTest, create thread 
> pools which are not shut down properly, leading to idle worker threads that 
> can prevent the JVM from shutting down properly.
> Suggested fix: shutdown() on the thread pool where a call to shutdown or 
> shutdownNow is missing.
> Affected classes (these were the ones I could find easily, I may have missed 
> some):
> * org.apache.commons.lang3.builder.ReflectionToStringStyleConcurrencyTest
> * org.apache.commons.lang3.builder.ToStringStyleConcurrencyTest
> * org.apache.commons.lang3.concurrent.CallableBackgroundInitializerTest



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (LANG-1025) Fix Java 8 related problem in site build

2015-03-23 Thread Fabian Lange (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375651#comment-14375651
 ] 

Fabian Lange commented on LANG-1025:


yes that is right:
{code}
Caused by: org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in 
constant pool: 18
at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146)
at org.apache.bcel.classfile.ConstantPool.(ConstantPool.java:67)
at 
org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222)
at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136)
at 
org.apache.bcel.util.ClassLoaderRepository.loadClass(ClassLoaderRepository.java:94)
at org.apache.bcel.classfile.JavaClass.getInterfaces(JavaClass.java:788)
at 
org.apache.bcel.classfile.JavaClass.getAllInterfaces(JavaClass.java:804)
at 
net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:78)
at 
net.sf.clirr.core.internal.checks.InterfaceSetCheck.check(InterfaceSetCheck.java:58)
at net.sf.clirr.core.Checker.runClassChecks(Checker.java:190)
at net.sf.clirr.core.Checker.reportDiffs(Checker.java:136)
at 
org.codehaus.mojo.clirr.AbstractClirrMojo.reportDiffs(AbstractClirrMojo.java:740)
at 
org.codehaus.mojo.clirr.AbstractClirrMojo.executeClirr(AbstractClirrMojo.java:308)
at org.codehaus.mojo.clirr.ClirrReport.doReport(ClirrReport.java:243)
at org.codehaus.mojo.clirr.ClirrReport.generate(ClirrReport.java:219)
at org.codehaus.mojo.clirr.ClirrReport.generate(ClirrReport.java:355)
at 
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:233)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:311)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:129)
at 
org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:182)
at 
org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:141)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
{code}

> Fix Java 8 related problem in site build
> 
>
> Key: LANG-1025
> URL: https://issues.apache.org/jira/browse/LANG-1025
> Project: Commons Lang
>  Issue Type: Task
>Affects Versions: 3.3.2
> Environment: Java 8
>Reporter: Benedikt Ritter
> Fix For: Patch Needed
>
>
> After LANG-1024 has been fixed, the site build now fails with: 
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project 
> commons-lang3: Execution default-site of goal 
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Invalid byte tag 
> in constant pool: 18 -> [Help 1]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (LANG-1093) Add ClassUtils.getAbbreviatedName

2015-03-23 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375643#comment-14375643
 ] 

ASF GitHub Bot commented on LANG-1093:
--

GitHub user CodingFabian opened a pull request:

https://github.com/apache/commons-lang/pull/57

Fixes JavaDoc of LANG-1093



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/CodingFabian/commons-lang LANG-1093-javadoc

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/57.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #57


commit c84a674cb7a256193d43e5621d6a6bc7eb5fa366
Author: Fabian Lange 
Date:   2015-03-23T09:56:47Z

Fixes JavaDoc of LANG-1093




> Add ClassUtils.getAbbreviatedName
> -
>
> Key: LANG-1093
> URL: https://issues.apache.org/jira/browse/LANG-1093
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Reporter: Fabian Lange
>Assignee: Benedikt Ritter
>  Labels: github
> Fix For: 3.4
>
>
> It would be really nice to have a class name shortener functionality 
> available similar to what some logger frameworks use.
> I took the idea for my implementation from logback, including the quirky 
> treatment of the desired length argument, feel free to discuss on the PR/here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (LANG-935) Possible performance improvement on string escape functions

2015-03-23 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375629#comment-14375629
 ] 

ASF GitHub Bot commented on LANG-935:
-

GitHub user CodingFabian opened a pull request:

https://github.com/apache/commons-lang/pull/56

Some minor fixup of LANG-935.

Avoid toString() of the replacement sequence by doing it once.
Avoid calculating the maximum when not needed.
Fixup comment for greedy algorithm.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/CodingFabian/commons-lang LANG-935-additions

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/56.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #56


commit b8a7b292e52b88ee6fc88159dcfd7860920b8ad0
Author: Fabian Lange 
Date:   2015-03-23T09:37:09Z

Some minor fixup of LANG-935.

Avoid toString() of the replacement sequence by doing it once.
Avoid calculating the maximum when not needed.
Fixup comment for greedy algorithm.




> Possible performance improvement on string escape functions
> ---
>
> Key: LANG-935
> URL: https://issues.apache.org/jira/browse/LANG-935
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.text.translate.*
>Affects Versions: 3.1
>Reporter: Peter Wall
>Priority: Minor
>  Labels: performance
> Fix For: 3.4
>
> Attachments: LANG-935.patch, tempproject1.zip
>
>
> The escape functions for HTML etc. use the same code and the same 
> initialisation tables for the escape and unescape functions, and while this 
> is an elegant approach it leads to a number of deficiencies:
> 1. The code is very much less efficient than it could be
> 2. A new output string is created even when no conversion is required
> 3. No mapping is provided for characters that do not have a specific 
> representation (for example HTML 0x101 should become ā )
> The proposal is to use a new mapping technique to address these issues



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (LANG-1025) Fix Java 8 related problem in site build

2015-03-23 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/LANG-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated LANG-1025:
--
Fix Version/s: (was: 3.4)

> Fix Java 8 related problem in site build
> 
>
> Key: LANG-1025
> URL: https://issues.apache.org/jira/browse/LANG-1025
> Project: Commons Lang
>  Issue Type: Task
>Affects Versions: 3.3.2
> Environment: Java 8
>Reporter: Benedikt Ritter
> Fix For: Patch Needed
>
>
> After LANG-1024 has been fixed, the site build now fails with: 
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project 
> commons-lang3: Execution default-site of goal 
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Invalid byte tag 
> in constant pool: 18 -> [Help 1]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (LANG-1025) Fix Java 8 related problem in site build

2015-03-23 Thread Benedikt Ritter (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375622#comment-14375622
 ] 

Benedikt Ritter commented on LANG-1025:
---

This is caused by Clirr and can only be fixed by a Clirr version that can 
handle Java 8. As far as I know, Clirr uses BCEL, so there won't be a new Clirr 
version until we release BCEL 6.0.

> Fix Java 8 related problem in site build
> 
>
> Key: LANG-1025
> URL: https://issues.apache.org/jira/browse/LANG-1025
> Project: Commons Lang
>  Issue Type: Task
>Affects Versions: 3.3.2
> Environment: Java 8
>Reporter: Benedikt Ritter
> Fix For: Patch Needed
>
>
> After LANG-1024 has been fixed, the site build now fails with: 
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project 
> commons-lang3: Execution default-site of goal 
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Invalid byte tag 
> in constant pool: 18 -> [Help 1]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (LANG-1088) Fix FastDateParse to do case-blind time zone matching?

2015-03-23 Thread Benedikt Ritter (JIRA)

[ 
https://issues.apache.org/jira/browse/LANG-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375474#comment-14375474
 ] 

Benedikt Ritter commented on LANG-1088:
---

This issue has been resolved I do not see a commit in SVN. [~chonton] can you 
comment please?

> Fix FastDateParse to do case-blind time zone matching?
> --
>
> Key: LANG-1088
> URL: https://issues.apache.org/jira/browse/LANG-1088
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Sebb
>Assignee: Charles Honton
> Fix For: 3.x
>
>
> It looks like SimpleDataFormat does not care what case is used for time zones.
> However, this does not appear to be documented.
> Should FastDateParser copy this behaviour?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (LANG-1100) Avoid memory allocation when using date formating to StringBuffer.

2015-03-23 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/LANG-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated LANG-1100:
--
Fix Version/s: (was: 3.x)
   (was: Review Patch)
   3.4

> Avoid memory allocation when using date formating to StringBuffer.
> --
>
> Key: LANG-1100
> URL: https://issues.apache.org/jira/browse/LANG-1100
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Benedikt Ritter
>Assignee: Charles Honton
>  Labels: github
> Fix For: 3.4
>
>
> Placeholder for https://github.com/apache/commons-lang/pull/35



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (LANG-1101) FastDateParser and FastDatePrinter do not support 'X' format

2015-03-23 Thread Benedikt Ritter (JIRA)

 [ 
https://issues.apache.org/jira/browse/LANG-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated LANG-1101:
--
Fix Version/s: (was: 3.x)
   3.4

> FastDateParser and FastDatePrinter do not support 'X' format
> 
>
> Key: LANG-1101
> URL: https://issues.apache.org/jira/browse/LANG-1101
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.time.*
>Reporter: Charles Honton
>Assignee: Charles Honton
>Priority: Minor
> Fix For: 3.4
>
>
> JDK7 added ISO 8601 Time zone support using the format character 'X'.  Add 
> this support to FastDateParser and FastDatePrinter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)