Support Percent-Encoding (described in RFC3986 and RFC7578)

[Giannis Sermetziadis]

Hi there. I already created a Jira ticket for this (CODEC-240), but
then found the contribution instructions :)

My suggestion is to provide a codec that implements the
Percent-Encoding as defined in RFC3986 and RFC7578. This is similar to
URLCodec but does not force the ' ' to '+' encoding and others, but
follows the spec by encoding with what the spec defines only the
octets that are outside the allowed set of the encoding being used.

I can provide a pull-request, if you agree that this is useful.

Giannis

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[CANCEL][VOTE] Release Apache Commons JCS 2.2.1

[Romain Manni-Bucau]

Cancelling then :(. Thanks guys for your help and feedbacks.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn 

2017-09-29 16:09 GMT+02:00 Thomas Vandahl :

> On 28.09.17 19:23, Romain Manni-Bucau wrote:
> > Do I need to cancel this vote? Cant relaunch a vote before ~2 weeks if so
> > (will be travelling) but happy to catch up after if you think it is the
> way
> > to go.
>
> I'm afraid so. You published 2.2.2-SNAPSHOT to the release area. You
> probably need to roll back the tag.
>
> Bye, Thomas.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[GitHub] commons-text pull request #62: TEXT-101: Moved RandomStringUtils to Commons-...

[ameyjadiye]

Github user ameyjadiye closed the pull request at:

https://github.com/apache/commons-text/pull/62


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #62: TEXT-101: Moved RandomStringUtils to Commons-text

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/62
  
As per discussion on Dev ML we are undoing deprecation of RandomStringUtils 
in Lang and discarding this solution. 


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang][text] TEXT-101: RandomStringUtils

[Amey Jadiye]

Okey, no problem folks. I'm going to close my PR. also we might need to
release lang-3.6.1 for undoing deprecation of RandomStringUtils  if
lang-3.7 is far.

Regards,
Amey

On Fri, Sep 29, 2017 at 1:41 PM, Pascal Schumacher  wrote:

> After thinking more about it, I came the conclusion that RandomStringUtils
> fits into [lang], so I'm for option (b).
>
> Cheers,
> Pascal
>
>
> Am 28.09.2017 um 23:26 schrieb Rob Tompkins:
>
>> Options:
>>
>> (a) leave RandomStringUtils deprecated in [lang] and pull in Amey’s pull
>> request moving it into [text].
>> (b) undeprecate it in [lang].
>>
>> The question is where should it reside? Does it fit as a general java
>> Lang extension or is it more focused on text?
>>
>> I’m in the middle here. Note also that we had some users ask why it had
>> been deprecated with no alternative.
>>
>> Amey - keep me honest here. I don’t want to overlook anything.
>>
>> -Rob
>>
>> On Sep 28, 2017, at 5:13 PM, Gary Gregory  wrote:
>>>
>>> Can someone summarize what our options are here please? I'd rather see it
>>> fresh than chasing links in mailing list archives and try to un-nest all
>>> the nesting... ;-)
>>>
>>> Gary
>>>
>>>
>>>
>>> On Wed, Sep 27, 2017 at 1:01 PM, Rob Tompkins 
>>> wrote:
>>>
>>> As I'm pulling this in this crosses my mind:

 Wait I'm curious here. Weren't folks leaning towards keeping
 RandomStringUtils in [lang]?

 The thread in question is this one: http://markmail.org/message/
 5tblwhldrwsbfdym

 It feels like @britter , @PascalSchumacher
 , and @garydgregory
  were all leaning towards the [lang]
 option. If that's the case we should probably go with that.

 —
 You are receiving this because you were mentioned.
 Reply to this email directly, view it on GitHub
 ,
 or mute the thread
 
 .

 -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 

-

To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons JCS 2.2.1

[Thomas Vandahl]

On 28.09.17 19:23, Romain Manni-Bucau wrote:
> Do I need to cancel this vote? Cant relaunch a vote before ~2 weeks if so
> (will be travelling) but happy to catch up after if you think it is the way
> to go.

