[GitHub] commons-rng pull request #6: RNG-37 make KN table long

Github user cur4so closed the pull request at: https://github.com/apache/commons-rng/pull/6 --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [beanutils] Toward 2.0.0

On 28 December 2017 at 22:50, Stephen Colebourne wrote: > On 28 December 2017 at 19:49, Gary Gregory wrote: >> Hi All, >> >> - BeanUtils now has a new package o.a.c.beanutils2. >> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),

Re: [beanutils] Toward 2.0.0

On 28 December 2017 at 19:49, Gary Gregory wrote: > Hi All, > > - BeanUtils now has a new package o.a.c.beanutils2. > - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), > which caused the above. > > What more do we want before releasing 2.0.0? > >

Re: [beanutils] Toward 2.0.0

On 28 December 2017 at 22:02, Dave Brosius wrote: > beanutils 3 exposed 'FastHashMap' which was a commons collections 3 data > structure in it's own interface. That went away in commons collections 4, > and so i modified the beanutils 4 interface to use

Re: [beanutils] Toward 2.0.0

beanutils 3 exposed 'FastHashMap' which was a commons collections 3 data structure in it's own interface. That went away in commons collections 4, and so i modified the beanutils 4 interface to use ConcurrentHashMaps. Thus the need for a package rename. On 12/28/2017 04:56 PM, sebb wrote:

Re: [beanutils] Toward 2.0.0

On 28 December 2017 at 19:49, Gary Gregory wrote: > Hi All, > > - BeanUtils now has a new package o.a.c.beanutils2. > - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), > which caused the above. > > What more do we want before releasing 2.0.0? > >

Re: Questions regarding improving the Apache Commons release process.

> On Dec 28, 2017, at 4:05 AM, Hervé BOUTEMY wrote: > > Hi Rob, > > one additional point: currently, for Maven itself, instead of adding new > Maven-specific ReleasePhase(s) to the default configuration, or configure > them in > our parent pom (I'm not sure

[beanutils] Toward 2.0.0

Hi All, - BeanUtils now has a new package o.a.c.beanutils2. - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), which caused the above. What more do we want before releasing 2.0.0? Updating from BU 1.x to 2.x should be "simple" for now: Just update your imports. Thoughts?

Re: [beanutils] Missing entries in changes.xml since 1.9.3

On Wed, Dec 27, 2017 at 11:39 AM, Gary Gregory wrote: > Hi All, > > Whomever committed since 1.9.3, please update the changes.xml file to > reflect changes that have JIRA issues like BEANUTILS-500. > Done. Gary > > Thank you, > Gary >

Re: [beanutils] Update to Java 7

On Wed, Dec 27, 2017 at 12:00 PM, Gary Gregory wrote: > FYI: > > I plan on updating [beanutils] to Java 7. This should make the code base > slightly more appealing. > Done. Gary > > Gary >

Re: Error in commons collections4 Caused by java util ConcurrentModificationException

Just like it says on the Javadoc: https://docs.oracle.com/javase/7/docs/api/java/util/ConcurrentModificationException.html One piece of code must be reading while another is writing on the collection. Gary On Thu, Dec 28, 2017 at 11:21 AM, durairaj t wrote: > Hi All, >

Error in commons collections4 Caused by java util ConcurrentModificationException

Hi All, I'm using comm.coll4 with JBOSS EAP sever 7.0 runtime and getting the below error, I don't know whats going on, Any help? Error Message: __ Caused by: java.util.ConcurrentModificationException at org.apache.commons.collections4.map.AbstractLinkedMap$LinkIt

Re: [VOTE] Release Commons JCS 2.2.1 based on RC3

Thanks Romain for pushing this release so hard. I have yank JCS from my project and replaced with another impl. Thanks anyway. Le dim. 24 déc. 2017 à 10:23, Romain Manni-Bucau a écrit : > My own +1 (dont think the issues we found are worth blocking a release but > would

Re: Questions regarding improving the Apache Commons release process.

Hi Rob, one additional point: currently, for Maven itself, instead of adding new Maven-specific ReleasePhase(s) to the default configuration, or configure them in our parent pom (I'm not sure documentation on how to do that is available: I could not find it), we chose first to create a