[GitHub] commons-text issue #54: TEXT-93: RandomStringGenerator accepts a list of val...

[ameyjadiye]

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. 


---
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.
---

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

Re: [configuration] checkstyle fails build

[Simon Spero]

On Jun 24, 2017 12:31 PM, "Oliver Heger" 
wrote:

Should changes related to the setup and handling of checkstyle then be
done for Commons as a whole?

(No P.S.)


It is the sort of thing fits nearly I  a parent. Maven is one example (not
sure how much customization is needed).

Also, in Java 9 you can get rid of the NoPS with the spin-wait hinting.

Simon

Re: [configuration] checkstyle fails build

[sebb]

On 25 June 2017 at 10:09, Claude Warren  wrote:
> Eclipse lets you export the format rules as separate files.  My suggestion
> was intended to mean that these files should be included, not the entire
> .settings as that contains a number of local settings and my leak
> confidential information. (I have not verified that it will leak
> confidential information).

Regardless of whether any information is leaked, Eclipse config files
are generally NOT portable between systems.
This is because they may contain local paths, and also people may wish
to include different features.

> Another option would be to use something like:
> http://code.revelc.net/formatter-maven-plugin/formatter-maven-plugin/usage.html
> to format the code during the maven build.
>
> On Fri, Jun 23, 2017 at 5:44 PM, Gary Gregory 
> wrote:
>
>> On Fri, Jun 23, 2017 at 9:35 AM, sebb  wrote:
>>
>> > On 23 June 2017 at 17:29, Gary Gregory  wrote:
>> > > On Fri, Jun 23, 2017 at 8:21 AM, Claude Warren 
>> wrote:
>> > >
>> > >> How about an eclipse format configuration that will correct the error
>> on
>> > >> demand.  Granted you have to run eclipse but if such a file were
>> created
>> > >> (and checked in) then it would be easy for anyone running eclipse to
>> fix
>> > >> it.
>> > >>
>> > >
>> > > I use Eclipse and would appreciate such a file. In the past we've not
>> > > included IDE files in the repo but making it easier would be nice.
>> >
>> > If added, these should be optional.
>> > i.e. don't use the same name as Eclipse uses, but copy the required
>> > settings to another file.
>> >
>> > See for example how Tomcat do it:
>> >
>> > http://svn.apache.org/repos/asf/tomcat/trunk/res/ide-support/eclipse/
>>
>>
>> Putting the files in a separate folder is one thing but flattening the
>> folders and changing file names is -1. Just put the Eclipse .settings
>> folder I should be using so I can overlay it on top of my project.
>> Otherwise, a user has to know where to sprinkle each file in each place.
>> Maybe something like:
>>
>> .../eclipse/.classpath
>> .../eclipse/.project
>> .../eclipse/.settings/fileA
>> .../eclipse/.settings/fileB
>> .../eclipse/.settings/folderA
>>
>> and so on.
>>
>> Gary
>>
>> >
>> >
>> > > Gary
>> > >
>> > >>
>> > >> Claude
>> > >>
>> > >> On Fri, Jun 23, 2017 at 4:03 PM, Oliver Heger <
>> > >> oliver.he...@oliver-heger.de>
>> > >> wrote:
>> > >>
>> > >> >
>> > >> >
>> > >> > Am 23.06.2017 um 08:58 schrieb Allon Mureinik:
>> > >> > > The root cause, IMHO, is having failValidation=false configured in
>> > the
>> > >> > > pom.xml. This way, when you introduce a new problem your only
>> > option to
>> > >> > > notice it is if you visually scan mvn's output. As evident by the
>> > >> current
>> > >> > > state of the build, not everyone notices these.
>> > >> > > A more robust approach would be to set failValidation=true, and
>> > >> actively
>> > >> > > fail the build if checkstyle's rules are violated.
>> > >> > >
>> > >> > > I've submitted a PR to fix all the existing issues and enable this
>> > >> > > validation. Reviews are welcome:
>> > >> > > https://github.com/apache/commons-configuration/pull/5
>> > >> > >
>> > >> >
>> > >> > Thanks for the PR, I will have a look.
>> > >> >
>> > >> > However, letting the build fail because of checkstyle error is too
>> > >> > restrictive IMHO. My approach is to work through the errors before
>> > >> > creating a new release. This has the disadvantage that errors might
>> > >> > accumulate; but from one release to the next one there is typically
>> > not
>> > >> > that much.
>> > >> >
>> > >> > Oliver
>> > >> >
>> > >> > >
>> > >> > > On Thu, Jun 22, 2017 at 11:10 PM, Gary Gregory <
>> > garydgreg...@gmail.com
>> > >> >
>> > >> > > wrote:
>> > >> > >
>> > >> > >> FYI, to whom can take the time to fix this.
>> > >> > >>
>> > >> > >> When I run 'mvn clean install', I get:
>> > >> > >>
>> > >> > >> [INFO] --- maven-checkstyle-plugin:2.15:check (default) @
>> > >> > >> commons-configuration2 ---
>> > >> > >> [INFO] There are 23 errors reported by Checkstyle 6.1.1 with
>> > >> > >> C:\vcs\svn\apache\commons\trunks-proper\configuration/
>> > >> > conf/checkstyle.xml
>> > >> > >> ruleset.
>> > >> > >> [ERROR]
>> > >> > >> src\main\java\org\apache\commons\configuration2\
>> > >> > >> AbstractHierarchicalConfiguration.java[976]
>> > >> > >> (regexp) RegexpSingleline: Line has trailing spaces.
>> > >> > >> [ERROR]
>> > >> > >> src\main\java\org\apache\commons\configuration2\
>> > >> > >> AbstractHierarchicalConfiguration.java[978:30]
>> > >> > >> (blocks) LeftCurly: '{' should be on a new line.
>> > >> > >> [ERROR]
>> > >> > >> src\main\java\org\apache\commons\configuration2\
>> > >> > >> AbstractYAMLBasedConfiguration.java[0]
>> > >> > >> (misc) NewlineAtEndOfFile: File does not end with a newline.
>> > >> > >> [ERROR]
>> > >> > >> 