I'm afraid so. You published 2.2.2-SNAPSHOT to the release area. You
probably need to roll back the tag.

Bye, Thomas.



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons VFS 2.2 from RC1.

[Gary Gregory]

Would a few of you please find the time to review this RC?

Thank you in advance for your input,
Gary

On Sat, Sep 23, 2017 at 10:43 AM, Gary Gregory  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons VFS 2.1 was released, so I would like to release
> Apache Commons VFS 2.2.
>
> Apache Commons VFS 2.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/vfs/ (svn revision
> 21925)
> Get it: svn co https://dist.apache.org/repos/dist/dev/commons/vfs/
>
> The tag is here:
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/
> commons-vfs2-project-2.2-rc1/ (svn revision 1809435)
> N.B. the SVN revision is required because SVN tags are not immutable.
> Get it: svn co https://svn.apache.org/repos/
> asf/commons/proper/vfs/tags/commons-vfs2-project-2.2-rc1/
>
> Maven artifacts are here:
> https://repository.apache.org/service/local/repositories/
> orgapachecommons-1268/content/org/apache/commons/commons-
> vfs2-distribution/2.2/
>
> These are the artifacts and their SHA1 hashes:
>
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
> vfs2-distribution-2.2-src.tar.gz
> (SHA1: 212a069b5b1534686b68fe35a6984920d9413fde)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
> vfs2-distribution-2.2-bin.zip.asc
> (SHA1: aac456496d4af37a1d1912b8348b4701cf337c85)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
> vfs2-distribution-2.2.pom
> (SHA1: d8053a146c0d7e4b9cf649e8d6a0aff680dc3946)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
> vfs2-distribution-2.2-src.zip.asc
> (SHA1: dbdddf332fc7929672c3cf5211d97aaafb5f4aa2)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
> vfs2-distribution-2.2-bin.zip
> (SHA1: d3021e90433d666715ffbef729036af1514e1fad)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
> vfs2-distribution-2.2-bin.tar.gz
> (SHA1: 6c363670be91fbacdbc2d67012952f30e56001c2)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
> vfs2-distribution-2.2.pom.asc
> (SHA1: 0ceb2511d213875ec5f99d471075c5dc700282c4)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
> vfs2-distribution-2.2-src.tar.gz.asc
> (SHA1: 54bcff53b916a9285926e9df20874d69a10325a9)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
> vfs2-distribution-2.2-src.zip
> (SHA1: 7b99183a0e7c57d67b857c5a8ad57a1fdb126047)
> /org/apache/commons/commons-vfs2-distribution/2.2/commons-
> vfs2-distribution-2.2-bin.tar.gz.asc
> (SHA1: 7061382cf7e04adf78b24972ccd6698cc374cc16)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2.jar.asc
> (SHA1: dcba69041d5c882598655f05db26a4742885a85b)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-test-sources.jar
> (SHA1: a36920f558b04a941d87a1efde85bd9d4559c2c3)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-tests.jar.asc
> (SHA1: fc31bf4504414da6d2b2290314fac060335a)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-javadoc.jar.asc
> (SHA1: 2b9ff24d85e9ead07add09f976211d594dd1c3e5)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2.pom.asc
> (SHA1: 2dd6bee343974fccf75f2ccb406827b996da7ddc)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2.pom
> (SHA1: 8ddc26fc8729a7f3a6a1c642e4069b58d3a5ec04)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-test-sources.jar.asc
> (SHA1: cbc27431defc0c34c7303d7f6ba0e367feea19cf)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-sources.jar.asc
> (SHA1: 29d1e2c30e404ea5cf9d7e5544479e04a78314cb)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2.jar
> (SHA1: 18f974ce4c6a978eca23f769af8c6898d9694424)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-sources.jar
> (SHA1: 8694cec165e6ef6c796a8bfae2ef565f32a5b82c)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-javadoc.jar
> (SHA1: 972e8bd4c3d4e3b5fbd2033aa4d80013eb1ec694)
> /org/apache/commons/commons-vfs2/2.2/commons-vfs2-2.2-tests.jar
> (SHA1: 5e238e41b28c10f2ca21dc56f5bca471cd892ebd)
> /org/apache/commons/commons-vfs2-project/2.2/commons-vfs2-
> project-2.2-site.xml
> (SHA1: 45db714de819ec12adc528479bf9a4a2e15ba323)
> /org/apache/commons/commons-vfs2-project/2.2/commons-vfs2-project-2.2.pom
> (SHA1: dece2db6026f36f9dbbad8668cfb1fca867fbb64)
> /org/apache/commons/commons-vfs2-project/2.2/commons-vfs2-
> project-2.2.pom.asc
> (SHA1: d2998c437160b336480b7faed21256eed16ffc95)
> /org/apache/commons/commons-vfs2-project/2.2/commons-vfs2-
> project-2.2-site.xml.asc
> (SHA1: 1c3ca11863fa8a12356c19fd35602aad51cc9052)
> /org/apache/commons/commons-vfs2-examples/2.2/commons-
> vfs2-examples-2.2-sources.jar.asc
> (SHA1: dcbedc0faceff7b5694352b28286fb706e30712f)
> /org/apache/commons/commons-vfs2-examples/2.2/commons-
> vfs2-examples-2.2-sources.jar
> (SHA1: 1744c6a0eac0c79a776e1d321f63862cc0123284)
> /org/apache/commons/commons-vfs2-examples/2.2/commons-
> vfs2-examples-2.2-javadoc.jar.asc
> (SHA1: 18b70a1620eba89ad6b92228989aeb3c44fe566c)
> 

