[jira] [Commented] (COLLECTIONS-605) Add new CollectionUtils Feature - addNCopies

2017-06-25 Thread BELUGA BEHR (JIRA)

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

BELUGA BEHR commented on COLLECTIONS-605:
-

[~s...@apache.org] Any thoughts? :)

> Add new CollectionUtils Feature - addNCopies
> 
>
> Key: COLLECTIONS-605
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-605
> Project: Commons Collections
>  Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: BELUGA BEHR
>Priority: Trivial
> Attachments: COLLECTIONS-605.1.patch
>
>
> Java's {{java.util.Collections}} has:
> {code}
> nCopies(int n, T o)
> Returns an immutable list consisting of n copies of the specified object.
> addAll(Collection c, T... elements)
> Adds all of the specified elements to the specified collection.
> fill(List list, T obj)
> Replaces all of the elements of the specified list with the specified element.
> {code}
> However, it does not have the ability to add nCopies directly to a Collection.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

2017-06-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/46
  

[![Coverage 
Status](https://:/builds/12125302/badge)](https://:/builds/12125302)

Coverage increased (+0.1%) to 84.886% when pulling 
**8aeaa9c418862fc1d4fb4e166da72a2fac2493dc on sesuncedu:COMPRESS-400-squash** 
into **19e1b02f754a9b7bc969eb17bd52cc36a85c4d74 on apache:master**.



> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

2017-06-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on COMPRESS-400:
-

GitHub user sesuncedu opened a pull request:

https://github.com/apache/commons-compress/pull/46

COMPRESS-400 : Squashed version of  COMPRESS-400-REDUX.

Add support for extra PAX headers (local and global).
This PR has a single squash commit to simplify final  review
Signed-off-by: Simon Spero 

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

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-400-squash

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

https://github.com/apache/commons-compress/pull/46.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 #46


commit 8aeaa9c418862fc1d4fb4e166da72a2fac2493dc
Author: Simon Spero 
Date:   2017-06-25T22:28:07Z

COMPRESS-400 : Squash commit of COMPRESS-400-REDUX.

Add support for extra PAX headers (local and global).

Signed-off-by: Simon Spero 




> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

2017-06-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/31
  

[![Coverage 
Status](https://:/builds/12125243/badge)](https://:/builds/12125243)

Coverage increased (+0.1%) to 84.862% when pulling 
**daebf440f05432c00067e58074aa1922f5b80c8d on sesuncedu:COMPRESS-400-REDUX** 
into **19e1b02f754a9b7bc969eb17bd52cc36a85c4d74 on apache:master**.



> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

2017-06-25 Thread Simon Spero (JIRA)

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

Simon Spero commented on COMPRESS-400:
--

Just added a  commit to  remote abstracted support for extended attributes. The 
commit message has some extended notes, which I am adding to the work log 
should this need to be revisited (since a lot of this stuff is not documented 
except in 'read the source code, not the spec'. 

If this  needs to be revisited, the following information is useful:

1. pax header keywords should be ascii. 
   star/gnutar (SCHILY.xattr.* ) do not check for this. 
   libarchive/bsdtar (LIBARCHIVE.xattr.*)  use URL-Encoding. 
   
2. pax header values should be encoded as UTF-8 characters (including \0). 
   star/gnutar (SCHILY.xattr.*) do not check for this.
   libarchive/bsdtar (LIBARCHIVE.xattr.*) encode values using Base64. 
   
libarchive/bsdtar will read SCHILY.xattr headers, but will not generate them. 

gnutar will complain about LIBARCHIVE.xattr (and any other unknown) headers and 
will neither encode nor decode them.
I believe that star is the same.
 
Proper support for handling extended attributes may require knowing which 
convention should 
be used on output. It may also require additional methods that handle byte[] 
values appropriately.

Should Path based initalization of entry metadata be supported, it should be 
noted that Java's abstraction of extended attributes treats handles them as 
binary values (which must fit in a single ByteBuffer, and thus are of maximum 
size MAX_INT).   nio file attribute views may be a suitable basis handling 
xattrs (and other related metadata).  

https://docs.oracle.com/javase/7/docs/api/java/nio/file/attribute/UserDefinedFileAttributeView.html

> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters

2017-06-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on TEXT-93:


Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/54
  
As per discussion 
here[TEXT-93](https://issues.apache.org/jira/browse/TEXT-93) we are good to 
merge this PR. 


> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (JEXL-229) Introduce new syntax for class literals: Class and Type

2017-06-25 Thread Dmitri Blinov (JIRA)
Dmitri Blinov created JEXL-229:
--

 Summary: Introduce new syntax for class literals: Class and 
Type
 Key: JEXL-229
 URL: https://issues.apache.org/jira/browse/JEXL-229
 Project: Commons JEXL
  Issue Type: New Feature
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Minor


For the purpose of type checking in jexl, It whould be convenient to have some 
simple syntax for referring to class types, like Class or 
Type. Literal Class should refer to general classes, and literal 
Type should refer to primitive type classes. For literals Class it could 
be possible to specify partal class name, which should resolve to classes in 
basic packages like java.lang and java.util, for example.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters

2017-06-25 Thread Gilles (JIRA)

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

Gilles commented on TEXT-93:


It's fine to delay the addition of the overloaded method to when someone has a 
use-case for it...


> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (JEXL-228) Ability to read j.u.Collection elements other than instanceof j.u.List by using [] and . operator

2017-06-25 Thread Dmitri Blinov (JIRA)
Dmitri Blinov created JEXL-228:
--

 Summary: Ability to read j.u.Collection elements other than 
instanceof j.u.List by using [] and . operator
 Key: JEXL-228
 URL: https://issues.apache.org/jira/browse/JEXL-228
 Project: Commons JEXL
  Issue Type: Improvement
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Minor


In the current implementation of Jexl there is a possibility to address in a 
script the specific elements of {{List}} and {{Array}} by using operators 
{{[]}} or {{.}}, whereas its not that simple for descendants of {{Set}} or any 
other {{Collection}} descendant, as there is no such an operator for them out 
of the box. But in practice this is not so uncommon task for a script writer to 
get, for example, the first element of the LinkedHashSet, which is supposed to 
maintain the logical order of its elements, but unfortunately does not 
implement {{List}} interface for us to be able to address its elements in that 
order. I believe such a basic functionality - deserves to be available for 
script witers from the start.

I have been experimenting with overloading access operators in customized 
JexlArithmetic for a while and have managed to overload operators {{[]}} and 
{{.}} so that they could be used not only for {{List}} interfaces but for other 
{{Collection}} types as well:

{code}
protected Object nth(Collection c, int i) {

   if (c instanceof List) {
 List list = (List) c;
 return list.get(i);
   } else {

 for (Object o : c) {
if (i-- == 0)
  return o;
 }
   }

   return null;
}

public Object propertyGet(Collection c, Number n) {
   return nth(c, n.intValue());
}

public Object arrayGet(Collection c, Number n) {
   return nth(c, n.intValue());
}
{code}

But I'm not satisfied with the fact that I have disabled alltogether the 
initial Jexl implementation of access operators for {{LIst}} types.

The suggestion is to add the ability for Jexl scripts to read, not manipulate, 
elements of any {{Collection}} type. 

BTW, I have found that for {{List}} elements this solution is roughly 50% 
faster compared with that of built-in Jexl List access implementation, so may 
be there should be a place for a performance improvement in a way Jexl itself 
accesses list elements.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[GitHub] commons-lang issue #272: Replaced test with verify

2017-06-25 Thread ameyjadiye
Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-lang/pull/272
  
Merged, thanks @garydgregory 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] commons-lang pull request #272: Replaced test with verify

2017-06-25 Thread ameyjadiye
Github user ameyjadiye closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---