Re: [FUNCTOR] Why do we have an API module?

[Benedikt Ritter]

Hi,

> Am 24.06.2017 um 20:19 schrieb Matt Benson :
> 
> TBH, I don't know that I think there's a reason to do such a library
> unless it's really a game changer. Some years ago I was working on
> some code outside the ASF, but it never went anywhere. The approach I
> took would have been pretty controversial, but we're so behind the
> curve here there's no reason IMO to do anything if it's not fairly
> radical.

Currently functor is somehow in limbo state. It has been promoted to proper, 
but there has never been a release. So I wonder what we want to do with it. 
Currently I’m thinking about a library providing some utility functor 
implementations. That’s the reason I thought only targeting Java 8 would be a 
good idea.

Thank you. Your input here is very much appreciated!

Cheers,
Benedikt

> 
> Matt
> 
> On Sat, Jun 24, 2017 at 12:29 PM, Benedikt Ritter  wrote:
>> Hi Matt,
>> 
>> what is your opinion in this topic (targeting Java 8)
>> 
>> Benedikt
>> 
>> Matt Benson  schrieb am Sa. 24. Juni 2017 um 19:18:
>> 
>>> If we want to repurpose functor for Java 8 then I imagine we'd just
>>> use their interfaces, for the most part. So the API module would
>>> indeed probably go away.
>>> 
>>> Matt
>>> 
>>> On Sat, Jun 24, 2017 at 12:08 PM, Benedikt Ritter 
>>> wrote:
 Hi,
 
> Am 16.06.2017 um 13:03 schrieb Matt Benson :
> 
> Yes, the point of the API module was to define the functional interfaces
> separately from the utility code around them; particularly pre-Java 8,
> these could be used apart from the utility code from the core.
 
 Since we discussed to just release functor for Java 8, do we still need
>>> this separation?
 
 Cheers,
 Benedikt
 
> 
> Matt
> 
> On Jun 16, 2017 4:27 AM, "Bruno P. Kinoshita"
>  wrote:
> 
> No objection here too. I've been gathering some links about other
>>> libraries
> and extensions to Java 8, to have a look at functor in the future and
>>> see
> if it would be interesting to have something there, unless it made more
> sense to put it on lang.
> 
> 
> The reason for the API module, if memory serves me well, was to provide
>>> a
> pre Java 8 implementation. This way we would have
> 
> - api
> - an implementation for Java 7
> - an implementation Java 8 that used Lambdas
> 
> Though right now, with Java 9 around the corner, a single module,
>>> trying to
> provide useful code that doesn't fit in lang would be better IMHO.
> 
> Hope that helps.
> 
> Thanks
> Bruno
> 
> From: Benedikt Ritter 
> To: Commons Developers List 
> Sent: Friday, 16 June 2017 9:04 PM
> Subject: [FUNCTOR] Why do we have an API module?
> 
> 
> 
> Hi,
> 
> 
> I’m about to start work on functor. Looking at the project, I wonder
>>> why we
> have a separation bewteen an API module and implementations. This feels
> like overkill to me for a project like functor. Further more I don’t see
> other parties extending the stuff in the API module. If nobody objects,
>>> I’d
> like to remove the multi-module build and move everything into a single
> code base.
> 
> 
> Regards,
> 
> Benedikt
> 
> -
> 
> 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
 
>>> 
>>> -
>>> 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: [configuration] checkstyle fails build

[Claude Warren]

Eclipse lets you export the format rules as separate files.  My suggestion
was intended to mean that these files should be included, not the entire
.settings as that contains a number of local settings and my leak
confidential information. (I have not verified that it will leak
confidential information).

Another option would be to use something like:
http://code.revelc.net/formatter-maven-plugin/formatter-maven-plugin/usage.html
to format the code during the maven build.