Re: [lang] Commons Lang 2.x release for Java 9

[Gary Gregory]

I think we should keep the changes to a minimum.

Gary

On Sep 29, 2017 02:08, "Emmanuel Bourg"  wrote:

> Hi all,
>
> I'd like to prepare a new release of Commons Lang 2 that addresses the
> Java 9 compatibility. I have two items in mind for this update, the
> automatic module name in the manifest of course, but also the
> SystemUtils.isJavaVersionAtLeast() method that is broken with Java 9 and
> throws an Exception. This would be a minimal update branched off the
> latest 2.6 release.
>
> Do you see anything else that should be addressed in this update?
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [lang][text] TEXT-101: RandomStringUtils

[Benedikt Ritter]

> Am 29.09.2017 um 10:11 schrieb Pascal Schumacher :
> 
> After thinking more about it, I came the conclusion that RandomStringUtils 
> fits into [lang], so I'm for option (b).

+1

> 
> Cheers,
> Pascal
> 
> Am 28.09.2017 um 23:26 schrieb Rob Tompkins:
>> Options:
>> 
>> (a) leave RandomStringUtils deprecated in [lang] and pull in Amey’s pull 
>> request moving it into [text].
>> (b) undeprecate it in [lang].
>> 
>> The question is where should it reside? Does it fit as a general java Lang 
>> extension or is it more focused on text?
>> 
>> I’m in the middle here. Note also that we had some users ask why it had been 
>> deprecated with no alternative.
>> 
>> Amey - keep me honest here. I don’t want to overlook anything.
>> 
>> -Rob
>> 
>>> On Sep 28, 2017, at 5:13 PM, Gary Gregory  wrote:
>>> 
>>> Can someone summarize what our options are here please? I'd rather see it
>>> fresh than chasing links in mailing list archives and try to un-nest all
>>> the nesting... ;-)
>>> 
>>> Gary
>>> 
>>> 
>>> 
>>> On Wed, Sep 27, 2017 at 1:01 PM, Rob Tompkins 
>>> wrote:
>>> 
 As I'm pulling this in this crosses my mind:
 
 Wait I'm curious here. Weren't folks leaning towards keeping
 RandomStringUtils in [lang]?
 
 The thread in question is this one: http://markmail.org/message/
 5tblwhldrwsbfdym
 
 It feels like @britter , @PascalSchumacher
 , and @garydgregory
  were all leaning towards the [lang]
 option. If that's the case we should probably go with that.
 
 —
 You are receiving this because you were mentioned.
 Reply to this email directly, view it on GitHub
 ,
 or mute the thread
 
 .
 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang][text] TEXT-101: RandomStringUtils

