date:20151124

Re: [VOTE] Release NET 3.4 based on RC2 - resend with corrected tag

2015-11-24 Thread Jörg Schaible

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

2015-11-24 Thread Peter Ansell

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: [VOTE] Release Commons Collections 4.1 Based on RC1

2015-11-24 Thread Jörg Schaible

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

2015-11-24 Thread Emmanuel Bourg

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_installed=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1


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

Re: [math] additions to MathArrays

2015-11-24 Thread Gilles


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: [VOTE] Release Commons Collections 4.1 Based on RC1

2015-11-24 Thread Thomas Neidhart

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

MathArrays -> JogAmp -> OpenCL

2015-11-24 Thread Eric Barnhill

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: [JXPATH] Java Version

2015-11-24 Thread 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.

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: [JXPATH] Java Version

2015-11-24 Thread 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.

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

Re: [VOTE] Release commons-io 2.5 based on RC1

2015-11-24 Thread Oliver Heger

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: MathArrays -> JogAmp -> OpenCL

2015-11-24 Thread Gilles


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

2015-11-24 Thread Benedikt Ritter

+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
>
> ==
> ---

Re: [JXPATH] Java Version

2015-11-24 Thread Benedikt Ritter

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

2015-11-24 Thread Matt Benson

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: [VOTE] Release commons-io 2.5 based on RC1

2015-11-24 Thread 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 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:
> >
>

[VOTE] Release commons-io 2.5 based on RC1 - Cancelled

2015-11-24 Thread Kristian Rosenvold

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

Re: [VOTE] Release Commons Collections 4.1 Based on RC1

2015-11-24 Thread Thomas Neidhart

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 Thread Uwe Barthel




> 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

[JXPATH] Release plans

2015-11-24 Thread Benedikt Ritter

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=rev
http://svn.apache.org/viewvc?rev=1716249=rev
http://svn.apache.org/viewvc?rev=1716252=rev
http://svn.apache.org/viewvc?rev=1716243=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

2015-11-24 Thread Benedikt Ritter

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 Thread Benedikt Ritter

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

Re: [math] additions to MathArrays

2015-11-24 Thread Ole Ersoy


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

2015-11-24 Thread sebb

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: r1716090 - in /commons/proper/collections/trunk: .travis.yml README.md pom.xml

2015-11-24 Thread Benedikt Ritter

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=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=1716089=1716090=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=1716089=1716090=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=1716089=1716090=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

2015-11-24 Thread 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=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=1716089=1716090=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=1716089=1716090=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=1716089=1716090=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

2015-11-24 Thread Phil Steitz

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

2015-11-24 Thread Benedikt Ritter

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=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=1716089=1716090=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=1716089=1716090=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=1716089=1716090=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

2015-11-24 Thread Phil Steitz

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: [JXPATH] Java Version

2015-11-24 Thread Emmanuel Bourg

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: [math] testing issue with Kolmogorov-Smirnov bootstrap methods

2015-11-24 Thread Gilles


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

[math] testing issue with Kolmogorov-Smirnov bootstrap methods

2015-11-24 Thread Luc Maisonobe

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] additions to MathArrays

2015-11-24 Thread sebb

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

2015-11-24 Thread Gilles


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: [math] testing issue with Kolmogorov-Smirnov bootstrap methods

2015-11-24 Thread Phil Steitz



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

2015-11-24 Thread sebb

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

[math] additions to MathArrays

2015-11-24 Thread Phil Steitz

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] testing issue with Kolmogorov-Smirnov bootstrap methods

2015-11-24 Thread Luc Maisonobe

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

Re: [math] testing issue with Kolmogorov-Smirnov bootstrap methods

2015-11-24 Thread Phil Steitz

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

38 matches

Mail list logo