On Fri, Jun 23, 2017 at 5:44 PM, Gary Gregory 
wrote:

> On Fri, Jun 23, 2017 at 9:35 AM, sebb  wrote:
>
> > On 23 June 2017 at 17:29, Gary Gregory  wrote:
> > > On Fri, Jun 23, 2017 at 8:21 AM, Claude Warren 
> wrote:
> > >
> > >> How about an eclipse format configuration that will correct the error
> on
> > >> demand.  Granted you have to run eclipse but if such a file were
> created
> > >> (and checked in) then it would be easy for anyone running eclipse to
> fix
> > >> it.
> > >>
> > >
> > > I use Eclipse and would appreciate such a file. In the past we've not
> > > included IDE files in the repo but making it easier would be nice.
> >
> > If added, these should be optional.
> > i.e. don't use the same name as Eclipse uses, but copy the required
> > settings to another file.
> >
> > See for example how Tomcat do it:
> >
> > http://svn.apache.org/repos/asf/tomcat/trunk/res/ide-support/eclipse/
>
>
> Putting the files in a separate folder is one thing but flattening the
> folders and changing file names is -1. Just put the Eclipse .settings
> folder I should be using so I can overlay it on top of my project.
> Otherwise, a user has to know where to sprinkle each file in each place.
> Maybe something like:
>
> .../eclipse/.classpath
> .../eclipse/.project
> .../eclipse/.settings/fileA
> .../eclipse/.settings/fileB
> .../eclipse/.settings/folderA
>
> and so on.
>
> Gary
>
> >
> >
> > > Gary
> > >
> > >>
> > >> Claude
> > >>
> > >> On Fri, Jun 23, 2017 at 4:03 PM, Oliver Heger <
> > >> oliver.he...@oliver-heger.de>
> > >> wrote:
> > >>
> > >> >
> > >> >
> > >> > Am 23.06.2017 um 08:58 schrieb Allon Mureinik:
> > >> > > The root cause, IMHO, is having failValidation=false configured in
> > the
> > >> > > pom.xml. This way, when you introduce a new problem your only
> > option to
> > >> > > notice it is if you visually scan mvn's output. As evident by the
> > >> current
> > >> > > state of the build, not everyone notices these.
> > >> > > A more robust approach would be to set failValidation=true, and
> > >> actively
> > >> > > fail the build if checkstyle's rules are violated.
> > >> > >
> > >> > > I've submitted a PR to fix all the existing issues and enable this
> > >> > > validation. Reviews are welcome:
> > >> > > https://github.com/apache/commons-configuration/pull/5
> > >> > >
> > >> >
> > >> > Thanks for the PR, I will have a look.
> > >> >
> > >> > However, letting the build fail because of checkstyle error is too
> > >> > restrictive IMHO. My approach is to work through the errors before
> > >> > creating a new release. This has the disadvantage that errors might
> > >> > accumulate; but from one release to the next one there is typically
> > not
> > >> > that much.
> > >> >
> > >> > Oliver
> > >> >
> > >> > >
> > >> > > On Thu, Jun 22, 2017 at 11:10 PM, Gary Gregory <
> > garydgreg...@gmail.com
> > >> >
> > >> > > wrote:
> > >> > >
> > >> > >> FYI, to whom can take the time to fix this.
> > >> > >>
> > >> > >> When I run 'mvn clean install', I get:
> > >> > >>
> > >> > >> [INFO] --- maven-checkstyle-plugin:2.15:check (default) @
> > >> > >> commons-configuration2 ---
> > >> > >> [INFO] There are 23 errors reported by Checkstyle 6.1.1 with
> > >> > >> C:\vcs\svn\apache\commons\trunks-proper\configuration/
> > >> > conf/checkstyle.xml
> > >> > >> ruleset.
> > >> > >> [ERROR]
> > >> > >> src\main\java\org\apache\commons\configuration2\
> > >> > >> AbstractHierarchicalConfiguration.java[976]
> > >> > >> (regexp) RegexpSingleline: Line has trailing spaces.
> > >> > >> [ERROR]
> > >> > >> src\main\java\org\apache\commons\configuration2\
> > >> > >> AbstractHierarchicalConfiguration.java[978:30]
> > >> > >> (blocks) LeftCurly: '{' should be on a new line.
> > >> > >> [ERROR]
> > >> > >> src\main\java\org\apache\commons\configuration2\
> > >> > >> AbstractYAMLBasedConfiguration.java[0]
> > >> > >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> > >> > >> [ERROR]
> > >> > >> src\main\java\org\apache\commons\configuration2\builder\fluent\
> > >> > >> INIBuilderParameters.java[0]
> > >> > >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> > >> > >> [ERROR]
> > >> > >> src\main\java\org\apache\commons\configuration2\builder\
> > >> > >> INIBuilderParametersImpl.java[0]
> > >> > >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> > >> > >> [ERROR]
> > >> > >> src\main\java\org\apache\commons\configuration2\builder\