[Gilles]

On Fri, 29 Sep 2017 10:11:07 +0200, Pascal Schumacher wrote:

After thinking more about it, I came the conclusion that
RandomStringUtils fits into [lang], so I'm for option (b).

Cheers,
Pascal

Am 28.09.2017 um 23:26 schrieb Rob Tompkins:

Options:

(a) leave RandomStringUtils deprecated in [lang] and pull in Amey’s 
pull request moving it into [text].


+1

Gilles


(b) undeprecate it in [lang].

The question is where should it reside? Does it fit as a general 
java Lang extension or is it more focused on text?


I’m in the middle here. Note also that we had some users ask why it 
had been deprecated with no alternative.


Amey - keep me honest here. I don’t want to overlook anything.

-Rob

On Sep 28, 2017, at 5:13 PM, Gary Gregory  
wrote:


Can someone summarize what our options are here please? I'd rather 
see it
fresh than chasing links in mailing list archives and try to 
un-nest all

the nesting... ;-)

Gary



On Wed, Sep 27, 2017 at 1:01 PM, Rob Tompkins 


wrote:


As I'm pulling this in this crosses my mind:

Wait I'm curious here. Weren't folks leaning towards keeping
RandomStringUtils in [lang]?

The thread in question is this one: http://markmail.org/message/
5tblwhldrwsbfdym

It feels like @britter , 
@PascalSchumacher

, and @garydgregory
 were all leaning towards the 
[lang]

option. If that's the case we should probably go with that.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

,
or mute the thread


.




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang][text] TEXT-101: RandomStringUtils

[Pascal Schumacher]

After thinking more about it, I came the conclusion that 
RandomStringUtils fits into [lang], so I'm for option (b).


Cheers,
Pascal

Am 28.09.2017 um 23:26 schrieb Rob Tompkins:

Options:

(a) leave RandomStringUtils deprecated in [lang] and pull in Amey’s pull 
request moving it into [text].
(b) undeprecate it in [lang].

The question is where should it reside? Does it fit as a general java Lang 
extension or is it more focused on text?

I’m in the middle here. Note also that we had some users ask why it had been 
deprecated with no alternative.

Amey - keep me honest here. I don’t want to overlook anything.

-Rob


On Sep 28, 2017, at 5:13 PM, Gary Gregory  wrote:

Can someone summarize what our options are here please? I'd rather see it
fresh than chasing links in mailing list archives and try to un-nest all
the nesting... ;-)

Gary



On Wed, Sep 27, 2017 at 1:01 PM, Rob Tompkins 
wrote:


As I'm pulling this in this crosses my mind:

Wait I'm curious here. Weren't folks leaning towards keeping
RandomStringUtils in [lang]?

The thread in question is this one: http://markmail.org/message/
5tblwhldrwsbfdym

It feels like @britter , @PascalSchumacher
, and @garydgregory
 were all leaning towards the [lang]
option. If that's the case we should probably go with that.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
,
or mute the thread

.


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[lang] Commons Lang 2.x release for Java 9

[Emmanuel Bourg]

Hi all,

I'd like to prepare a new release of Commons Lang 2 that addresses the
Java 9 compatibility. I have two items in mind for this update, the
automatic module name in the manifest of course, but also the
SystemUtils.isJavaVersionAtLeast() method that is broken with Java 9 and
throws an Exception. This would be a minimal update branched off the
latest 2.6 release.

Do you see anything else that should be addressed in this update?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text pull request #65: Sort pom file

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/65


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org