[math] testing issue with Kolmogorov-Smirnov bootstrap methods
Hi all, It seems the new bootstrap method introduced in fbc327e9 in order to solve MATH-1246 creates some random test failures. The reason is that an EnumeratedRealDistribution instance is created without a random generator (there are no way to pass a random generator in the bootstrap method). This EnumeratedRealDistribution will therefore create a Well19937c generator with the default constructor, which uses time to seed the generator. Depending on the way this generator is seeded, the testBootstrapSmallSamplesWithTies test fails quite often. Would it be possible to pass a random generator somewhere and to configure it with a fixed seed for the Junit tests? best regards, Luc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] testing issue with Kolmogorov-Smirnov bootstrap methods
On Tue, 24 Nov 2015 11:40:23 +0100, Luc Maisonobe wrote: Hi all, It seems the new bootstrap method introduced in fbc327e9 in order to solve MATH-1246 creates some random test failures. The reason is that an EnumeratedRealDistribution instance is created without a random generator (there are no way to pass a random generator in the bootstrap method). This EnumeratedRealDistribution will therefore create a Well19937c generator with the default constructor, which uses time to seed the generator. Depending on the way this generator is seeded, the testBootstrapSmallSamplesWithTies test fails quite often. If it fails often, doesn't it indicate a problem with the code or a wrong assumption about the test? Best, Gilles Would it be possible to pass a random generator somewhere and to configure it with a fixed seed for the Junit tests? best regards, Luc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] testing issue with Kolmogorov-Smirnov bootstrap methods
> On Nov 24, 2015, at 3:50 AM, Gilles wrote: > >> On Tue, 24 Nov 2015 11:40:23 +0100, Luc Maisonobe wrote: >> Hi all, >> >> It seems the new bootstrap method introduced in fbc327e9 in order >> to solve MATH-1246 creates some random test failures. >> >> The reason is that an EnumeratedRealDistribution instance is >> created without a random generator (there are no way to pass >> a random generator in the bootstrap method). This >> EnumeratedRealDistribution will therefore create a Well19937c >> generator with the default constructor, which uses time to seed >> the generator. Depending on the way this generator is seeded, >> the testBootstrapSmallSamplesWithTies test fails quite often. > > If it fails often, doesn't it indicate a problem with the code or > a wrong assumption about the test? > Possibly, but not likely. The bootstrap estimates are not very stable. The same instability is evident in the R tests of ks.boot. I will find a way to supply a fixed seed. I am still working on the full resolution of MAtH-1246 which requires adding jitter. The bootstrap is an optional method never activated by the default implementation. I am close to having the jitter code ready to commit. Phil > Best, > Gilles > >> Would it be possible to pass a random generator somewhere and >> to configure it with a fixed seed for the Junit tests? >> >> best regards, >> Luc > > > - > 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
[ANNOUNCEMENT] Apache Commons Validator 1.5.0 released!
The Apache Commons Team is pleased to announce the release of Apache Commons Validator 1.5.0 Apache Commons Validator provides the building blocks for both client side validation and server side data validation. It may be used standalone or with a framework like Struts. 1.5.0 is fully binary compatible to the last release. No client code changes are required to migrate from version 1.4.x to 1.5.0. The minimum required JDK version for this release is 1.6. However note that the Javascript code has been dropped, see https://issues.apache.org/jira/browse/VALIDATOR-371 Source and binary distributions are available for download from the Apache Commons download site: http://commons.apache.org/proper/commons-validator/download_validator.cgi When downloading, please verify signatures using the KEYS file available at the above location when downloading the release. Alternatively the release can be pulled via maven: commons-validator commons-validator 1.5.0 Full details of all the changes in 1.5.0 can be found in the changelog: http://commons.apache.org/proper/commons-validator/changes-report.html For complete information on Commons Validator, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Validator website: http://commons.apache.org/proper/commons-validator/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] testing issue with Kolmogorov-Smirnov bootstrap methods
On 11/24/15 3:40 AM, Luc Maisonobe wrote: > Hi all, > > It seems the new bootstrap method introduced in fbc327e9 in order > to solve MATH-1246 creates some random test failures. > > The reason is that an EnumeratedRealDistribution instance is > created without a random generator (there are no way to pass > a random generator in the bootstrap method). This > EnumeratedRealDistribution will therefore create a Well19937c > generator with the default constructor, which uses time to seed > the generator. Depending on the way this generator is seeded, > the testBootstrapSmallSamplesWithTies test fails quite often. > > Would it be possible to pass a random generator somewhere and > to configure it with a fixed seed for the Junit tests? I just changed the code (3_X: 3cfafe051 / master: 5f9cfa6eb) to have the bootstrap method use the rng configured for the class. The tests supply a fixed seed generator to the KS instance, but that was not being passed by the bootstrap to the EnumeratedDistribution. Sorry I missed that. Phil > > best regards, > Luc > > - > 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: [math] testing issue with Kolmogorov-Smirnov bootstrap methods
Le 24/11/2015 14:34, Phil Steitz a écrit : > On 11/24/15 3:40 AM, Luc Maisonobe wrote: >> Hi all, >> >> It seems the new bootstrap method introduced in fbc327e9 in order >> to solve MATH-1246 creates some random test failures. >> >> The reason is that an EnumeratedRealDistribution instance is >> created without a random generator (there are no way to pass >> a random generator in the bootstrap method). This >> EnumeratedRealDistribution will therefore create a Well19937c >> generator with the default constructor, which uses time to seed >> the generator. Depending on the way this generator is seeded, >> the testBootstrapSmallSamplesWithTies test fails quite often. >> >> Would it be possible to pass a random generator somewhere and >> to configure it with a fixed seed for the Junit tests? > > I just changed the code (3_X: 3cfafe051 / master: 5f9cfa6eb) to have > the bootstrap method use the rng configured for the class. The > tests supply a fixed seed generator to the KS instance, but that was > not being passed by the bootstrap to the EnumeratedDistribution. > Sorry I missed that. Never mind. Thanks a lot for this fast fix. best regards, Luc > > Phil >> >> best regards, >> Luc >> >> - >> 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
[math] additions to MathArrays
I need the following methods to complete the fix for MATH-1246. I can add them as private methods to the KS class; but they seem generally useful, so I propose adding them to MathArrays. Any objections? /** * Concatenates two arrays. * * @param x first array * @param y second array * @return a new array consisting of the entries of x followed by the entries of y * @throws NullPointerException if either x or y is null */ public static double[] concat(double[] x, double[] y) /** * Returns an array consisting of the unique values in {@code data}. * The return array is sorted in descending order. * * @param data * @return descending list of values included in the input array */ public static double[] values(double[] data) /** * Adds random jitter to {@code data} using deviates sampled from {@code dist}. * * Note that jitter is applied in-place - i.e., the array * values are overwritten with the result of applying jitter. * * @param data input/output data array * @param dist probability distribution to sample for jitter values * @throws NullPointerException if either of the parameters is null */ public static void jitter(double[] data, RealDistribution dist) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] additions to MathArrays
On 24 November 2015 at 13:52, Phil Steitz wrote: > I need the following methods to complete the fix for MATH-1246. I > can add them as private methods to the KS class; but they seem > generally useful, so I propose adding them to MathArrays. Any > objections? > > /** > * Concatenates two arrays. > * > * @param x first array > * @param y second array > * @return a new array consisting of the entries of x followed by > the entries of y > * @throws NullPointerException if either x or y is null > */ > public static double[] concat(double[] x, double[] y) Could perhaps take a list? > /** > * Returns an array consisting of the unique values in {@code data}. > * The return array is sorted in descending order. > * > * @param data > * @return descending list of values included in the input array > */ > public static double[] values(double[] data) The name gives no hint that the output is unique. IMO it should be renamed to reflect that. [The sort order seems to be a byproduct of the algorithm used, so is not particularly relevant to the name] > /** > * Adds random jitter to {@code data} using deviates sampled from > {@code dist}. > * > * Note that jitter is applied in-place - i.e., the array > * values are overwritten with the result of applying jitter. > * > * @param data input/output data array > * @param dist probability distribution to sample for jitter values > * @throws NullPointerException if either of the parameters is null > */ > public static void jitter(double[] data, RealDistribution dist) > > > - > 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: [math] additions to MathArrays
On Tue, 24 Nov 2015 06:52:04 -0700, Phil Steitz wrote: I need the following methods to complete the fix for MATH-1246. I can add them as private methods to the KS class; but they seem generally useful, so I propose adding them to MathArrays. Any objections? /** * Concatenates two arrays. * * @param x first array * @param y second array * @return a new array consisting of the entries of x followed by the entries of y * @throws NullPointerException if either x or y is null */ public static double[] concat(double[] x, double[] y) I'd propose public static double[] cat(double[] ... arrays) /** * Returns an array consisting of the unique values in {@code data}. * The return array is sorted in descending order. * * @param data * @return descending list of values included in the input array */ public static double[] values(double[] data) I'd suggest public static double[] uniq(double[] data) /** * Adds random jitter to {@code data} using deviates sampled from {@code dist}. * * Note that jitter is applied in-place - i.e., the array * values are overwritten with the result of applying jitter. * * @param data input/output data array * @param dist probability distribution to sample for jitter values * @throws NullPointerException if either of the parameters is null */ public static void jitter(double[] data, RealDistribution dist) IMO, this method should be part of the new API proposed in https://issues.apache.org/jira/browse/MATH-1158 Like so: /** {@inheritDoc} */ public RealDistribution.Sampler createSampler(final RandomGenerator rng) { return new RealDistribution.Sampler() { public double next() { /* ... */ } public double[] next(int sampleSize) { /* ... */ } /** * @param data input/output data array. * @param dist probability distribution to sample for jitter values * @throws NullPointerException if data array is null. */ public void jitter(double[] data) { final int len = data.length; final double[] jit = next(len); for (int i = 0; i < len; i++) { data[i] += jit[i]; } } }; } Advantages: * Simpler to use (half as many arguments). :-) * Utility is defined where the base functionality is defined. * Avoid adding to the overcrowded MathArrays utility class. * Avoid dependency to another package (will help with modularization). Drawbacks from usage POV * None (?) Drawbacks from implementation POV * Cannot be done before we agree to go forward with the aforementioned issue. In the meantime, I suggest to implement it as a "private" method. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1716090 - in /commons/proper/collections/trunk: .travis.yml README.md pom.xml
Nice! 2015-11-24 10:25 GMT+01:00 : > Author: tn > Date: Tue Nov 24 09:25:40 2015 > New Revision: 1716090 > > URL: http://svn.apache.org/viewvc?rev=1716090&view=rev > Log: > Add travis configuration for jacoco and coveralls. Add badges to Readme.md. > > Modified: > commons/proper/collections/trunk/.travis.yml > commons/proper/collections/trunk/README.md > commons/proper/collections/trunk/pom.xml > > Modified: commons/proper/collections/trunk/.travis.yml > URL: > http://svn.apache.org/viewvc/commons/proper/collections/trunk/.travis.yml?rev=1716090&r1=1716089&r2=1716090&view=diff > > == > --- commons/proper/collections/trunk/.travis.yml (original) > +++ commons/proper/collections/trunk/.travis.yml Tue Nov 24 09:25:40 2015 > @@ -5,3 +5,6 @@ jdk: >- openjdk6 >- openjdk7 >- oraclejdk8 > + > +after_success: > + - mvn clean test jacoco:report coveralls:report > > Modified: commons/proper/collections/trunk/README.md > URL: > http://svn.apache.org/viewvc/commons/proper/collections/trunk/README.md?rev=1716090&r1=1716089&r2=1716090&view=diff > > == > --- commons/proper/collections/trunk/README.md (original) > +++ commons/proper/collections/trunk/README.md Tue Nov 24 09:25:40 2015 > @@ -43,6 +43,11 @@ > Apache Commons Collections > === > > +[![Build Status]( > https://travis-ci.org/apache/commons-collections.svg?branch=master)](https://travis-ci.org/apache/commons-collections > ) > +[![Coverage Status]( > https://coveralls.io/repos/apache/commons-collections/badge.svg?branch=master)](https://coveralls.io/r/apache/commons-collections > ) > +[![Maven Central]( > https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-collections4/badge.svg)](https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-collections4/ > ) > +[![License]( > http://img.shields.io/:license-apache-blue.svg)](http://www.apache.org/licenses/LICENSE-2.0.html > ) > + > The Apache Commons Collections package contains types that extend and > augment the Java Collections Framework. > > Documentation > > Modified: commons/proper/collections/trunk/pom.xml > URL: > http://svn.apache.org/viewvc/commons/proper/collections/trunk/pom.xml?rev=1716090&r1=1716089&r2=1716090&view=diff > > == > --- commons/proper/collections/trunk/pom.xml (original) > +++ commons/proper/collections/trunk/pom.xml Tue Nov 24 09:25:40 2015 > @@ -690,6 +690,38 @@ > > > > + > + > + travis > + > + > + env.TRAVIS > + true > + > + > + > + > + > +org.jacoco > +jacoco-maven-plugin > +${commons.jacoco.version} > + > + > +prepare-agent > + > + prepare-agent > + > + > + > + > + > +org.eluder.coveralls > +coveralls-maven-plugin > +3.1.0 > + > + > + > + > > > > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: svn commit: r1716090 - in /commons/proper/collections/trunk: .travis.yml README.md pom.xml
Actually, it does not work yet, as I can not enable commons-collections on travis. I already sent an email to them, but did not get an answer yet. How did you manage to do it for commons-lang? Thomas On Tue, Nov 24, 2015 at 5:36 PM, Benedikt Ritter wrote: > Nice! > > 2015-11-24 10:25 GMT+01:00 : > > > Author: tn > > Date: Tue Nov 24 09:25:40 2015 > > New Revision: 1716090 > > > > URL: http://svn.apache.org/viewvc?rev=1716090&view=rev > > Log: > > Add travis configuration for jacoco and coveralls. Add badges to > Readme.md. > > > > Modified: > > commons/proper/collections/trunk/.travis.yml > > commons/proper/collections/trunk/README.md > > commons/proper/collections/trunk/pom.xml > > > > Modified: commons/proper/collections/trunk/.travis.yml > > URL: > > > http://svn.apache.org/viewvc/commons/proper/collections/trunk/.travis.yml?rev=1716090&r1=1716089&r2=1716090&view=diff > > > > > == > > --- commons/proper/collections/trunk/.travis.yml (original) > > +++ commons/proper/collections/trunk/.travis.yml Tue Nov 24 09:25:40 2015 > > @@ -5,3 +5,6 @@ jdk: > >- openjdk6 > >- openjdk7 > >- oraclejdk8 > > + > > +after_success: > > + - mvn clean test jacoco:report coveralls:report > > > > Modified: commons/proper/collections/trunk/README.md > > URL: > > > http://svn.apache.org/viewvc/commons/proper/collections/trunk/README.md?rev=1716090&r1=1716089&r2=1716090&view=diff > > > > > == > > --- commons/proper/collections/trunk/README.md (original) > > +++ commons/proper/collections/trunk/README.md Tue Nov 24 09:25:40 2015 > > @@ -43,6 +43,11 @@ > > Apache Commons Collections > > === > > > > +[![Build Status]( > > > https://travis-ci.org/apache/commons-collections.svg?branch=master)](https://travis-ci.org/apache/commons-collections > > ) > > +[![Coverage Status]( > > > https://coveralls.io/repos/apache/commons-collections/badge.svg?branch=master)](https://coveralls.io/r/apache/commons-collections > > ) > > +[![Maven Central]( > > > https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-collections4/badge.svg)](https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-collections4/ > > ) > > +[![License]( > > > http://img.shields.io/:license-apache-blue.svg)](http://www.apache.org/licenses/LICENSE-2.0.html > > ) > > + > > The Apache Commons Collections package contains types that extend and > > augment the Java Collections Framework. > > > > Documentation > > > > Modified: commons/proper/collections/trunk/pom.xml > > URL: > > > http://svn.apache.org/viewvc/commons/proper/collections/trunk/pom.xml?rev=1716090&r1=1716089&r2=1716090&view=diff > > > > > == > > --- commons/proper/collections/trunk/pom.xml (original) > > +++ commons/proper/collections/trunk/pom.xml Tue Nov 24 09:25:40 2015 > > @@ -690,6 +690,38 @@ > > > > > > > > + > > + > > + travis > > + > > + > > + env.TRAVIS > > + true > > + > > + > > + > > + > > + > > +org.jacoco > > +jacoco-maven-plugin > > +${commons.jacoco.version} > > + > > + > > +prepare-agent > > + > > + prepare-agent > > + > > + > > + > > + > > + > > +org.eluder.coveralls > > +coveralls-maven-plugin > > +3.1.0 > > + > > + > > + > > + > > > > > > > > > > > > > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter >
Re: [math] additions to MathArrays
On 11/24/15 7:11 AM, sebb wrote: > On 24 November 2015 at 13:52, Phil Steitz wrote: >> I need the following methods to complete the fix for MATH-1246. I >> can add them as private methods to the KS class; but they seem >> generally useful, so I propose adding them to MathArrays. Any >> objections? >> >> /** >> * Concatenates two arrays. >> * >> * @param x first array >> * @param y second array >> * @return a new array consisting of the entries of x followed by >> the entries of y >> * @throws NullPointerException if either x or y is null >> */ >> public static double[] concat(double[] x, double[] y) > Could perhaps take a list? You mean what Gilles suggested? Phil > >> /** >> * Returns an array consisting of the unique values in {@code data}. >> * The return array is sorted in descending order. >> * >> * @param data >> * @return descending list of values included in the input array >> */ >> public static double[] values(double[] data) > The name gives no hint that the output is unique. > IMO it should be renamed to reflect that. > > [The sort order seems to be a byproduct of the algorithm used, so is > not particularly relevant to the name] > >> /** >> * Adds random jitter to {@code data} using deviates sampled from >> {@code dist}. >> * >> * Note that jitter is applied in-place - i.e., the array >> * values are overwritten with the result of applying jitter. >> * >> * @param data input/output data array >> * @param dist probability distribution to sample for jitter values >> * @throws NullPointerException if either of the parameters is null >> */ >> public static void jitter(double[] data, RealDistribution dist) >> >> >> - >> 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: svn commit: r1716090 - in /commons/proper/collections/trunk: .travis.yml README.md pom.xml
You have to file an issue for infra, asking them to activate travis and coveralls for the github mirror. 2015-11-24 17:52 GMT+01:00 Thomas Neidhart : > Actually, it does not work yet, as I can not enable commons-collections on > travis. > > I already sent an email to them, but did not get an answer yet. How did you > manage to do it for commons-lang? > > Thomas > > On Tue, Nov 24, 2015 at 5:36 PM, Benedikt Ritter > wrote: > > > Nice! > > > > 2015-11-24 10:25 GMT+01:00 : > > > > > Author: tn > > > Date: Tue Nov 24 09:25:40 2015 > > > New Revision: 1716090 > > > > > > URL: http://svn.apache.org/viewvc?rev=1716090&view=rev > > > Log: > > > Add travis configuration for jacoco and coveralls. Add badges to > > Readme.md. > > > > > > Modified: > > > commons/proper/collections/trunk/.travis.yml > > > commons/proper/collections/trunk/README.md > > > commons/proper/collections/trunk/pom.xml > > > > > > Modified: commons/proper/collections/trunk/.travis.yml > > > URL: > > > > > > http://svn.apache.org/viewvc/commons/proper/collections/trunk/.travis.yml?rev=1716090&r1=1716089&r2=1716090&view=diff > > > > > > > > > == > > > --- commons/proper/collections/trunk/.travis.yml (original) > > > +++ commons/proper/collections/trunk/.travis.yml Tue Nov 24 09:25:40 > 2015 > > > @@ -5,3 +5,6 @@ jdk: > > >- openjdk6 > > >- openjdk7 > > >- oraclejdk8 > > > + > > > +after_success: > > > + - mvn clean test jacoco:report coveralls:report > > > > > > Modified: commons/proper/collections/trunk/README.md > > > URL: > > > > > > http://svn.apache.org/viewvc/commons/proper/collections/trunk/README.md?rev=1716090&r1=1716089&r2=1716090&view=diff > > > > > > > > > == > > > --- commons/proper/collections/trunk/README.md (original) > > > +++ commons/proper/collections/trunk/README.md Tue Nov 24 09:25:40 2015 > > > @@ -43,6 +43,11 @@ > > > Apache Commons Collections > > > === > > > > > > +[![Build Status]( > > > > > > https://travis-ci.org/apache/commons-collections.svg?branch=master)](https://travis-ci.org/apache/commons-collections > > > ) > > > +[![Coverage Status]( > > > > > > https://coveralls.io/repos/apache/commons-collections/badge.svg?branch=master)](https://coveralls.io/r/apache/commons-collections > > > ) > > > +[![Maven Central]( > > > > > > https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-collections4/badge.svg)](https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-collections4/ > > > ) > > > +[![License]( > > > > > > http://img.shields.io/:license-apache-blue.svg)](http://www.apache.org/licenses/LICENSE-2.0.html > > > ) > > > + > > > The Apache Commons Collections package contains types that extend and > > > augment the Java Collections Framework. > > > > > > Documentation > > > > > > Modified: commons/proper/collections/trunk/pom.xml > > > URL: > > > > > > http://svn.apache.org/viewvc/commons/proper/collections/trunk/pom.xml?rev=1716090&r1=1716089&r2=1716090&view=diff > > > > > > > > > == > > > --- commons/proper/collections/trunk/pom.xml (original) > > > +++ commons/proper/collections/trunk/pom.xml Tue Nov 24 09:25:40 2015 > > > @@ -690,6 +690,38 @@ > > > > > > > > > > > > + > > > + > > > + travis > > > + > > > + > > > + env.TRAVIS > > > + true > > > + > > > + > > > + > > > + > > > + > > > +org.jacoco > > > +jacoco-maven-plugin > > > +${commons.jacoco.version} > > > + > > > + > > > +prepare-agent > > > + > > > + prepare-agent > > > + > > > + > > > + > > > + > > > + > > > +org.eluder.coveralls > > > +coveralls-maven-plugin > > > +3.1.0 > > > + > > > + > > > + > > > + > > > > > > > > > > > > > > > > > > > > > > > > -- > > http://people.apache.org/~britter/ > > http://www.systemoutprintln.de/ > > http://twitter.com/BenediktRitter > > http://github.com/britter > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [math] additions to MathArrays
On 11/24/15 7:28 AM, Gilles wrote: > On Tue, 24 Nov 2015 06:52:04 -0700, Phil Steitz wrote: >> I need the following methods to complete the fix for MATH-1246. I >> can add them as private methods to the KS class; but they seem >> generally useful, so I propose adding them to MathArrays. Any >> objections? >> >> /** >> * Concatenates two arrays. >> * >> * @param x first array >> * @param y second array >> * @return a new array consisting of the entries of x followed by >> the entries of y >> * @throws NullPointerException if either x or y is null >> */ >> public static double[] concat(double[] x, double[] y) > > I'd propose > public static double[] cat(double[] ... arrays) +1 for the varArgs. I am not sure about the name though, since unix cat has a slightly different meaning. Maybe best to spell out completely "concatentate" > >> >> /** >> * Returns an array consisting of the unique values in {@code >> data}. >> * The return array is sorted in descending order. >> * >> * @param data >> * @return descending list of values included in the input array >> */ >> public static double[] values(double[] data) > > I'd suggest > public static double[] uniq(double[] data) +1, maybe spell out unique though. > >> >> /** >> * Adds random jitter to {@code data} using deviates sampled from >> {@code dist}. >> * >> * Note that jitter is applied in-place - i.e., the array >> * values are overwritten with the result of applying jitter. >> * >> * @param data input/output data array >> * @param dist probability distribution to sample for jitter values >> * @throws NullPointerException if either of the parameters is null >> */ >> public static void jitter(double[] data, RealDistribution dist) > > IMO, this method should be part of the new API proposed in > > https://issues.apache.org/jira/browse/MATH-1158 > > Like so: > > /** {@inheritDoc} */ > public RealDistribution.Sampler createSampler(final > RandomGenerator rng) { > return new RealDistribution.Sampler() { > public double next() { /* ... */ } > public double[] next(int sampleSize) { /* ... */ } > > /** > * @param data input/output data array. > * @param dist probability distribution to sample for > jitter values > * @throws NullPointerException if data array is null. > */ > public void jitter(double[] data) { > final int len = data.length; > final double[] jit = next(len); > for (int i = 0; i < len; i++) { > data[i] += jit[i]; > } > } > }; > } > > Advantages: > * Simpler to use (half as many arguments). :-) I guess beauty is in the eye of the beholder. Simple static array-based method looks simpler to me. > * Utility is defined where the base functionality is defined. > * Avoid adding to the overcrowded MathArrays utility class. But it is an array utility. > * Avoid dependency to another package (will help with > modularization). > > Drawbacks from usage POV > * None (?) > > Drawbacks from implementation POV > * Cannot be done before we agree to go forward with the > aforementioned issue. > > In the meantime, I suggest to implement it as a "private" method. I will add it as private. I don't like the setup above. If we do end up pulling sampling out of the distributions, I would have the method take a "sampler." > > > Regards, > Gilles > > > - > 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: [math] additions to MathArrays
Notes inline... On 11/24/2015 08:28 AM, Gilles wrote: On Tue, 24 Nov 2015 06:52:04 -0700, Phil Steitz wrote: I need the following methods to complete the fix for MATH-1246. I can add them as private methods to the KS class; but they seem generally useful, so I propose adding them to MathArrays. Any objections? /** * Concatenates two arrays. * * @param x first array * @param y second array * @return a new array consisting of the entries of x followed by the entries of y * @throws NullPointerException if either x or y is null */ public static double[] concat(double[] x, double[] y) I'd propose public static double[] cat(double[] ... arrays) Java 8 has an addAll method that is similar to the cat method: http://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html#addAll-int-java.util.Collection- Perhaps use a similar naming convention... The cat API is also does what Javascript's splice method does, so that might be a better name. http://www.w3schools.com/jsref/jsref_splice.asp /** * Returns an array consisting of the unique values in {@code data}. * The return array is sorted in descending order. * * @param data * @return descending list of values included in the input array */ public static double[] values(double[] data) I'd suggest public static double[] uniq(double[] data) Just a note - Java 8 Streams make the implementation fairly short: |Integer[]array =newInteger[]{5,10,20,58,10};Stream.of(array).distinct().forEach(i ->System.out.print(" "+i)); 5, 10, 20, 58 //Printed | Cheers, - Ole /** * Adds random jitter to {@code data} using deviates sampled from {@code dist}. * * Note that jitter is applied in-place - i.e., the array * values are overwritten with the result of applying jitter. * * @param data input/output data array * @param dist probability distribution to sample for jitter values * @throws NullPointerException if either of the parameters is null */ public static void jitter(double[] data, RealDistribution dist) IMO, this method should be part of the new API proposed in https://issues.apache.org/jira/browse/MATH-1158 Like so: /** {@inheritDoc} */ public RealDistribution.Sampler createSampler(final RandomGenerator rng) { return new RealDistribution.Sampler() { public double next() { /* ... */ } public double[] next(int sampleSize) { /* ... */ } /** * @param data input/output data array. * @param dist probability distribution to sample for jitter values * @throws NullPointerException if data array is null. */ public void jitter(double[] data) { final int len = data.length; final double[] jit = next(len); for (int i = 0; i < len; i++) { data[i] += jit[i]; } } }; } Advantages: * Simpler to use (half as many arguments). :-) * Utility is defined where the base functionality is defined. * Avoid adding to the overcrowded MathArrays utility class. * Avoid dependency to another package (will help with modularization). Drawbacks from usage POV * None (?) Drawbacks from implementation POV * Cannot be done before we agree to go forward with the aforementioned issue. In the meantime, I suggest to implement it as a "private" method. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] additions to MathArrays
On 24 November 2015 at 18:01, Phil Steitz wrote: > On 11/24/15 7:11 AM, sebb wrote: >> On 24 November 2015 at 13:52, Phil Steitz wrote: >>> I need the following methods to complete the fix for MATH-1246. I >>> can add them as private methods to the KS class; but they seem >>> generally useful, so I propose adding them to MathArrays. Any >>> objections? >>> >>> /** >>> * Concatenates two arrays. >>> * >>> * @param x first array >>> * @param y second array >>> * @return a new array consisting of the entries of x followed by >>> the entries of y >>> * @throws NullPointerException if either x or y is null >>> */ >>> public static double[] concat(double[] x, double[] y) >> Could perhaps take a list? > > You mean what Gilles suggested? Yes, not just a pair of arrays. > Phil >> >>> /** >>> * Returns an array consisting of the unique values in {@code data}. >>> * The return array is sorted in descending order. >>> * >>> * @param data >>> * @return descending list of values included in the input array >>> */ >>> public static double[] values(double[] data) >> The name gives no hint that the output is unique. >> IMO it should be renamed to reflect that. >> >> [The sort order seems to be a byproduct of the algorithm used, so is >> not particularly relevant to the name] >> >>> /** >>> * Adds random jitter to {@code data} using deviates sampled from >>> {@code dist}. >>> * >>> * Note that jitter is applied in-place - i.e., the array >>> * values are overwritten with the result of applying jitter. >>> * >>> * @param data input/output data array >>> * @param dist probability distribution to sample for jitter values >>> * @throws NullPointerException if either of the parameters is null >>> */ >>> public static void jitter(double[] data, RealDistribution dist) >>> >>> >>> - >>> 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: svn commit: r11284 - in /release/commons: beanutils/ betwixt/ chain/ cli/ collections/ configuration/ csv/ daemon/ dbutils/ digester/ discovery/ el/ email/ fileupload/ jcs/ jelly/ jexl/ jxpath/ la
+1 2015-11-24 11:22 GMT+01:00 : > Author: sebb > Date: Tue Nov 24 10:22:18 2015 > New Revision: 11284 > > Log: > Drop unnecessary headers > They are also misleading since the header does not relate to the listing > > Modified: > release/commons/beanutils/HEADER.html > release/commons/betwixt/HEADER.html > release/commons/chain/HEADER.html > release/commons/cli/HEADER.html > release/commons/collections/HEADER.html > release/commons/configuration/HEADER.html > release/commons/csv/HEADER.html > release/commons/daemon/HEADER.html > release/commons/dbutils/HEADER.html > release/commons/digester/HEADER.html > release/commons/discovery/HEADER.html > release/commons/el/HEADER.html > release/commons/email/HEADER.html > release/commons/fileupload/HEADER.html > release/commons/jcs/HEADER.html > release/commons/jelly/HEADER.html > release/commons/jexl/HEADER.html > release/commons/jxpath/HEADER.html > release/commons/lang/HEADER.html > release/commons/launcher/HEADER.html > release/commons/logging/HEADER.html > release/commons/math/HEADER.html > release/commons/modeler/HEADER.html > release/commons/pool/HEADER.html > release/commons/primitives/HEADER.html > release/commons/proxy/HEADER.html > release/commons/scxml/HEADER.html > release/commons/validator/HEADER.html > release/commons/vfs/HEADER.html > release/commons/weaver/HEADER.html > > Modified: release/commons/beanutils/HEADER.html > > == > --- release/commons/beanutils/HEADER.html (original) > +++ release/commons/beanutils/HEADER.html Tue Nov 24 10:22:18 2015 > @@ -1,5 +1,3 @@ > -Index of /dist/commons > - > Apache Commons Project Distributions > > The most recent source and binary releases for the Apache Commons > project are available from this directory listing. For older releases, > please use the http://archive.apache.org/dist/commons/";>archives. > > > Modified: release/commons/betwixt/HEADER.html > > == > --- release/commons/betwixt/HEADER.html (original) > +++ release/commons/betwixt/HEADER.html Tue Nov 24 10:22:18 2015 > @@ -1,5 +1,3 @@ > -Index of /dist/commons > - > Apache Commons Project Distributions > > The most recent source and binary releases for the Apache Commons > project are available from this directory listing. For older releases, > please use the http://archive.apache.org/dist/commons/";>archives. > > > Modified: release/commons/chain/HEADER.html > > == > --- release/commons/chain/HEADER.html (original) > +++ release/commons/chain/HEADER.html Tue Nov 24 10:22:18 2015 > @@ -1,5 +1,3 @@ > -Index of /dist/commons > - > Apache Commons Project Distributions > > The most recent source and binary releases for the Apache Commons > project are available from this directory listing. For older releases, > please use the http://archive.apache.org/dist/commons/";>archives. > > > Modified: release/commons/cli/HEADER.html > > == > --- release/commons/cli/HEADER.html (original) > +++ release/commons/cli/HEADER.html Tue Nov 24 10:22:18 2015 > @@ -1,5 +1,3 @@ > -Index of /dist/commons > - > Apache Commons Project Distributions > > The most recent source and binary releases for the Apache Commons > project are available from this directory listing. For older releases, > please use the http://archive.apache.org/dist/commons/";>archives. > > > Modified: release/commons/collections/HEADER.html > > == > --- release/commons/collections/HEADER.html (original) > +++ release/commons/collections/HEADER.html Tue Nov 24 10:22:18 2015 > @@ -1,5 +1,3 @@ > -Index of /dist/commons > - > Apache Commons Project Distributions > > The most recent source and binary releases for the Apache Commons > project are available from this directory listing. For older releases, > please use the http://archive.apache.org/dist/commons/";>archives. > > > Modified: release/commons/configuration/HEADER.html > > == > --- release/commons/configuration/HEADER.html (original) > +++ release/commons/configuration/HEADER.html Tue Nov 24 10:22:18 2015 > @@ -1,5 +1,3 @@ > -Index of /dist/commons > - > Apache Commons Project Distributions > > The most recent source and binary releases for the Apache Commons > project are available from this directory listing. For older releases, > please use the http://archive.apache.org/dist/commons/";>archives. > > > Modified: release/commons/csv/HEADER.html > > == > --- release/commons/csv/HEADER.html (orig
Re: [math] additions to MathArrays
On Tue, 24 Nov 2015 11:08:33 -0700, Phil Steitz wrote: On 11/24/15 7:28 AM, Gilles wrote: On Tue, 24 Nov 2015 06:52:04 -0700, Phil Steitz wrote: I need the following methods to complete the fix for MATH-1246. I can add them as private methods to the KS class; but they seem generally useful, so I propose adding them to MathArrays. Any objections? /** * Concatenates two arrays. * * @param x first array * @param y second array * @return a new array consisting of the entries of x followed by the entries of y * @throws NullPointerException if either x or y is null */ public static double[] concat(double[] x, double[] y) I'd propose public static double[] cat(double[] ... arrays) +1 for the varArgs. I am not sure about the name though, since unix cat has a slightly different meaning. Maybe best to spell out completely "concatentate" -1 ;-) But OK for "concatenate". /** * Returns an array consisting of the unique values in {@code data}. * The return array is sorted in descending order. * * @param data * @return descending list of values included in the input array */ public static double[] values(double[] data) I'd suggest public static double[] uniq(double[] data) +1, maybe spell out unique though. Yes, we should be more Java-like than Unix-like. /** * Adds random jitter to {@code data} using deviates sampled from {@code dist}. * * Note that jitter is applied in-place - i.e., the array * values are overwritten with the result of applying jitter. * * @param data input/output data array * @param dist probability distribution to sample for jitter values * @throws NullPointerException if either of the parameters is null */ public static void jitter(double[] data, RealDistribution dist) IMO, this method should be part of the new API proposed in https://issues.apache.org/jira/browse/MATH-1158 Like so: /** {@inheritDoc} */ public RealDistribution.Sampler createSampler(final RandomGenerator rng) { return new RealDistribution.Sampler() { public double next() { /* ... */ } public double[] next(int sampleSize) { /* ... */ } /** * @param data input/output data array. * @param dist probability distribution to sample for jitter values * @throws NullPointerException if data array is null. */ public void jitter(double[] data) { final int len = data.length; final double[] jit = next(len); for (int i = 0; i < len; i++) { data[i] += jit[i]; } } }; } Advantages: * Simpler to use (half as many arguments). :-) I guess beauty is in the eye of the beholder. Simple static array-based method looks simpler to me. I didn't mention "beauty". But, indeed, using more OO constructs in an OO language could be construed as incresing the beauty of the library! Collections of static methods grouped in a "utility" classes are not OO programming (although they may make sense from a "utility" point-of-view, i.e. preferably not part of the public API). * Utility is defined where the base functionality is defined. * Avoid adding to the overcrowded MathArrays utility class. But it is an array utility. * Avoid dependency to another package (will help with modularization). Drawbacks from usage POV * None (?) Drawbacks from implementation POV * Cannot be done before we agree to go forward with the aforementioned issue. In the meantime, I suggest to implement it as a "private" method. I will add it as private. I don't like the setup above. Why? [Topic for another thread.] If we do end up pulling sampling out of the distributions, I would have the method take a "sampler." I would still not agree that's the way to go since the "setup above" is the current best attempt at solving all the problems encountered. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JXPATH] Java Version
I've updated JXPATH to Java 7. There is a lot of work to update the code base to use Java 7 languages features and APIs. I invite everybody to join me here... Thanks, Benedikt 2015-11-22 19:28 GMT+01:00 Pascal Schumacher : > If you pay Oracle for long term support you still get updates for Java 7. > > This means that there will be some people (like me at work :() which have > to stick to Java 7 for some time. > > > Am 22.11.2015 um 16:44 schrieb Gary Gregory: > >> On Sun, Nov 22, 2015 at 6:20 AM, Dave Brosius >> wrote: >> >> As has java 7 reached end of life. >>> >> >> FYI: I think IBM still supports their Java 7 IIRC >> >> Gayr >> >> >>> On 11/22/2015 09:06 AM, Benedikt Ritter wrote: >>> >>> I'm fine with Java 7, since Java 6 has already reached EOL. 2015-11-21 19:48 GMT+01:00 Gary Gregory : I'd go with Java 7. > Gary > On Nov 21, 2015 3:50 AM, "Benedikt Ritter" wrote: > > Hi, > >> any preference on which Java Version JXPath 1.4 target? Currently the >> >> build > > is set to 1.3. I've only Java 1.6, 1.7 1.8 and 1.9 installed on my >> >> machine, > > so I won't be able to test with 1.3, 1.4 and 1.5. Further more I don't >> >> see > > a reason to keep support for such old Java versions. >> >> Thoughts? >> Benedikt >> >> -- >> http://people.apache.org/~britter/ >> http://www.systemoutprintln.de/ >> http://twitter.com/BenediktRitter >> http://github.com/britter >> >> >> - >>> 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 > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [JXPATH] Java Version
> I've updated JXPATH to Java 7. There is a lot of work to update the code > base to use Java 7 languages features and APIs. I invite everybody to join > me here… Do you like to start these changes before or after the release 1.4? I prefer to create the release as soon as possible and start rework on that baseline. -- Uwe > On 24 Nov 2015, at 21:44, Benedikt Ritter wrote: > > I've updated JXPATH to Java 7. There is a lot of work to update the code > base to use Java 7 languages features and APIs. I invite everybody to join > me here... > > Thanks, > Benedikt > > 2015-11-22 19:28 GMT+01:00 Pascal Schumacher : > >> If you pay Oracle for long term support you still get updates for Java 7. >> >> This means that there will be some people (like me at work :() which have >> to stick to Java 7 for some time. >> >> >> Am 22.11.2015 um 16:44 schrieb Gary Gregory: >> >>> On Sun, Nov 22, 2015 at 6:20 AM, Dave Brosius >>> wrote: >>> >>> As has java 7 reached end of life. >>> >>> FYI: I think IBM still supports their Java 7 IIRC >>> >>> Gayr >>> >>> On 11/22/2015 09:06 AM, Benedikt Ritter wrote: I'm fine with Java 7, since Java 6 has already reached EOL. > > 2015-11-21 19:48 GMT+01:00 Gary Gregory : > > I'd go with Java 7. > >> Gary >> On Nov 21, 2015 3:50 AM, "Benedikt Ritter" wrote: >> >> Hi, >> >>> any preference on which Java Version JXPath 1.4 target? Currently the >>> >>> build >> >> is set to 1.3. I've only Java 1.6, 1.7 1.8 and 1.9 installed on my >>> >>> machine, >> >> so I won't be able to test with 1.3, 1.4 and 1.5. Further more I don't >>> >>> see >> >> a reason to keep support for such old Java versions. >>> >>> Thoughts? >>> Benedikt >>> >>> -- >>> http://people.apache.org/~britter/ >>> http://www.systemoutprintln.de/ >>> http://twitter.com/BenediktRitter >>> http://github.com/britter >>> >>> >>> > - 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 >> >> > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
MathArrays -> JogAmp -> OpenCL
Is anyone interested in some GPU support for MathArrays by using, say, the JogAmp bindings and OpenCL methods. I have implemented such an architecture for my own convolution library I am developing, and it would not be much trouble for me to add this kind of support for commons-math some time in the new year. It would require the user to install the JOCL glue libraries to make use of this and this may be out side of the commons mission. Overall I find JogAmp very convenient and its creators support it. Eric
Re: [VOTE] Release commons-io 2.5 based on RC1
Hi Kristian, while checking the release I found some problems: * The commons-io-2.5.jar in the binary distribution contains a cobertura.properties file. This is probably created by running the site build over the release build before creating the distributions. In the past we had a problematic release because Cobertura seems to mess up some classes. I cannot remember the exact details, but the jar was not working correctly. Could this be the case here, too? * The copyright year in NOTICE is still 2014. I think this is blocking. * Building with Java 1.6 on Windows 10 gives a test failure: --- Test set: org.apache.commons.io.FileUtilsTestCase --- Tests run: 134, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.203 sec <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase testGetFile(org.apache.commons.io.FileUtilsTestCase) Time elapsed: 0 sec <<< ERROR! java.io.IOException: Cannot create file C:\data\dev\projects\OpenSource\io\commons-io-2.5-src\test\io\file1-test.txt as the parent directory does not exist at org.apache.commons.io.testtools.FileBasedTestCase.createFile(FileBasedTestCase.java:60) at org.apache.commons.io.FileUtilsTestCase.setUp(FileUtilsTestCase.java:101) With Java 1.8 it is worse; here I get 71 errors which are mostly similar to the one before (all in FileUtilsTestCase). The site looks okay except for the JIRA report which is missing. -1 Sorry Oliver Am 23.11.2015 um 18:31 schrieb Kristian Rosenvold: > We have fixed quite a few bugs and added some significant > enhancements since commons-io was released, > so I would like to release commons-io 2.5 > > Foo 2.5 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision 11266) > > Maven artifacts are here: >https://repository.apache.org/content/repositories/orgapachecommons-1123 > > Details of changes since 2.4 are in the release notes: > https://dist.apache.org/repos/dist/dev/commons/io/RELEASE-NOTES.txt > > http://people.apache.org/~krosenvold/commons-io-2.5-RC1/changes-report.html > > I have tested this with JDK 1.6, 1.7 and 1.8. > > The tag is here: > https://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-2.5-RC1 > (r1715890) > > Site: > http://people.apache.org/~krosenvold/commons-io-2.5-RC1/ > (note some *relative* links are broken and the 2.5 directories are > not yet created - these will be OK once the site is deployed) > > Clirr Report (compared to 2.4): > http://people.apache.org/~krosenvold/commons-io-2.5-RC1/clirr-report.html > > > RAT Report: > http://people.apache.org/~krosenvold/commons-io-2.5-RC1/rat-report.html > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner that 72 hours from now, i.e. after > 19:00 CET 26-March 2015 > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thanks! > > > Kristian > > - > 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: [JXPATH] Java Version
On 11/24/2015 09:55 PM, Uwe Barthel wrote: >> I've updated JXPATH to Java 7. There is a lot of work to update the code >> base to use Java 7 languages features and APIs. I invite everybody to join >> me here… > > Do you like to start these changes before or after the release 1.4? > I prefer to create the release as soon as possible and start rework on that > baseline. If the idea is to roll out a bugfix release that people are awaiting then I do not see the point in updating the minimum java version and changing the code to use new language / jdk features. This will just limit the use of the bugfix release, as not every application using it will have been upgraded already. Also, every change might introduce another problem, but this is up to the judgement of the maintainer(s). For the release afterwards (i.e. 1.5), I think it is fine to apply all the changes, and updating the minimum java version in minor releases is ok and has been done for other components already. Just my 2 cents Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Collections 4.1 Based on RC1
On 11/22/2015 11:26 PM, Thomas Neidhart wrote: > Hi all, > > we have accumulated enough changes since the last 4.0 release as well as > we need to provide a fix for the known remote code exploit via java > de-serialization. Therefore, I would like to start a vote to release > Commons Collections 4.1 based on RC1. > > Note: > > The fix for the security related issue results in Clirr errors as unsafe > classes in the functor package do not implement the Serializable > interface anymore. This is mentioned in the release notes. > > > Collections 4.1 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/collections/ > (svn revision 11263) > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/orgapachecommons-1122/org/apache/commons/commons-collections4/4.1/ > > Details of changes since 4.0 are in the release notes: > > > https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt > > > http://people.apache.org/builds/commons/collections/4.1/RC1/changes-report.html > > The tag is here: > > > https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_1_RC1 > (svn revision 1715703) > > Site: > http://people.apache.org/builds/commons/collections/4.1/RC1/ > > Clirr Report (compared to 4.0): > > > http://people.apache.org/builds/commons/collections/4.1/RC1/clirr-report.html > > RAT Report: > > > http://people.apache.org/builds/commons/collections/4.1/RC1/rat-report.html > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > > This vote will close no sooner that 72 hours from now, i.e. after 2400 > GMT 25-November 2015 > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... I would like to remind all PMC members that this is also a security related release that several people have requested. If someone is not happy with the release as is, please speak up and vote so that we at least can move forward. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JXPATH] Java Version
On Tue, Nov 24, 2015 at 3:06 PM, Thomas Neidhart wrote: > On 11/24/2015 09:55 PM, Uwe Barthel wrote: >>> I've updated JXPATH to Java 7. There is a lot of work to update the code >>> base to use Java 7 languages features and APIs. I invite everybody to join >>> me here… >> >> Do you like to start these changes before or after the release 1.4? >> I prefer to create the release as soon as possible and start rework on that >> baseline. > > If the idea is to roll out a bugfix release that people are awaiting > then I do not see the point in updating the minimum java version and > changing the code to use new language / jdk features. > > This will just limit the use of the bugfix release, as not every > application using it will have been upgraded already. Also, every change > might introduce another problem, but this is up to the judgement of the > maintainer(s). > > For the release afterwards (i.e. 1.5), I think it is fine to apply all > the changes, and updating the minimum java version in minor releases is > ok and has been done for other components already. I really want to see JXPath get e.g. generics. That said, there is wisdom in leaving that until after the immediate release. I don't have the patience for acting as RM, but I think I'll have a few spare cycles to work on upgrades. What does everyone think about creating a branch for this work? Matt > > Just my 2 cents > > Thomas > > - > 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: MathArrays -> JogAmp -> OpenCL
On Tue, 24 Nov 2015 20:58:14 +, Eric Barnhill wrote: Is anyone interested in some GPU support for MathArrays by using, say, the JogAmp bindings and OpenCL methods. I have implemented such an architecture for my own convolution library I am developing, and it would not be much trouble for me to add this kind of support for commons-math some time in the new year. It would require the user to install the JOCL glue libraries to make use of this and this may be out side of the commons mission. Overall I find JogAmp very convenient and its creators support it. There were some recent and not so recent discussions on parallel processing as a way to enhance the performance of CM. Actual experiments are certainly welcome to figure out the best way(s) to go. And this would probably be a nice addition to the userguide. Could you give pointers to the utilities and a slightly more detailed description of the intended usage? Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release NET 3.4 based on RC2 - resend with corrected tag
Hi Sebb, well, README tells me to use Maven 2 to build: = %< = $ mvn-2.2 clean package [INFO] Scanning for projects... [INFO] -- [INFO] Building Apache Commons Net [INFO]task-segment: [clean, package] [INFO] -- [INFO] -- [ERROR] BUILD ERROR [INFO] -- [INFO] Error resolving version for 'org.apache.maven.plugins:maven-scm- publish-plugin': Plugin requires Maven version 3.0 = %< = ;-) However, I can build the sources with my compiler zoo (Java 5 to 9) without problems. +1 Cheers, Jörg sebb wrote: > It's probably about time to release NET. > There have been quite a few improvements and fixes since the last version. > > [This is a repeat of the original mail, but using a tag that actually > exists this time] > > == > > Net 3.4 RC2 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/net/ (svn revision > 11241) > > ./binaries/commons-net-3.4- bin.tar.gz.sha1:88411522395b4000b038a94ab007be89ebda2ec3 > ./binaries/commons-net-3.4- bin.zip.sha1:f252a45b1610346116c9dd966fec9a15171223d1 > ./source/commons-net-3.4- src.tar.gz.sha1:abfba84427a06341e113d59d8f75855e67093087 > ./source/commons-net-3.4- src.zip.sha1:f3b38dfcccd8fcdc9ac500a5f8580a19817b > > Maven artifacts are here: > https://repository.apache.org/content/repositories/orgapachecommons-1120/commons-net/commons-net/3.4/ > > These are the artifacts and their hashes > > /commons-net/commons-net/3.4/commons-net-3.4-test-sources.jar > (SHA1: fdb74119054a2aacc134c56137660d7a0a40e4a8) > /commons-net/commons-net/3.4/commons-net-3.4-javadoc.jar > (SHA1: b882750c8dbd480e2b9afd357dcf71d962f2fa03) > /commons-net/commons-net/3.4/commons-net-3.4-ftp.jar > (SHA1: 6fc585e5f3dc8333b20110af22a8bae59f5246cb) > /commons-net/commons-net/3.4/commons-net-3.4-tests.jar > (SHA1: ce44ebc0e7be56c3bd650700be93c5b377b47573) > /commons-net/commons-net/3.4/commons-net-3.4.pom > (SHA1: d1790447a41c848af8cba0919fae7a577fbc744a) > /commons-net/commons-net/3.4/commons-net-3.4.jar > (SHA1: 5e984db9554728564d58e90da5d90eff8ae8cf2d) > /commons-net/commons-net/3.4/commons-net-3.4-sources.jar > (SHA1: 08439b8f20d7bdec502423732798a639501732c8) > /commons-net/commons-net/3.4/commons-net-3.4-examples.jar > (SHA1: 33abb13d790501fc9e4e77a40425bc381d39b9ca) > > Details of changes since 3.3 are in the release notes: > https://dist.apache.org/repos/dist/dev/commons/net/RELEASE-NOTES.txt > http://people.apache.org/~sebb/net-3.4-RC2/changes-report.html > > I have tested this with JDK 1.6, 1.7, 1.8 using maven3. > > The tag is here: > http://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_4_RC2/ > (svn 1715635) > > N.B. the SVN revision is required because SVN tags are not immutable. > > Site: > http://people.apache.org/~sebb/net-3.4-RC2/ > (note some *relative* links are broken and the 3.4 directories are > not yet created - these will be OK once the site is deployed) > > download_net.cgi does not work, but the template can be checked at > http://people.apache.org/~sebb/net-3.4-RC2/download_net.html > > Clirr Report (compared to 3.3): > http://people.apache.org/~sebb/net-3.4-RC2/clirr-report.html > > Note that adding methods to an interface is binary-compatible, but > not source-compatible > This change is documented in the Release Notes > > RAT Report: > http://people.apache.org/~sebb/net-3.4-RC2/rat-report.html > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner that 72 hours from now, i.e. after > 14:00 GMT 22-Nov 2015 > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thanks! > > Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JXPATH] Java Version
Le 24/11/2015 22:06, Thomas Neidhart a écrit : > If the idea is to roll out a bugfix release that people are awaiting > then I do not see the point in updating the minimum java version and > changing the code to use new language / jdk features. I agree with Thomas. Let's update the JDK for simplifying the release process, but updating the syntax now isn't necessary. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Collections 4.1 Based on RC1
Hi Thomas, Thomas Neidhart wrote: > Hi all, > > we have accumulated enough changes since the last 4.0 release as well as > we need to provide a fix for the known remote code exploit via java > de-serialization. Therefore, I would like to start a vote to release > Commons Collections 4.1 based on RC1. > > Note: > > The fix for the security related issue results in Clirr errors as unsafe > classes in the functor package do not implement the Serializable > interface anymore. This is mentioned in the release notes. > > > Collections 4.1 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/collections/ > (svn revision 11263) > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/orgapachecommons-1122/org/apache/commons/commons-collections4/4.1/ > > Details of changes since 4.0 are in the release notes: > > > https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt > > > http://people.apache.org/builds/commons/collections/4.1/RC1/changes-report.html > > The tag is here: > > > https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_1_RC1 > (svn revision 1715703) > > Site: > http://people.apache.org/builds/commons/collections/4.1/RC1/ > > Clirr Report (compared to 4.0): > > > http://people.apache.org/builds/commons/collections/4.1/RC1/clirr-report.html > > RAT Report: > > > http://people.apache.org/builds/commons/collections/4.1/RC1/rat-report.html > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > > This vote will close no sooner that 72 hours from now, i.e. after 2400 > GMT 25-November 2015 > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thanks, > > Thomas It fails for IBM JDK 6: %< === Failed tests: org.apache.commons.collections4.map.AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue(org.apache.commons.collections4.map.AbstractMapTest$TestMapEntrySet) Run 1: PASS Run 2: PASS Run 3: PASS Run 4: PASS Run 5: PASS Run 6: PASS Run 7: PASS Run 8: PASS Run 9: PASS Run 10: PASS Run 11: PASS Run 12: PASS Run 13: PASS Run 14: PASS Run 15: PASS Run 16: PASS Run 17: PASS Run 18: PASS Run 19: PASS Run 20: PASS Run 21: PASS Run 22: PASS Run 23: PASS Run 24: PASS Run 25: PASS Run 26: PASS Run 27: PASS Run 28: PASS Run 29: PASS Run 30: PASS Run 31: PASS Run 32: PASS Run 33: PASS Run 34: PASS Run 35: PASS Run 36: PASS Run 37: AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue:1665 expected: but was: Run 38: PASS Run 39: PASS Run 40: PASS Run 41: PASS Run 42: AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue:1665 expected: but was: Run 43: PASS %< === $ mvn-3.0 -version Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100) Maven home: /usr/share/maven-bin-3.0 Java version: 1.6.0, vendor: IBM Corporation Java home: /opt/ibm-jdk-bin-1.6.0.9_p2/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.1.12-gentoo", arch: "amd64", family: "unix" %< === It fails to compile with Java 8: %< === [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /home/joehni/tmp/download/commons-collections4-4.1- src/src/test/java/org/apache/commons/collections4/FluentIterableTest.java: [242,41] reference to forEach is ambiguous both method forEach(java.util.function.Consumer) in java.lang.Iterable and method forEach(org.apache.commons.collections4.Closure) in org.apache.commons.collections4.FluentIterable match [INFO] 1 error [INFO] - %< === $ mvn-3.0 -version Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100) Maven home: /usr/share/maven-bin-3.0 Java version: 1.8.0_66, vendor: Oracle Corporation Java home: /opt/oracle-jdk-bin-1.8.0.66/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.1.12-gentoo", arch: "amd64", family: "unix" %< === nor Java 9: %< === [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /home/joehni/tmp/download/commons-collections4-4.1- src/src/main/java/org/apache/commons/collections4/functors/SwitchClosure.java: [123,48] incompatible types: cannot infer type-variable(s) T
Re: [JXPATH] Java Version
On 25 November 2015 at 09:29, Emmanuel Bourg wrote: > Le 24/11/2015 22:06, Thomas Neidhart a écrit : > >> If the idea is to roll out a bugfix release that people are awaiting >> then I do not see the point in updating the minimum java version and >> changing the code to use new language / jdk features. > > I agree with Thomas. Let's update the JDK for simplifying the release > process, but updating the syntax now isn't necessary. One simple addition you can do when moving to Java-7 is to add java.lang.AutoCloseable to any relevant classes that are not already java.io.Closeable, but still have resources that need to be cleaned up. Then users can then use them in try-with-resources (and IDE's can start warning about resource cleanups), even if the jxpath codebase doesn't internally change from the previous try pattern to try-with-resources immediately. Cheers, Peter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JXPATH] Java Version
Le 22/11/2015 15:06, Benedikt Ritter a écrit : > I'm fine with Java 7, since Java 6 has already reached EOL. The free of charge Oracle Java 6 is EOL, but this isn't the only Java 6 distributions. OpenJDK 6 is still maintained by RedHat [1] and is commonly used on servers. On Debian OpenJDK 6 is still installed on 35% of the machines with OpenJDK [2]. On the desktop side the figures are quite different. On the application I maintain I observe that Java 8 dominates around 75%. Java 6 is around 17%, mostly due to OS X users not upgrading the Apple Java to the more recent Oracle Java. Emmanuel Bourg [1] http://hg.openjdk.java.net/jdk6/jdk6/jdk/ [2] https://qa.debian.org/popcon-graph.php?packages=openjdk-6-jre-headless+openjdk-7-jre-headless+openjdk-8-jre-headless&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release commons-io 2.5 based on RC1
Just to add to Java 8 woes, running "mvn clean site", I get: [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 08:01 min [INFO] Finished at: 2015-11-24T16:13:48-08:00 [INFO] Final Memory: 62M/540M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project commons-io: Execution default-site of goal org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Invalid byte tag in constant pool: 15 -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException Using: Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) Maven home: E:\Java\apache-maven-3.3.9\bin\.. Java version: 1.8.0_65, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_65\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" It probably has nothing to do with us, just a data point. This is from the src zip, ASC, MD5, SHA1, and reports are OK. I can build with "mvn clean site" OK with: Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) Maven home: E:\Java\apache-maven-3.3.9\bin\.. Java version: 1.7.0_79, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_79\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" So +1 from me based on my experience. I am worried about the report failures on the VOTE thread though. I did not install/run with Java 6 though. Caveat, while in the Cobertura part of the build, I saw this: Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 26.076 sec <<< FAILURE! - in org.apache.commons.io.input.TailerTest testTailer(org.apache.commons.io.input.TailerTest) Time elapsed: 5.412 sec <<< FAILURE! junit.framework.AssertionFailedError: Missing InterruptedException at junit.framework.Assert.fail(Assert.java:57) at junit.framework.Assert.assertTrue(Assert.java:22) at junit.framework.Assert.assertNotNull(Assert.java:256) at junit.framework.TestCase.assertNotNull(TestCase.java:426) at org.apache.commons.io.input.TailerTest.testTailer(TailerTest.java:258) But I did not see the above during the normal test phase of the build. Gary On Tue, Nov 24, 2015 at 12:59 PM, Oliver Heger wrote: > Hi Kristian, > > while checking the release I found some problems: > > * The commons-io-2.5.jar in the binary distribution contains a > cobertura.properties file. This is probably created by running the site > build over the release build before creating the distributions. In the > past we had a problematic release because Cobertura seems to mess up > some classes. I cannot remember the exact details, but the jar was not > working correctly. Could this be the case here, too? > * The copyright year in NOTICE is still 2014. I think this is blocking. > * Building with Java 1.6 on Windows 10 gives a test failure: > > > --- > Test set: org.apache.commons.io.FileUtilsTestCase > > --- > Tests run: 134, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.203 > sec <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase > testGetFile(org.apache.commons.io.FileUtilsTestCase) Time elapsed: 0 > sec <<< ERROR! > java.io.IOException: Cannot create file > > C:\data\dev\projects\OpenSource\io\commons-io-2.5-src\test\io\file1-test.txt > as the parent directory does not exist > at > > org.apache.commons.io.testtools.FileBasedTestCase.createFile(FileBasedTestCase.java:60) > at > org.apache.commons.io.FileUtilsTestCase.setUp(FileUtilsTestCase.java:101) > > With Java 1.8 it is worse; here I get 71 errors which are mostly similar > to the one before (all in FileUtilsTestCase). > > The site looks okay except for the JIRA report which is missing. > > -1 > > Sorry > Oliver > > > Am 23.11.2015 um 18:31 schrieb Kristian Rosenvold: > > We have fixed quite a few bugs and added some significant > > enhancements since commons-io was released, > > so I would like to release commons-io 2.5 > > > > Foo 2.5 RC1 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision > 11266) > > > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/
[VOTE] Release commons-io 2.5 based on RC1 - Cancelled
Thanks for the reviews, I'll fix the reported problems and respin! the test failure on java8 site looks weird, I'll look into that. As for actually publishing the site on java8, I'd have to switch to the google BCEL to fix that. I'm assuming we can just "not support" this for the time being ? Kristian 2015-11-25 2:36 GMT+01:00 Gary Gregory : > Just to add to Java 8 woes, running "mvn clean site", I get: > > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 08:01 min > [INFO] Finished at: 2015-11-24T16:13:48-08:00 > [INFO] Final Memory: 62M/540M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on > project commons-io: Execution default-site of goal > org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Invalid byte > tag in constant pool: 15 > -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException > > Using: > > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T08:41:47-08:00) > Maven home: E:\Java\apache-maven-3.3.9\bin\.. > Java version: 1.8.0_65, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_65\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" > > It probably has nothing to do with us, just a data point. > > This is from the src zip, ASC, MD5, SHA1, and reports are OK. > > I can build with "mvn clean site" OK with: > > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T08:41:47-08:00) > Maven home: E:\Java\apache-maven-3.3.9\bin\.. > Java version: 1.7.0_79, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_79\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" > > So +1 from me based on my experience. I am worried about the report > failures on the VOTE thread though. I did not install/run with Java 6 > though. > > Caveat, while in the Cobertura part of the build, I saw this: > > Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 26.076 sec > <<< FAILURE! - in org.apache.commons.io.input.TailerTest > testTailer(org.apache.commons.io.input.TailerTest) Time elapsed: 5.412 sec > <<< FAILURE! > junit.framework.AssertionFailedError: Missing InterruptedException > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.assertTrue(Assert.java:22) > at junit.framework.Assert.assertNotNull(Assert.java:256) > at junit.framework.TestCase.assertNotNull(TestCase.java:426) > at > org.apache.commons.io.input.TailerTest.testTailer(TailerTest.java:258) > > But I did not see the above during the normal test phase of the build. > > Gary > > On Tue, Nov 24, 2015 at 12:59 PM, Oliver Heger > wrote: > >> Hi Kristian, >> >> while checking the release I found some problems: >> >> * The commons-io-2.5.jar in the binary distribution contains a >> cobertura.properties file. This is probably created by running the site >> build over the release build before creating the distributions. In the >> past we had a problematic release because Cobertura seems to mess up >> some classes. I cannot remember the exact details, but the jar was not >> working correctly. Could this be the case here, too? >> * The copyright year in NOTICE is still 2014. I think this is blocking. >> * Building with Java 1.6 on Windows 10 gives a test failure: >> >> >> --- >> Test set: org.apache.commons.io.FileUtilsTestCase >> >> --- >> Tests run: 134, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.203 >> sec <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase >> testGetFile(org.apache.commons.io.FileUtilsTestCase) Time elapsed: 0 >> sec <<< ERROR! >> java.io.IOException: Cannot create file >> >> C:\data\dev\projects\OpenSource\io\commons-io-2.5-src\test\io\file1-test.txt >> as the parent directory does not exist >> at >> >> org.apache.commons.io.testtools.FileBasedTestCase.createFile(FileBasedTestCase.java:60) >> at >> org.apache.commons.io.FileUtilsTestCase.setUp(FileUtilsTestCase.java:101) >> >> With Java 1.8 it is worse; here I get 71 errors which are mostly similar >> to the one before (all in FileUtilsTestCase). >> >> The site lo
Re: [VOTE] Release Commons Collections 4.1 Based on RC1
On 11/24/2015 11:30 PM, Jörg Schaible wrote: > Hi Thomas, > > Thomas Neidhart wrote: > >> Hi all, >> >> we have accumulated enough changes since the last 4.0 release as well as >> we need to provide a fix for the known remote code exploit via java >> de-serialization. Therefore, I would like to start a vote to release >> Commons Collections 4.1 based on RC1. >> >> Note: >> >> The fix for the security related issue results in Clirr errors as unsafe >> classes in the functor package do not implement the Serializable >> interface anymore. This is mentioned in the release notes. >> >> >> Collections 4.1 RC1 is available for review here: >> https://dist.apache.org/repos/dist/dev/commons/collections/ >> (svn revision 11263) >> >> Maven artifacts are here: >> >> >> > https://repository.apache.org/content/repositories/orgapachecommons-1122/org/apache/commons/commons-collections4/4.1/ >> >> Details of changes since 4.0 are in the release notes: >> >> >> https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt >> >> >> http://people.apache.org/builds/commons/collections/4.1/RC1/changes-report.html >> >> The tag is here: >> >> >> > https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_1_RC1 >> (svn revision 1715703) >> >> Site: >> http://people.apache.org/builds/commons/collections/4.1/RC1/ >> >> Clirr Report (compared to 4.0): >> >> >> http://people.apache.org/builds/commons/collections/4.1/RC1/clirr-report.html >> >> RAT Report: >> >> >> http://people.apache.org/builds/commons/collections/4.1/RC1/rat-report.html >> >> KEYS: >> https://www.apache.org/dist/commons/KEYS >> >> Please review the release candidate and vote. >> >> This vote will close no sooner that 72 hours from now, i.e. after 2400 >> GMT 25-November 2015 >> >> [ ] +1 Release these artifacts >> [ ] +0 OK, but... >> [ ] -0 OK, but really should fix... >> [ ] -1 I oppose this release because... >> >> Thanks, >> >> Thomas > > It fails for IBM JDK 6: > > %< === > Failed tests: > org.apache.commons.collections4.map.AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue(org.apache.commons.collections4.map.AbstractMapTest$TestMapEntrySet) > Run 1: PASS > Run 2: PASS > Run 3: PASS > Run 4: PASS > Run 5: PASS > Run 6: PASS > Run 7: PASS > Run 8: PASS > Run 9: PASS > Run 10: PASS > Run 11: PASS > Run 12: PASS > Run 13: PASS > Run 14: PASS > Run 15: PASS > Run 16: PASS > Run 17: PASS > Run 18: PASS > Run 19: PASS > Run 20: PASS > Run 21: PASS > Run 22: PASS > Run 23: PASS > Run 24: PASS > Run 25: PASS > Run 26: PASS > Run 27: PASS > Run 28: PASS > Run 29: PASS > Run 30: PASS > Run 31: PASS > Run 32: PASS > Run 33: PASS > Run 34: PASS > Run 35: PASS > Run 36: PASS > Run 37: > AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue:1665 > expected: but was: > Run 38: PASS > Run 39: PASS > Run 40: PASS > Run 41: PASS > Run 42: > AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue:1665 > expected: but was: > Run 43: PASS These test failures exist since the 4.0 release, quoting your vote for Collection 4.0 based on RC5: > +1, builds for all but one JDK flawlessly from source. I still have 2 > failing tests for IBM JDK 1.6: > > Failed tests: > AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue:1656 > expected: but was: > AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue:1656 > expected: but was: > > However, since we already blamed that JDK, it does not influence the > release. I can not remember anymore why these have not been worked-around though, but I suspect that it was not so simple in this case. > %< === > $ mvn-3.0 -version > Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 > 14:51:28+0100) > Maven home: /usr/share/maven-bin-3.0 > Java version: 1.6.0, vendor: IBM Corporation > Java home: /opt/ibm-jdk-bin-1.6.0.9_p2/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "4.1.12-gentoo", arch: "amd64", family: "unix" > %< === > > It fails to compile with Java 8: > > %< === > [INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] /home/joehni/tmp/download/commons-collections4-4.1- > src/src/test/java/org/apache/commons/collections4/FluentIterableTest.java: > [242,41] reference to forEach is ambiguous > both method forEach(java.util.function.Consumer) in > java.lang.Iterable and method > forEach(org.apache.commons.collections4.Closure) in > org.apache.commons.collections4.FluentIterable match > [INFO] 1 error > [INFO]
Re: [JXPATH] Java Version
2015-11-24 22:06 GMT+01:00 Thomas Neidhart : > On 11/24/2015 09:55 PM, Uwe Barthel wrote: > >> I've updated JXPATH to Java 7. There is a lot of work to update the code > >> base to use Java 7 languages features and APIs. I invite everybody to > join > >> me here… > > > > Do you like to start these changes before or after the release 1.4? > > I prefer to create the release as soon as possible and start rework on > that baseline. > > If the idea is to roll out a bugfix release that people are awaiting > then I do not see the point in updating the minimum java version and > changing the code to use new language / jdk features. > The problem with JDK 1.4 is, that I don't have it on any machine. The oldest JDK you can get for Mac OS X to my knowledge is 1.6. I wouldn't want to RM for a project when I can't test with the target JDK. If anybody knows where to get a JDK 1.4 for Mac OS, that would be very much appreciated. > > This will just limit the use of the bugfix release, as not every > application using it will have been upgraded already. Also, every change > might introduce another problem, but this is up to the judgement of the > maintainer(s). > > For the release afterwards (i.e. 1.5), I think it is fine to apply all > the changes, and updating the minimum java version in minor releases is > ok and has been done for other components already. > Just my 2 cents > > Thomas > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [JXPATH] Java Version
2015-11-24 21:55 GMT+01:00 Uwe Barthel : > > I've updated JXPATH to Java 7. There is a lot of work to update the code > > base to use Java 7 languages features and APIs. I invite everybody to > join > > me here… > > Do you like to start these changes before or after the release 1.4? > I prefer to create the release as soon as possible and start rework on > that baseline. > I have already started to upgrade the code base. > > -- Uwe > > > > On 24 Nov 2015, at 21:44, Benedikt Ritter wrote: > > > > I've updated JXPATH to Java 7. There is a lot of work to update the code > > base to use Java 7 languages features and APIs. I invite everybody to > join > > me here... > > > > Thanks, > > Benedikt > > > > 2015-11-22 19:28 GMT+01:00 Pascal Schumacher : > > > >> If you pay Oracle for long term support you still get updates for Java > 7. > >> > >> This means that there will be some people (like me at work :() which > have > >> to stick to Java 7 for some time. > >> > >> > >> Am 22.11.2015 um 16:44 schrieb Gary Gregory: > >> > >>> On Sun, Nov 22, 2015 at 6:20 AM, Dave Brosius > >>> wrote: > >>> > >>> As has java 7 reached end of life. > > >>> > >>> FYI: I think IBM still supports their Java 7 IIRC > >>> > >>> Gayr > >>> > >>> > On 11/22/2015 09:06 AM, Benedikt Ritter wrote: > > I'm fine with Java 7, since Java 6 has already reached EOL. > > > > 2015-11-21 19:48 GMT+01:00 Gary Gregory : > > > > I'd go with Java 7. > > > >> Gary > >> On Nov 21, 2015 3:50 AM, "Benedikt Ritter" > wrote: > >> > >> Hi, > >> > >>> any preference on which Java Version JXPath 1.4 target? Currently > the > >>> > >>> build > >> > >> is set to 1.3. I've only Java 1.6, 1.7 1.8 and 1.9 installed on my > >>> > >>> machine, > >> > >> so I won't be able to test with 1.3, 1.4 and 1.5. Further more I > don't > >>> > >>> see > >> > >> a reason to keep support for such old Java versions. > >>> > >>> Thoughts? > >>> Benedikt > >>> > >>> -- > >>> http://people.apache.org/~britter/ > >>> http://www.systemoutprintln.de/ > >>> http://twitter.com/BenediktRitter > >>> http://github.com/britter > >>> > >>> > >>> > > - > 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 > >> > >> > > > > > > -- > > http://people.apache.org/~britter/ > > http://www.systemoutprintln.de/ > > http://twitter.com/BenediktRitter > > http://github.com/britter > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
[JXPATH] Release plans
Hi, it looks like I've been to fast with my minimum Java update on JXPath. Probably because I've only waited for the people how are usually all for upgrading to a later JDK (*waves at Gary* ;-). So here's my plan for JXPath 1.4. 1) Revert the following commits: http://svn.apache.org/viewvc?rev=1716238&view=rev http://svn.apache.org/viewvc?rev=1716249&view=rev http://svn.apache.org/viewvc?rev=1716252&view=rev http://svn.apache.org/viewvc?rev=1716243&view=rev 2) Find a way to test the build with Java 1.4 on Mac OS X (maybe using a VM) 3) Push out JXPath 1.4 RC1 4) Upgrade to Java 7 after release of JXPath 1.4 Again, everybody is welcome to help polish this release, since I'm not too familiar with JXPath at the moment. Best regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [JXPATH] Java Version
> Do you like to start these changes before or after the release 1.4? > I prefer to create the release as soon as possible and start rework on that baseline. Maybe my statement was a bit ambiguous. I'm fine with a Java version 1.6 or 1.7 but would not wait until the code is overall refurbished. The problem with JDK 1.4 is, that I don't have it on any machine. The oldest JDK you can get for Mac OS X to my knowledge is 1.6. Unfortunately, same here. -- Uwe - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org