Patch for review

[Shweta Turakhia]

Hi,
 Can someone please take a look at the patch uploaded for
https://issues.apache.org/jira/browse/LANG-1061

I made the changes as discussed on the jira and updated the unit tests.

Thanks,
Shweta

Jenkins build is still unstable: Commons Math #29

[Apache Jenkins Server]

See 


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

Re: [MATH] Jenkins unit test failure

[Thomas Neidhart]

I did several tests by adding additional console output.
The build was always running on H11 and sometimes it was working, while in
other cases not.

Inspecting the byte code did not show anything unusual, it looks correct.
Maybe it is related to jacoco, as it adds a javaagent which manipulates
bytecode during the execution.

I will do further tests to see if there is a connection.

Thomas

On Tue, Jan 13, 2015 at 2:50 AM, sebb  wrote:

> On 13 January 2015 at 01:12, sebb  wrote:
> > On 13 January 2015 at 00:53, Phil Steitz  wrote:
> >> On 1/12/15 5:44 PM, sebb wrote:
> >>> On 12 January 2015 at 22:21, Thomas Neidhart <
> thomas.neidh...@gmail.com> wrote:
>  On 01/12/2015 11:17 PM, Phil Steitz wrote:
> > On 1/12/15 2:30 PM, Thomas Neidhart wrote:
> >> On 01/12/2015 10:26 PM, Thomas Neidhart wrote:
> >>> On 01/12/2015 08:09 PM, Phil Steitz wrote:
>  On 1/12/15 11:37 AM, sebb wrote:
> > On 12 January 2015 at 18:11, Phil Steitz 
> wrote:
> >> On 1/12/15 10:50 AM, sebb wrote:
> >>> On 11 January 2015 at 22:10, Phil Steitz <
> phil.ste...@gmail.com> wrote:
>  On 1/11/15 11:19 AM, Phil Steitz wrote:
> > On 1/10/15 10:49 PM, Phil Steitz wrote:
> >> On 1/9/15 6:09 PM, sebb wrote:
> >>> On 10 January 2015 at 01:01, Phil Steitz <
> phil.ste...@gmail.com> wrote:
>  On 1/9/15 5:32 PM, sebb wrote:
> > On 9 January 2015 at 23:48, sebb 
> wrote:
> >> Of the last 6 runs, only 1 had a problem with unit test
> failures.
> >>
> >> All the builds ran on ubuntu3, apart from the failure
> which ran on H10.
> >> This may have some bearing on the result; I don't yet
> know.
> >>
> >> I had a quick look at 2 tests that failed:
> >>
> >> SimpleRegressionTest.testPerfect
> >>
> >> SimpleRegressionTest.testPerfectNegative
> >>
> >> Although the test case has some instance data, these
> particular tests
> >> do not use any, so it does not look like a concurrency
> issue in the
> >> unit test itself.
> >>
> >> The SimpleRegression class has mutable instance data,
> but the test
> >> cases create their own instance.
> >>
> >> I don't know anything about the math functions
> involved, but it looks
> >> as though Infinity might result from getSignificance()
> if
> >> getSlopeStdErr() returns 0, as the latter is used as a
> divisor. Or if
> >> the field sumXX is 0 because that is also used as a
> divisor.
> >>
> >> Maybe the H10 host has different floating point
> hardware?
> >>
> >> I'll try running some more tests on H10.
> > the build failed again on H10; exactly the same tests
> failed as before:
> >
> > This test:
> >
> https://builds.apache.org/job/Commons%20Math%20H10/1/console
> >
> > Previous failure:
> > https://builds.apache.org/job/Commons%20Math/14/console
>  This is actually a bug.  Thanks, sebb (and Jenkins)!
> 
>  Has been here since 1.x.  What is going on is that the
> data sets
>  used in the test cases are set up to be perfect linear
>  relationships, which should in fact lead to mean square
> error (and
>  hence slope standard error) equal to 0.  The Jenkins box
> must be
>  getting exact 0.  The funny thing is the test is there to
> validate
>  correct performance for models like this.  Its success
> unfortunately
>  depends on poor precision.
> 
>  I will open a JIRA for this.  I don't think it is a
> release blocker
>  for 3.4.1, as I am sure you would get the same thing in
> any earlier
>  version of [math].
> >>> OK good to know.
> >>>
> >>> I'll leave the H10 Jenkins job for now to make it easy to
> retest.
> >> My first guess here was wrong.  The infinities are being
> handled
> >> correctly for the JDKs I have.  Something must be going
> awry in the
> >> t distribution cumulative probability computation for +INF
> on the
> >> box that is failing.  Is there a way to find out exactly
> what JDK
> >> and OS version are being used?
> > I just committed a test that tests the t distribution
> computations
> > directly.  It seems to have run clean; but the other test
> ran clean
> > too.  Is there any way to force the build to use the host
> 

Re: [MATH] Jenkins unit test failure

[Thomas Neidhart]

jacoco is not the cause as the tests still fail when it is disabled.

Thomas

On Tue, Jan 13, 2015 at 10:52 AM, Thomas Neidhart  wrote:

> I did several tests by adding additional console output.
> The build was always running on H11 and sometimes it was working, while in
> other cases not.
>
> Inspecting the byte code did not show anything unusual, it looks correct.
> Maybe it is related to jacoco, as it adds a javaagent which manipulates
> bytecode during the execution.
>
> I will do further tests to see if there is a connection.
>
> Thomas
>
> On Tue, Jan 13, 2015 at 2:50 AM, sebb  wrote:
>
>> On 13 January 2015 at 01:12, sebb  wrote:
>> > On 13 January 2015 at 00:53, Phil Steitz  wrote:
>> >> On 1/12/15 5:44 PM, sebb wrote:
>> >>> On 12 January 2015 at 22:21, Thomas Neidhart <
>> thomas.neidh...@gmail.com> wrote:
>>  On 01/12/2015 11:17 PM, Phil Steitz wrote:
>> > On 1/12/15 2:30 PM, Thomas Neidhart wrote:
>> >> On 01/12/2015 10:26 PM, Thomas Neidhart wrote:
>> >>> On 01/12/2015 08:09 PM, Phil Steitz wrote:
>>  On 1/12/15 11:37 AM, sebb wrote:
>> > On 12 January 2015 at 18:11, Phil Steitz 
>> wrote:
>> >> On 1/12/15 10:50 AM, sebb wrote:
>> >>> On 11 January 2015 at 22:10, Phil Steitz <
>> phil.ste...@gmail.com> wrote:
>>  On 1/11/15 11:19 AM, Phil Steitz wrote:
>> > On 1/10/15 10:49 PM, Phil Steitz wrote:
>> >> On 1/9/15 6:09 PM, sebb wrote:
>> >>> On 10 January 2015 at 01:01, Phil Steitz <
>> phil.ste...@gmail.com> wrote:
>>  On 1/9/15 5:32 PM, sebb wrote:
>> > On 9 January 2015 at 23:48, sebb 
>> wrote:
>> >> Of the last 6 runs, only 1 had a problem with unit
>> test failures.
>> >>
>> >> All the builds ran on ubuntu3, apart from the failure
>> which ran on H10.
>> >> This may have some bearing on the result; I don't yet
>> know.
>> >>
>> >> I had a quick look at 2 tests that failed:
>> >>
>> >> SimpleRegressionTest.testPerfect
>> >>
>> >> SimpleRegressionTest.testPerfectNegative
>> >>
>> >> Although the test case has some instance data, these
>> particular tests
>> >> do not use any, so it does not look like a concurrency
>> issue in the
>> >> unit test itself.
>> >>
>> >> The SimpleRegression class has mutable instance data,
>> but the test
>> >> cases create their own instance.
>> >>
>> >> I don't know anything about the math functions
>> involved, but it looks
>> >> as though Infinity might result from getSignificance()
>> if
>> >> getSlopeStdErr() returns 0, as the latter is used as a
>> divisor. Or if
>> >> the field sumXX is 0 because that is also used as a
>> divisor.
>> >>
>> >> Maybe the H10 host has different floating point
>> hardware?
>> >>
>> >> I'll try running some more tests on H10.
>> > the build failed again on H10; exactly the same tests
>> failed as before:
>> >
>> > This test:
>> >
>> https://builds.apache.org/job/Commons%20Math%20H10/1/console
>> >
>> > Previous failure:
>> > https://builds.apache.org/job/Commons%20Math/14/console
>>  This is actually a bug.  Thanks, sebb (and Jenkins)!
>> 
>>  Has been here since 1.x.  What is going on is that the
>> data sets
>>  used in the test cases are set up to be perfect linear
>>  relationships, which should in fact lead to mean square
>> error (and
>>  hence slope standard error) equal to 0.  The Jenkins box
>> must be
>>  getting exact 0.  The funny thing is the test is there
>> to validate
>>  correct performance for models like this.  Its success
>> unfortunately
>>  depends on poor precision.
>> 
>>  I will open a JIRA for this.  I don't think it is a
>> release blocker
>>  for 3.4.1, as I am sure you would get the same thing in
>> any earlier
>>  version of [math].
>> >>> OK good to know.
>> >>>
>> >>> I'll leave the H10 Jenkins job for now to make it easy to
>> retest.
>> >> My first guess here was wrong.  The infinities are being
>> handled
>> >> correctly for the JDKs I have.  Something must be going
>> awry in the
>> >> t distribution cumulative probability computation for +INF
>> on the
>> >> box that is failing.  Is there a way to find out exactly
>> what JDK
>> >> and OS version a

[LANG] Re: Patch for review

[Benedikt Ritter]

Sebb, you have worked on the issue. Do you have time to take a look?

Benedikt

2015-01-13 10:06 GMT+01:00 Shweta Turakhia :

> Hi,
>  Can someone please take a look at the patch uploaded for
> https://issues.apache.org/jira/browse/LANG-1061
>
> I made the changes as discussed on the jira and updated the unit tests.
>
> Thanks,
> Shweta
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [Math] Maven profile for running the examples?

[Gilles]

On Thu, 8 Jan 2015 15:49:31 +, sebb wrote:
On 8 January 2015 at 11:59, Gilles  
wrote:

On Thu, 8 Jan 2015 01:20:20 +, sebb wrote:


On 8 January 2015 at 00:25, Gilles  
wrote:


On Wed, 7 Jan 2015 17:21:33 +, sebb wrote:



On 7 January 2015 at 17:12, Thomas Neidhart
 wrote:



On 01/07/2015 06:00 PM, sebb wrote:



On 7 January 2015 at 16:29, Thomas Neidhart

wrote:



On 01/07/2015 04:50 PM, sebb wrote:



On 7 January 2015 at 13:59, Gilles 


wrote:



[...]





I have pushed the change to the userguide. To execute the 
example

you do
the following:

 * go to commons-math folder, type mvn clean install
   this step is only needed if your local maven repository 
does

not
yet
   contain the latest commons-math snapshot
 * go to userguide folder (src/userguide), type mvn clean 
package

 * now you can run the examples like that:

java -cp 
target/commons-math3-examples-uber-3.5-SNAPSHOT.jar





org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison





Very nice.




Yes, however there is a caveat.
The uber jar must not be published, at least in its current 
form.
- it contains un-shaded classes that have different Maven 
coords (=>

jar hell)
- it does not have N&L files
- are the 3rd party jars AL compatible?




there is no intention to publish the uber jar.




OK.

There is another way to run the code without needing to 
generate the

jars:

cd src/userguide

mvn -q exec:java





-Dexec.mainClass=org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison




nice, did not know this trick before.


This uses Maven to resolve the dependencies.

Works very well for developer testing of examples.
However it is not so useful for end users as they would need 
Maven

and
the Math source.

The NET jar method works well because there are no external
dependencies, and the example jar is created in the same 
directory

as
the core jar it depends on.

The same approach would work for Math, but the user would 
have to

download the additional dependencies somehow.




the approach with exec:java is good enough imho, as >90% of 
the users

will have maven installed.




Agreed.
It's safe to assume that (see below for the proposed usage).



But they won't necessarily have the Math source.

On a whim I just tried creating a basic pom with only the
dependencies.
I added examples as another dependency.

This works fine with exec:java from any directory provided only 
that

the examples have been installed (or can be found from a repo)

A minor disadvantage of exec:java is one has to use properties 
for the

main class and arguments - the syntax is a bit awkward.




I did not follow the details (e.g. what is "uber"?) but IMHO, one 
simple



The uber jar is a jar that contains the examples classes and all 
its

dependencies.

enough way is enough; the simpler the "pom.xml" the better 
(perhaps with

a little README in the same directory).



The src/userguide/pom.xml compiles the examples and creates the 
uber jar.

The section that creates the uber jar could be dropped and it would
still be suitable for use with exec:java

the examples are also not published (yet), thus there is no way 
to run
the examples without downloading the source distribution (or 
checkout

the git repo).




Yes, but the code we are discussing is for the next release.




Not necessarily.
The first step was necessarily to be able to compile and run them
for ourselves.



OK

I think it would make sense to include the compiled examples in 
the

release as a separate jar.




IMO, the setup in the "src/userguide" can have at least two 
purposes

that are more useful than publishing the compiled examples:
 1. Generate reports (on various aspects of CM) to be integrated 
in

"userguide" document. [For this, the build must run the code
that generates the reports.]
 2. Publish source code of working examples. [For this, the RM
must of course ensure that the code is correct (i.e. compiles
and runs as expected).]

Providing compiled code is only useful if the examples are more
than just toy problems, and provide readily useful 
functionalities:

a library of real-world applications (in which the name "examples"
won't be appropriate anymore).  [We are not there yet (the idea of
real-world examples was proposed quite some time ago but did not
elicit any comment IIRC).]



By contrast the NET examples are all (or mostly) usable.


Points (1) and (2) would add to the resources which a newcomer
might like to read to get acquainted with the contents of the
library. The document should be readily available without a
prospective user having to run anything.



Well of course.



So we need to set up a list of desirable reports...
[One that comes to mind is a benchmark of FastMath.]


If the examples were extended to include useful utilities, then I
suspect you would find some people wanted to be able to run them
without needing to install Maven and a JDK.
In which case one way to do this is via a ub

Jenkins build is back to stable : Commons Math #31

[Apache Jenkins Server]

See 


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

Re: Jenkins build is still unstable: Commons Math #28

[sebb]

ububtu-1

On 13 January 2015 at 02:17, Apache Jenkins Server
 wrote:
> See 
>
>
> -
> 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: Jenkins build is back to stable : Commons Math #31

[sebb]

ubuntu3

On 13 January 2015 at 15:12, Apache Jenkins Server
 wrote:
> See 
>
>
> -
> 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: Jenkins build is still unstable: Commons Math #29

[sebb]

H11

On 13 January 2015 at 09:15, Apache Jenkins Server
 wrote:
> See 
>
>
> -
> 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] Maven profile for running the examples?

[sebb]

On 13 January 2015 at 12:44, Gilles  wrote:
> On Thu, 8 Jan 2015 15:49:31 +, sebb wrote:
>>
>> On 8 January 2015 at 11:59, Gilles  wrote:
>>>
>>> On Thu, 8 Jan 2015 01:20:20 +, sebb wrote:


 On 8 January 2015 at 00:25, Gilles  wrote:
>
>
> On Wed, 7 Jan 2015 17:21:33 +, sebb wrote:
>>
>>
>>
>> On 7 January 2015 at 17:12, Thomas Neidhart
>>  wrote:
>>>
>>>
>>>
>>> On 01/07/2015 06:00 PM, sebb wrote:



 On 7 January 2015 at 16:29, Thomas Neidhart
 
 wrote:
>
>
>
> On 01/07/2015 04:50 PM, sebb wrote:
>>
>>
>>
>> On 7 January 2015 at 13:59, Gilles 
>> wrote:
>
>
>
> [...]





 I have pushed the change to the userguide. To execute the
 example
 you do
 the following:

  * go to commons-math folder, type mvn clean install
this step is only needed if your local maven repository does
 not
 yet
contain the latest commons-math snapshot
  * go to userguide folder (src/userguide), type mvn clean
 package
  * now you can run the examples like that:

 java -cp target/commons-math3-examples-uber-3.5-SNAPSHOT.jar





 org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison
>>>
>>>
>>>
>>>
>>>
>>> Very nice.
>>
>>
>>
>>
>> Yes, however there is a caveat.
>> The uber jar must not be published, at least in its current form.
>> - it contains un-shaded classes that have different Maven coords
>> (=>
>> jar hell)
>> - it does not have N&L files
>> - are the 3rd party jars AL compatible?
>
>
>
>
> there is no intention to publish the uber jar.




 OK.

>> There is another way to run the code without needing to generate
>> the
>> jars:
>>
>> cd src/userguide
>>
>> mvn -q exec:java
>>
>>
>>
>>
>>
>>
>> -Dexec.mainClass=org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison
>
>
>
>
> nice, did not know this trick before.
>
>> This uses Maven to resolve the dependencies.
>>
>> Works very well for developer testing of examples.
>> However it is not so useful for end users as they would need Maven
>> and
>> the Math source.
>>
>> The NET jar method works well because there are no external
>> dependencies, and the example jar is created in the same directory
>> as
>> the core jar it depends on.
>>
>> The same approach would work for Math, but the user would have to
>> download the additional dependencies somehow.
>
>
>
>
> the approach with exec:java is good enough imho, as >90% of the
> users
> will have maven installed.
>
>
>
>
> Agreed.
> It's safe to assume that (see below for the proposed usage).
>

 But they won't necessarily have the Math source.

 On a whim I just tried creating a basic pom with only the
 dependencies.
 I added examples as another dependency.

 This works fine with exec:java from any directory provided only that
 the examples have been installed (or can be found from a repo)

 A minor disadvantage of exec:java is one has to use properties for
 the
 main class and arguments - the syntax is a bit awkward.
>
>
>
>
> I did not follow the details (e.g. what is "uber"?) but IMHO, one
> simple



 The uber jar is a jar that contains the examples classes and all its
 dependencies.

> enough way is enough; the simpler the "pom.xml" the better (perhaps
> with
> a little README in the same directory).



 The src/userguide/pom.xml compiles the examples and creates the uber
 jar.
 The section that creates the uber jar could be dropped and it would
 still be suitable for use with exec:java

>>> the examples are also not published (yet), thus there is no way to
>>> run
>>> the examples without downloading the source distribution (or checkout
>>> the git repo).
>>
>>
>>
>>
>> Yes, but the code we are discussing is for the next release.
>
>
>

Re: [Math] Maven profile for running the examples?

[Phil Steitz]

On 1/13/15 10:48 AM, sebb wrote:
> On 13 January 2015 at 12:44, Gilles  wrote:
>> On Thu, 8 Jan 2015 15:49:31 +, sebb wrote:
>>> On 8 January 2015 at 11:59, Gilles  wrote:
 On Thu, 8 Jan 2015 01:20:20 +, sebb wrote:
>
> On 8 January 2015 at 00:25, Gilles  wrote:
>>
>> On Wed, 7 Jan 2015 17:21:33 +, sebb wrote:
>>>
>>>
>>> On 7 January 2015 at 17:12, Thomas Neidhart
>>>  wrote:


 On 01/07/2015 06:00 PM, sebb wrote:
>
>
> On 7 January 2015 at 16:29, Thomas Neidhart
> 
> wrote:
>>
>>
>> On 01/07/2015 04:50 PM, sebb wrote:
>>>
>>>
>>> On 7 January 2015 at 13:59, Gilles 
>>> wrote:
>>
>>
>> [...]
>
>
>
>
> I have pushed the change to the userguide. To execute the
> example
> you do
> the following:
>
>  * go to commons-math folder, type mvn clean install
>this step is only needed if your local maven repository does
> not
> yet
>contain the latest commons-math snapshot
>  * go to userguide folder (src/userguide), type mvn clean
> package
>  * now you can run the examples like that:
>
> java -cp target/commons-math3-examples-uber-3.5-SNAPSHOT.jar
>
>
>
>
>
> org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison




 Very nice.
>>>
>>>
>>>
>>> Yes, however there is a caveat.
>>> The uber jar must not be published, at least in its current form.
>>> - it contains un-shaded classes that have different Maven coords
>>> (=>
>>> jar hell)
>>> - it does not have N&L files
>>> - are the 3rd party jars AL compatible?
>>
>>
>>
>> there is no intention to publish the uber jar.
>
>
>
> OK.
>
>>> There is another way to run the code without needing to generate
>>> the
>>> jars:
>>>
>>> cd src/userguide
>>>
>>> mvn -q exec:java
>>>
>>>
>>>
>>>
>>>
>>>
>>> -Dexec.mainClass=org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison
>>
>>
>>
>> nice, did not know this trick before.
>>
>>> This uses Maven to resolve the dependencies.
>>>
>>> Works very well for developer testing of examples.
>>> However it is not so useful for end users as they would need Maven
>>> and
>>> the Math source.
>>>
>>> The NET jar method works well because there are no external
>>> dependencies, and the example jar is created in the same directory
>>> as
>>> the core jar it depends on.
>>>
>>> The same approach would work for Math, but the user would have to
>>> download the additional dependencies somehow.
>>
>>
>>
>> the approach with exec:java is good enough imho, as >90% of the
>> users
>> will have maven installed.
>>
>>
>>
>> Agreed.
>> It's safe to assume that (see below for the proposed usage).
>>
> But they won't necessarily have the Math source.
>
> On a whim I just tried creating a basic pom with only the
> dependencies.
> I added examples as another dependency.
>
> This works fine with exec:java from any directory provided only that
> the examples have been installed (or can be found from a repo)
>
> A minor disadvantage of exec:java is one has to use properties for
> the
> main class and arguments - the syntax is a bit awkward.
>>
>>
>>
>> I did not follow the details (e.g. what is "uber"?) but IMHO, one
>> simple
>
>
> The uber jar is a jar that contains the examples classes and all its
> dependencies.
>
>> enough way is enough; the simpler the "pom.xml" the better (perhaps
>> with
>> a little README in the same directory).
>
>
> The src/userguide/pom.xml compiles the examples and creates the uber
> jar.
> The section that creates the uber jar could be dropped and it would
> still be suitable for use with exec:java
>
 the examples are also not published (yet), thus there is no way to
 run
 the examples without downloading the source distribution (or checkout
 the git repo).
>>>
>>>
>>>
>>> Yes, but the code we are discussing is for the next release.
>

Re: [Math] Maven profile for running the examples?

[Gilles]

On Tue, 13 Jan 2015 11:03:42 -0700, Phil Steitz wrote:

On 1/13/15 10:48 AM, sebb wrote:
On 13 January 2015 at 12:44, Gilles  
wrote:

On Thu, 8 Jan 2015 15:49:31 +, sebb wrote:
On 8 January 2015 at 11:59, Gilles  
wrote:

On Thu, 8 Jan 2015 01:20:20 +, sebb wrote:


On 8 January 2015 at 00:25, Gilles 
 wrote:


On Wed, 7 Jan 2015 17:21:33 +, sebb wrote:



On 7 January 2015 at 17:12, Thomas Neidhart
 wrote:



On 01/07/2015 06:00 PM, sebb wrote:



On 7 January 2015 at 16:29, Thomas Neidhart

wrote:



On 01/07/2015 04:50 PM, sebb wrote:



On 7 January 2015 at 13:59, Gilles 


wrote:



[...]





I have pushed the change to the userguide. To execute 
the

example
you do
the following:

 * go to commons-math folder, type mvn clean install
   this step is only needed if your local maven 
repository does

not
yet
   contain the latest commons-math snapshot
 * go to userguide folder (src/userguide), type mvn 
clean

package
 * now you can run the examples like that:

java -cp 
target/commons-math3-examples-uber-3.5-SNAPSHOT.jar







org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison





Very nice.




Yes, however there is a caveat.
The uber jar must not be published, at least in its 
current form.
- it contains un-shaded classes that have different Maven 
coords

(=>
jar hell)
- it does not have N&L files
- are the 3rd party jars AL compatible?




there is no intention to publish the uber jar.




OK.

There is another way to run the code without needing to 
generate

the
jars:

cd src/userguide

mvn -q exec:java







-Dexec.mainClass=org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison




nice, did not know this trick before.


This uses Maven to resolve the dependencies.

Works very well for developer testing of examples.
However it is not so useful for end users as they would 
need Maven

and
the Math source.

The NET jar method works well because there are no 
external
dependencies, and the example jar is created in the same 
directory

as
the core jar it depends on.

The same approach would work for Math, but the user would 
have to

download the additional dependencies somehow.




the approach with exec:java is good enough imho, as >90% of 
the

users
will have maven installed.




Agreed.
It's safe to assume that (see below for the proposed usage).


But they won't necessarily have the Math source.

On a whim I just tried creating a basic pom with only the
dependencies.
I added examples as another dependency.

This works fine with exec:java from any directory provided 
only that
the examples have been installed (or can be found from a 
repo)


A minor disadvantage of exec:java is one has to use 
properties for

the
main class and arguments - the syntax is a bit awkward.




I did not follow the details (e.g. what is "uber"?) but IMHO, 
one

simple



The uber jar is a jar that contains the examples classes and all 
its

dependencies.

enough way is enough; the simpler the "pom.xml" the better 
(perhaps

with
a little README in the same directory).



The src/userguide/pom.xml compiles the examples and creates the 
uber

jar.
The section that creates the uber jar could be dropped and it 
would

still be suitable for use with exec:java

the examples are also not published (yet), thus there is no 
way to

run
the examples without downloading the source distribution (or 
checkout

the git repo).




Yes, but the code we are discussing is for the next release.




Not necessarily.
The first step was necessarily to be able to compile and run 
them

for ourselves.



OK

I think it would make sense to include the compiled examples 
in the

release as a separate jar.




IMO, the setup in the "src/userguide" can have at least two 
purposes

that are more useful than publishing the compiled examples:
 1. Generate reports (on various aspects of CM) to be 
integrated in
"userguide" document. [For this, the build must run the 
code

that generates the reports.]
 2. Publish source code of working examples. [For this, the RM
must of course ensure that the code is correct (i.e. 
compiles

and runs as expected).]

Providing compiled code is only useful if the examples are more
than just toy problems, and provide readily useful 
functionalities:
a library of real-world applications (in which the name 
"examples"
won't be appropriate anymore).  [We are not there yet (the idea 
of
real-world examples was proposed quite some time ago but did 
not

elicit any comment IIRC).]



By contrast the NET examples are all (or mostly) usable.


Points (1) and (2) would add to the resources which a newcomer
might like to read to get acquainted with the contents of the
library. The document should be readily available without a
prospective user having to run anything.


Well of course.



So we need to set up a list of desirable reports...
[One that comes to mind is a benchmark of FastMath.]

If the examples were extended to include useful utilities, then 
I

s

Re: [VOTE] Release Aoache Commons Validator 1.4.1 based on RC3

[Benedikt Ritter]

2015-01-10 19:51 GMT+01:00 Benedikt Ritter :

> Hi all,
>
> we have fixed the issues which where found in RC2 (and a lot more ;-)) so
> I'd like to call a new vote to release Apache Commons Validator 1.4.1 based
> on RC3.
>
> Changes between RC2 and RC3:
> - Removed dependency to methods > Java 1.4
> - [VALIDATOR-342] URLValidator returns false for http://example.rocks
> - [VALIDATOR-235] UrlValidator rejects url with Unicode characters in
> domain label or TLD
> - [VALIDATOR-339] URLValidator fails validating domain names with a
> trailing period, which are valid.
> - [VALIDATOR-306] DomainValidator accepts labels longer than 63 chars and
> domain name lengths exceeding 255 chars
> - [VALIDATOR-349] TLD tables should be pre-sorted
> - [VALIDATOR-290] Create new url validation using rfc3986 and IDN - added
> new test
> - [VALIDATOR-350] Should "x.root" validate as a domain name? Removed
> "root" from TLD list. Also "um" and "yu" as they are currently "Not
> assigned"
> - [VALIDATOR-308] Logical errors in util.Flags affecting check of multiple
> flags as well as flag 64
> - [VALIDATOR-344] AbstractCheckDigit class does not fully test invalid
> strings. Fix up the testCalculateInvalid() invalid method to allow for
> either invalid checksum or syntax (CheckDigitException) error when testing
> the entries in the invalid array.
> - [VALIDATOR-297] Punycode url is not valid. Top-level domain regex
> matching was wrong; did not allow embedded "-" as per RFC2396
> - [VALIDATOR-334] UrlValidator: isValidAuthority() returning true when
> supplied authority validator fails
> - [VALIDATOR-309] UrlValidator does not validate uppercase URL schemes
> - [VALIDATOR-343] Doc URL update for broken link
>
> Changes between RC1 and RC2:
> - [VALIDATOR-307] - isValid checks if the given address is only IPV4
> address and not IPV6
> - [VALIDATOR-347] - toLowerCase() method is Locale-sensitive and should
> not be used
> - [VALIDATOR-348] - Update TLD list to latest version (Version 2014123000)
> - [VALIDATOR-336] - CUSIPCheckDigit thinks invalid CUSIP is valid.
> - [VALIDATOR-345] - ISINCheckDigit fails to reject invalid (non-numeric)
> check digits
> - [VALIDATOR-346] - SedolCheckDigit fails to reject invalid (non-numeric)
> check digits
> - Removed STATUS.html
> - Added README.md to binary and source distribution
> - Fixed encoding of source files in build by setting commons.encoding
> property
> - Fixed JIRA report to contain the issues of the project
> - Reverted dependency to commons-beanutils to 1.8.3 since this is the
> latest JDK 1.4 compatible release
> - Added JDK requirements to release notes.
>
> Validator 1.4.1-RC2 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/validator/ (svn revision
> 7682)
>
> The tag is here:
>
> http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_4_1_RC3/
>  (svn
> revision 1650789)
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1076/commons-validator/commons-validator/1.4.1/
>
> Details of changes since 1.4 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/validator/RELEASE-NOTES.txt
>
> I have tested this with JDK 1.6, 1.7 and 1.8 using maven 3.2.5.
>
> Site (some links my be broken but will be fixed when the site is deployed):
>   http://people.apache.org/~britter/validator-1.4.1-RC3/
>
> Clirr Report:
>   http://people.apache.org/~britter/validator-1.4.1-RC3/clirr-report.html
>
> RAT Report:
>   http://people.apache.org/~britter/validator-1.4.1-RC3/rat-report.html
>
> Keys:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review this release candidate and vote.
> This vote will close no sooner than 72 hours from now, i.e. after
> 2015/01/04 19:00CET
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> I'd like to add that all thanks for this RC goes to sebb, who has invested
> a lot of time to get this right.
> Thanks!
>

Here is my +1.


>
> Benedikt
>
>
> --
> 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] Maven profile for running the examples?

[sebb]

On 13 January 2015 at 18:40, Gilles  wrote:
> On Tue, 13 Jan 2015 11:03:42 -0700, Phil Steitz wrote:
>>
>> On 1/13/15 10:48 AM, sebb wrote:
>>>
>>> On 13 January 2015 at 12:44, Gilles  wrote:

 On Thu, 8 Jan 2015 15:49:31 +, sebb wrote:
>
> On 8 January 2015 at 11:59, Gilles 
> wrote:
>>
>> On Thu, 8 Jan 2015 01:20:20 +, sebb wrote:
>>>
>>>
>>> On 8 January 2015 at 00:25, Gilles 
>>> wrote:


 On Wed, 7 Jan 2015 17:21:33 +, sebb wrote:
>
>
>
> On 7 January 2015 at 17:12, Thomas Neidhart
>  wrote:
>>
>>
>>
>> On 01/07/2015 06:00 PM, sebb wrote:
>>>
>>>
>>>
>>> On 7 January 2015 at 16:29, Thomas Neidhart
>>> 
>>> wrote:



 On 01/07/2015 04:50 PM, sebb wrote:
>
>
>
> On 7 January 2015 at 13:59, Gilles
> 
> wrote:



 [...]
>>>
>>>
>>>
>>>
>>>
>>> I have pushed the change to the userguide. To execute the
>>> example
>>> you do
>>> the following:
>>>
>>>  * go to commons-math folder, type mvn clean install
>>>this step is only needed if your local maven repository
>>> does
>>> not
>>> yet
>>>contain the latest commons-math snapshot
>>>  * go to userguide folder (src/userguide), type mvn clean
>>> package
>>>  * now you can run the examples like that:
>>>
>>> java -cp target/commons-math3-examples-uber-3.5-SNAPSHOT.jar
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison
>>
>>
>>
>>
>>
>> Very nice.
>
>
>
>
> Yes, however there is a caveat.
> The uber jar must not be published, at least in its current
> form.
> - it contains un-shaded classes that have different Maven
> coords
> (=>
> jar hell)
> - it does not have N&L files
> - are the 3rd party jars AL compatible?




 there is no intention to publish the uber jar.
>>>
>>>
>>>
>>>
>>> OK.
>>>
> There is another way to run the code without needing to
> generate
> the
> jars:
>
> cd src/userguide
>
> mvn -q exec:java
>
>
>
>
>
>
>
>
> -Dexec.mainClass=org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison




 nice, did not know this trick before.

> This uses Maven to resolve the dependencies.
>
> Works very well for developer testing of examples.
> However it is not so useful for end users as they would need
> Maven
> and
> the Math source.
>
> The NET jar method works well because there are no external
> dependencies, and the example jar is created in the same
> directory
> as
> the core jar it depends on.
>
> The same approach would work for Math, but the user would have
> to
> download the additional dependencies somehow.




 the approach with exec:java is good enough imho, as >90% of the
 users
 will have maven installed.




 Agreed.
 It's safe to assume that (see below for the proposed usage).

>>> But they won't necessarily have the Math source.
>>>
>>> On a whim I just tried creating a basic pom with only the
>>> dependencies.
>>> I added examples as another dependency.
>>>
>>> This works fine with exec:java from any directory provided only
>>> that
>>> the examples have been installed (or can be found from a repo)
>>>
>>> A minor disadvantage of exec:java is one has to use properties
>>> for
>>> the
>>> main class and arguments - the syntax is a bit awkward.




 I did not fol

[RESULT][VOTE] Release Apache Commons Validator 1.4.1 based on RC3

[Benedikt Ritter]

2015-01-10 19:51 GMT+01:00 Benedikt Ritter :

> Hi all,
>
> we have fixed the issues which where found in RC2 (and a lot more ;-)) so
> I'd like to call a new vote to release Apache Commons Validator 1.4.1 based
> on RC3.
>
> Changes between RC2 and RC3:
> - Removed dependency to methods > Java 1.4
> - [VALIDATOR-342] URLValidator returns false for http://example.rocks
> - [VALIDATOR-235] UrlValidator rejects url with Unicode characters in
> domain label or TLD
> - [VALIDATOR-339] URLValidator fails validating domain names with a
> trailing period, which are valid.
> - [VALIDATOR-306] DomainValidator accepts labels longer than 63 chars and
> domain name lengths exceeding 255 chars
> - [VALIDATOR-349] TLD tables should be pre-sorted
> - [VALIDATOR-290] Create new url validation using rfc3986 and IDN - added
> new test
> - [VALIDATOR-350] Should "x.root" validate as a domain name? Removed
> "root" from TLD list. Also "um" and "yu" as they are currently "Not
> assigned"
> - [VALIDATOR-308] Logical errors in util.Flags affecting check of multiple
> flags as well as flag 64
> - [VALIDATOR-344] AbstractCheckDigit class does not fully test invalid
> strings. Fix up the testCalculateInvalid() invalid method to allow for
> either invalid checksum or syntax (CheckDigitException) error when testing
> the entries in the invalid array.
> - [VALIDATOR-297] Punycode url is not valid. Top-level domain regex
> matching was wrong; did not allow embedded "-" as per RFC2396
> - [VALIDATOR-334] UrlValidator: isValidAuthority() returning true when
> supplied authority validator fails
> - [VALIDATOR-309] UrlValidator does not validate uppercase URL schemes
> - [VALIDATOR-343] Doc URL update for broken link
>
> Changes between RC1 and RC2:
> - [VALIDATOR-307] - isValid checks if the given address is only IPV4
> address and not IPV6
> - [VALIDATOR-347] - toLowerCase() method is Locale-sensitive and should
> not be used
> - [VALIDATOR-348] - Update TLD list to latest version (Version 2014123000)
> - [VALIDATOR-336] - CUSIPCheckDigit thinks invalid CUSIP is valid.
> - [VALIDATOR-345] - ISINCheckDigit fails to reject invalid (non-numeric)
> check digits
> - [VALIDATOR-346] - SedolCheckDigit fails to reject invalid (non-numeric)
> check digits
> - Removed STATUS.html
> - Added README.md to binary and source distribution
> - Fixed encoding of source files in build by setting commons.encoding
> property
> - Fixed JIRA report to contain the issues of the project
> - Reverted dependency to commons-beanutils to 1.8.3 since this is the
> latest JDK 1.4 compatible release
> - Added JDK requirements to release notes.
>
> Validator 1.4.1-RC2 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/validator/ (svn revision
> 7682)
>
> The tag is here:
>
> http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_4_1_RC3/
>  (svn
> revision 1650789)
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1076/commons-validator/commons-validator/1.4.1/
>
> Details of changes since 1.4 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/validator/RELEASE-NOTES.txt
>
> I have tested this with JDK 1.6, 1.7 and 1.8 using maven 3.2.5.
>
> Site (some links my be broken but will be fixed when the site is deployed):
>   http://people.apache.org/~britter/validator-1.4.1-RC3/
>
> Clirr Report:
>   http://people.apache.org/~britter/validator-1.4.1-RC3/clirr-report.html
>
> RAT Report:
>   http://people.apache.org/~britter/validator-1.4.1-RC3/rat-report.html
>
> Keys:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review this release candidate and vote.
> This vote will close no sooner than 72 hours from now, i.e. after
> 2015/01/04 19:00CET
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> I'd like to add that all thanks for this RC goes to sebb, who has invested
> a lot of time to get this right.
> Thanks!
>

This vote passes with the following votes:

Gary Gregory: +1
Sebb: +1
Bruno Kinoshita: +1 (non-binding)
Luc Maisonobe: +0
Benedikt Ritter: +1

James Carman also voted +1, but I'm not sure wether it was for the RC or
just as a sign of agreement to a previous statement in this thread, so I'm
not counting his vote in. James please correct me, if you intended to vote
for the release.

I'm going to push the artifacts and write an announcement soon.

Thanks to all who reviewed this and the last RCs and to those who helped
fixing the problems we found during the other votes.

Benedikt


>
> Benedikt
>
>
> --
> 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] Jenkins unit test failure

[Phil Steitz]

On 1/12/15 3:21 PM, Thomas Neidhart wrote:
> On 01/12/2015 11:17 PM, Phil Steitz wrote:
>> On 1/12/15 2:30 PM, Thomas Neidhart wrote:
>>> On 01/12/2015 10:26 PM, Thomas Neidhart wrote:
 On 01/12/2015 08:09 PM, Phil Steitz wrote:
> On 1/12/15 11:37 AM, sebb wrote:
>> On 12 January 2015 at 18:11, Phil Steitz  wrote:
>>> On 1/12/15 10:50 AM, sebb wrote:
 On 11 January 2015 at 22:10, Phil Steitz  wrote:
> On 1/11/15 11:19 AM, Phil Steitz wrote:
>> On 1/10/15 10:49 PM, Phil Steitz wrote:
>>> On 1/9/15 6:09 PM, sebb wrote:
 On 10 January 2015 at 01:01, Phil Steitz  
 wrote:
> On 1/9/15 5:32 PM, sebb wrote:
>> On 9 January 2015 at 23:48, sebb  wrote:
>>> Of the last 6 runs, only 1 had a problem with unit test 
>>> failures.
>>>
>>> All the builds ran on ubuntu3, apart from the failure which ran 
>>> on H10.
>>> This may have some bearing on the result; I don't yet know.
>>>
>>> I had a quick look at 2 tests that failed:
>>>
>>> SimpleRegressionTest.testPerfect
>>>
>>> SimpleRegressionTest.testPerfectNegative
>>>
>>> Although the test case has some instance data, these particular 
>>> tests
>>> do not use any, so it does not look like a concurrency issue in 
>>> the
>>> unit test itself.
>>>
>>> The SimpleRegression class has mutable instance data, but the 
>>> test
>>> cases create their own instance.
>>>
>>> I don't know anything about the math functions involved, but it 
>>> looks
>>> as though Infinity might result from getSignificance() if
>>> getSlopeStdErr() returns 0, as the latter is used as a divisor. 
>>> Or if
>>> the field sumXX is 0 because that is also used as a divisor.
>>>
>>> Maybe the H10 host has different floating point hardware?
>>>
>>> I'll try running some more tests on H10.
>> the build failed again on H10; exactly the same tests failed as 
>> before:
>>
>> This test:
>> https://builds.apache.org/job/Commons%20Math%20H10/1/console
>>
>> Previous failure:
>> https://builds.apache.org/job/Commons%20Math/14/console
> This is actually a bug.  Thanks, sebb (and Jenkins)!
>
> Has been here since 1.x.  What is going on is that the data sets
> used in the test cases are set up to be perfect linear
> relationships, which should in fact lead to mean square error (and
> hence slope standard error) equal to 0.  The Jenkins box must be
> getting exact 0.  The funny thing is the test is there to validate
> correct performance for models like this.  Its success 
> unfortunately
> depends on poor precision.
>
> I will open a JIRA for this.  I don't think it is a release 
> blocker
> for 3.4.1, as I am sure you would get the same thing in any 
> earlier
> version of [math].
 OK good to know.

 I'll leave the H10 Jenkins job for now to make it easy to retest.
>>> My first guess here was wrong.  The infinities are being handled
>>> correctly for the JDKs I have.  Something must be going awry in the
>>> t distribution cumulative probability computation for +INF on the
>>> box that is failing.  Is there a way to find out exactly what JDK
>>> and OS version are being used?
>> I just committed a test that tests the t distribution computations
>> directly.  It seems to have run clean; but the other test ran clean
>> too.  Is there any way to force the build to use the host that fails?
> I can't make any sense of what is going on with the Jenkins builds.
> Clean runs and then lots of errors.  This one explains the
> SimpleRegression "problem" (which is not a problem with that class
> at least)
>
> testCumulativeProbablilityExtremes(org.apache.commons.math3.distribution.TDistributionTest)
>   Time elapsed: 0.001 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<1.0> but was:<-Infinity>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:494)
> at org.junit.Assert.assertEquals(Assert.java:592)
> at 
> org.apache.commons.math3.distribution.TDistributionTest.testCumulativeProbablilityExtremes(TDistributionTest.

[continuum] BUILD FAILURE: Apache Commons Validator - Apache Commons (Test if can build / test with Java 1.5)

[Apache Continuum]

Online report : 
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=39209&projectId=106

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Tue 13 Jan 2015 21:20:37 +
  Finished at: Tue 13 Jan 2015 21:20:47 +
  Total time: 9s
  Build Trigger: Schedule
  Build Number: 132
  Exit code: 1
  Building machine hostname: continuum-vm
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_32"
  OpenJDK Runtime Environment (IcedTea6 1.13.4) 
(6b32-1.13.4-4ubuntu0.12.04.2)
  OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)

  Builder version :
  Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 
2013-02-19 13:51:28+)
  Maven home: /opt/apache-maven-3.0.5
  Java version: 1.6.0_32, vendor: Sun Microsystems Inc.
  Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
  Default locale: en_US, platform encoding: ANSI_X3.4-1968
  OS name: "linux", version: "3.2.0-67-generic", arch: "amd64", family: 
"unix"


SCM Changes:

Changed: britter @ Tue 13 Jan 2015 20:28:08 +
Comment: VALIDATOR-355: Update to Java 6
Files changed:
  /commons/proper/validator/trunk/pom.xml ( 1651474 )
  /commons/proper/validator/trunk/src/changes/changes.xml ( 1651474 )

Changed: britter @ Tue 13 Jan 2015 20:29:05 +
Comment: Remove Java 1.4 work around
Files changed:
  
/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
 ( 1651475 )

Changed: britter @ Tue 13 Jan 2015 20:32:15 +
Comment: Use String.contains(String) instead of String.indexOf(String) != -1
Files changed:
  
/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/CreditCardValidator.java
 ( 1651476 )
  
/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/InetAddressValidator.java
 ( 1651476 )
  
/commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/CreditCardValidatorTest.java
 ( 1651476 )
  
/commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/GenericValidatorImpl.java
 ( 1651476 )

Changed: britter @ Tue 13 Jan 2015 20:39:58 +
Comment: Generics and enhanced for loop
Files changed:
  
/commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/checkdigit/AbstractCheckDigitTest.java
 ( 1651480 )

Changed: britter @ Tue 13 Jan 2015 20:44:10 +
Comment: Generics and enhanced for loops
Files changed:
  
/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/CreditCardValidator.java
 ( 1651483 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 3.0.5
Description: Test if can build / test with Java 1.5


Test Summary:

Tests: 0
Failures: 0
Errors: 0
Total time: 0.0




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

Re: [MATH] Jenkins unit test failure

[Thomas Neidhart]

On 01/13/2015 09:01 PM, Phil Steitz wrote:
> On 1/12/15 3:21 PM, Thomas Neidhart wrote:
>> On 01/12/2015 11:17 PM, Phil Steitz wrote:
>>> On 1/12/15 2:30 PM, Thomas Neidhart wrote:
 On 01/12/2015 10:26 PM, Thomas Neidhart wrote:
> On 01/12/2015 08:09 PM, Phil Steitz wrote:
>> On 1/12/15 11:37 AM, sebb wrote:
>>> On 12 January 2015 at 18:11, Phil Steitz  wrote:
 On 1/12/15 10:50 AM, sebb wrote:
> On 11 January 2015 at 22:10, Phil Steitz  
> wrote:
>> On 1/11/15 11:19 AM, Phil Steitz wrote:
>>> On 1/10/15 10:49 PM, Phil Steitz wrote:
 On 1/9/15 6:09 PM, sebb wrote:
> On 10 January 2015 at 01:01, Phil Steitz  
> wrote:
>> On 1/9/15 5:32 PM, sebb wrote:
>>> On 9 January 2015 at 23:48, sebb  wrote:
 Of the last 6 runs, only 1 had a problem with unit test 
 failures.

 All the builds ran on ubuntu3, apart from the failure which 
 ran on H10.
 This may have some bearing on the result; I don't yet know.

 I had a quick look at 2 tests that failed:

 SimpleRegressionTest.testPerfect

 SimpleRegressionTest.testPerfectNegative

 Although the test case has some instance data, these 
 particular tests
 do not use any, so it does not look like a concurrency issue 
 in the
 unit test itself.

 The SimpleRegression class has mutable instance data, but the 
 test
 cases create their own instance.

 I don't know anything about the math functions involved, but 
 it looks
 as though Infinity might result from getSignificance() if
 getSlopeStdErr() returns 0, as the latter is used as a 
 divisor. Or if
 the field sumXX is 0 because that is also used as a divisor.

 Maybe the H10 host has different floating point hardware?

 I'll try running some more tests on H10.
>>> the build failed again on H10; exactly the same tests failed as 
>>> before:
>>>
>>> This test:
>>> https://builds.apache.org/job/Commons%20Math%20H10/1/console
>>>
>>> Previous failure:
>>> https://builds.apache.org/job/Commons%20Math/14/console
>> This is actually a bug.  Thanks, sebb (and Jenkins)!
>>
>> Has been here since 1.x.  What is going on is that the data sets
>> used in the test cases are set up to be perfect linear
>> relationships, which should in fact lead to mean square error 
>> (and
>> hence slope standard error) equal to 0.  The Jenkins box must be
>> getting exact 0.  The funny thing is the test is there to 
>> validate
>> correct performance for models like this.  Its success 
>> unfortunately
>> depends on poor precision.
>>
>> I will open a JIRA for this.  I don't think it is a release 
>> blocker
>> for 3.4.1, as I am sure you would get the same thing in any 
>> earlier
>> version of [math].
> OK good to know.
>
> I'll leave the H10 Jenkins job for now to make it easy to retest.
 My first guess here was wrong.  The infinities are being handled
 correctly for the JDKs I have.  Something must be going awry in the
 t distribution cumulative probability computation for +INF on the
 box that is failing.  Is there a way to find out exactly what JDK
 and OS version are being used?
>>> I just committed a test that tests the t distribution computations
>>> directly.  It seems to have run clean; but the other test ran clean
>>> too.  Is there any way to force the build to use the host that 
>>> fails?
>> I can't make any sense of what is going on with the Jenkins builds.
>> Clean runs and then lots of errors.  This one explains the
>> SimpleRegression "problem" (which is not a problem with that class
>> at least)
>>
>> testCumulativeProbablilityExtremes(org.apache.commons.math3.distribution.TDistributionTest)
>>   Time elapsed: 0.001 sec  <<< FAILURE!
>> java.lang.AssertionError: expected:<1.0> but was:<-Infinity>
>> at org.junit.Assert.fail(Assert.java:88)
>> at org.junit.Assert.failNotEquals(Assert.java:743)
>> at org.junit.Assert.assertEquals(Assert.java:494)
>>

[continuum] BUILD FAILURE: Apache Commons Validator - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

[Apache Continuum]

Online report : 
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=39210&projectId=106

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Tue 13 Jan 2015 21:36:03 +
  Finished at: Tue 13 Jan 2015 21:36:31 +
  Total time: 27s
  Build Trigger: Forced
  Build Number: 132
  Exit code: 1
  Building machine hostname: continuum-vm
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_32"
  OpenJDK Runtime Environment (IcedTea6 1.13.4) 
(6b32-1.13.4-4ubuntu0.12.04.2)
  OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)

  Builder version :
  Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 
2013-02-19 13:51:28+)
  Maven home: /opt/apache-maven-3.0.5
  Java version: 1.6.0_32, vendor: Sun Microsystems Inc.
  Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
  Default locale: en_US, platform encoding: ANSI_X3.4-1968
  OS name: "linux", version: "3.2.0-67-generic", arch: "amd64", family: 
"unix"


SCM Changes:

Changed: britter @ Tue 13 Jan 2015 20:28:08 +
Comment: VALIDATOR-355: Update to Java 6
Files changed:
  /commons/proper/validator/trunk/pom.xml ( 1651474 )
  /commons/proper/validator/trunk/src/changes/changes.xml ( 1651474 )

Changed: britter @ Tue 13 Jan 2015 20:29:05 +
Comment: Remove Java 1.4 work around
Files changed:
  
/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
 ( 1651475 )

Changed: britter @ Tue 13 Jan 2015 20:32:15 +
Comment: Use String.contains(String) instead of String.indexOf(String) != -1
Files changed:
  
/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/CreditCardValidator.java
 ( 1651476 )
  
/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/InetAddressValidator.java
 ( 1651476 )
  
/commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/CreditCardValidatorTest.java
 ( 1651476 )
  
/commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/GenericValidatorImpl.java
 ( 1651476 )

Changed: britter @ Tue 13 Jan 2015 20:39:58 +
Comment: Generics and enhanced for loop
Files changed:
  
/commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/checkdigit/AbstractCheckDigitTest.java
 ( 1651480 )

Changed: britter @ Tue 13 Jan 2015 20:44:10 +
Comment: Generics and enhanced for loops
Files changed:
  
/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/CreditCardValidator.java
 ( 1651483 )

Changed: britter @ Tue 13 Jan 2015 19:47:27 +
Comment: Bump version numbers for next development iteration
Files changed:
  /commons/proper/validator/trunk/README.md ( 1651457 )
  /commons/proper/validator/trunk/pom.xml ( 1651457 )
  /commons/proper/validator/trunk/src/changes/changes.xml ( 1651457 )

Changed: britter @ Tue 13 Jan 2015 19:57:19 +
Comment: Add link to 1.4.1 JavaDocs
Files changed:
  /commons/proper/validator/trunk/src/site/site.xml ( 1651460 )

Changed: britter @ Tue 13 Jan 2015 20:07:27 +
Comment: Update doap for latest release (and the one before)
Files changed:
  /commons/proper/validator/trunk/doap_validator.rdf ( 1651463 )

Changed: britter @ Tue 13 Jan 2015 20:12:04 +
Comment: Update link to apidocs
Files changed:
  /commons/proper/validator/trunk/README.md ( 1651465 )

Changed: britter @ Tue 13 Jan 2015 20:12:55 +
Comment: Validator uses a three digit version number scheme
Files changed:
  /commons/proper/validator/trunk/pom.xml ( 1651466 )

Changed: britter @ Mon 12 Jan 2015 09:09:30 +
Comment: Update copyright year
Files changed:
  /commons/proper/validator/trunk/NOTICE.txt ( 1651048 )

Changed: britter @ Sat 10 Jan 2015 18:05:16 +
Comment: Checkstyle: constant names should follow naming conventions
Files changed:
  
/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
 ( 1650777 )

Changed: britter @ Sat 10 Jan 2015 18:09:38 +
Comment: Fix typo
Files changed:
  /commons/proper/validator/trunk/RELEASE-NOTES.txt ( 1650782 )

Changed: britter @ Sat 10 Jan 2015 18:14:13 +
Comment: Add since tag for newly added method in InetAddressValidator
Files changed:
  
/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/InetAddressValidator.java
 ( 1650785 )

Changed: britter @ Sat 10 Jan 2015 18:15:18 +
Comment: Bump RC number
Files changed:
  /commons/proper/validator/trunk/pom.xml ( 1650786 )

Changed: britter @ Sat 10 Jan 2015 18:17:54 +
Comment: Add missing build properties (according to release guide)
Files changed:
  /commons/proper/validator/trunk/pom.xml ( 1650787 )

Changed: sebb @ Tue 6 Jan 2015 23:50:46 +
Commen

Re: [MATH] Jenkins unit test failure

[sebb]

On 13 January 2015 at 21:26, Thomas Neidhart  wrote:
> On 01/13/2015 09:01 PM, Phil Steitz wrote:
>> On 1/12/15 3:21 PM, Thomas Neidhart wrote:
>>> On 01/12/2015 11:17 PM, Phil Steitz wrote:
 On 1/12/15 2:30 PM, Thomas Neidhart wrote:
> On 01/12/2015 10:26 PM, Thomas Neidhart wrote:
>> On 01/12/2015 08:09 PM, Phil Steitz wrote:
>>> On 1/12/15 11:37 AM, sebb wrote:
 On 12 January 2015 at 18:11, Phil Steitz  wrote:
> On 1/12/15 10:50 AM, sebb wrote:
>> On 11 January 2015 at 22:10, Phil Steitz  
>> wrote:
>>> On 1/11/15 11:19 AM, Phil Steitz wrote:
 On 1/10/15 10:49 PM, Phil Steitz wrote:
> On 1/9/15 6:09 PM, sebb wrote:
>> On 10 January 2015 at 01:01, Phil Steitz  
>> wrote:
>>> On 1/9/15 5:32 PM, sebb wrote:
 On 9 January 2015 at 23:48, sebb  wrote:
> Of the last 6 runs, only 1 had a problem with unit test 
> failures.
>
> All the builds ran on ubuntu3, apart from the failure which 
> ran on H10.
> This may have some bearing on the result; I don't yet know.
>
> I had a quick look at 2 tests that failed:
>
> SimpleRegressionTest.testPerfect
>
> SimpleRegressionTest.testPerfectNegative
>
> Although the test case has some instance data, these 
> particular tests
> do not use any, so it does not look like a concurrency issue 
> in the
> unit test itself.
>
> The SimpleRegression class has mutable instance data, but the 
> test
> cases create their own instance.
>
> I don't know anything about the math functions involved, but 
> it looks
> as though Infinity might result from getSignificance() if
> getSlopeStdErr() returns 0, as the latter is used as a 
> divisor. Or if
> the field sumXX is 0 because that is also used as a divisor.
>
> Maybe the H10 host has different floating point hardware?
>
> I'll try running some more tests on H10.
 the build failed again on H10; exactly the same tests failed 
 as before:

 This test:
 https://builds.apache.org/job/Commons%20Math%20H10/1/console

 Previous failure:
 https://builds.apache.org/job/Commons%20Math/14/console
>>> This is actually a bug.  Thanks, sebb (and Jenkins)!
>>>
>>> Has been here since 1.x.  What is going on is that the data sets
>>> used in the test cases are set up to be perfect linear
>>> relationships, which should in fact lead to mean square error 
>>> (and
>>> hence slope standard error) equal to 0.  The Jenkins box must be
>>> getting exact 0.  The funny thing is the test is there to 
>>> validate
>>> correct performance for models like this.  Its success 
>>> unfortunately
>>> depends on poor precision.
>>>
>>> I will open a JIRA for this.  I don't think it is a release 
>>> blocker
>>> for 3.4.1, as I am sure you would get the same thing in any 
>>> earlier
>>> version of [math].
>> OK good to know.
>>
>> I'll leave the H10 Jenkins job for now to make it easy to retest.
> My first guess here was wrong.  The infinities are being handled
> correctly for the JDKs I have.  Something must be going awry in 
> the
> t distribution cumulative probability computation for +INF on the
> box that is failing.  Is there a way to find out exactly what JDK
> and OS version are being used?
 I just committed a test that tests the t distribution computations
 directly.  It seems to have run clean; but the other test ran clean
 too.  Is there any way to force the build to use the host that 
 fails?
>>> I can't make any sense of what is going on with the Jenkins builds.
>>> Clean runs and then lots of errors.  This one explains the
>>> SimpleRegression "problem" (which is not a problem with that class
>>> at least)
>>>
>>> testCumulativeProbablilityExtremes(org.apache.commons.math3.distribution.TDistributionTest)
>>>   Time elapsed: 0.001 sec  <<< FAILURE!
>>> java.lang.AssertionError: expected:<1.0> but was:<-Infinity>
>>> at org.junit.Assert.fail(As

Re: [math] Enable jacoco again.

[sebb]

On 13 January 2015 at 10:04,   wrote:
> Repository: commons-math
> Updated Branches:
>   refs/heads/master 3923fc10f -> 4e1958256
>
>
> Enable jacoco again.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/4e195825
> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/4e195825
> Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/4e195825
>
> Branch: refs/heads/master
> Commit: 4e1958256efd75ff3eefbdf43d187c9cc1e691bb
> Parents: 3923fc1
> Author: tn 
> Authored: Tue Jan 13 11:04:32 2015 +0100
> Committer: tn 
> Committed: Tue Jan 13 11:04:32 2015 +0100
>
> --
>  src/site/resources/profile.jacoco  | 17 +
>  src/site/resources/profile.jacoco.disabled | 17 -
>  2 files changed, 17 insertions(+), 17 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/commons-math/blob/4e195825/src/site/resources/profile.jacoco
> --
> diff --git a/src/site/resources/profile.jacoco 
> b/src/site/resources/profile.jacoco
> new file mode 100644
> index 000..a12755f
> --- /dev/null
> +++ b/src/site/resources/profile.jacoco
> @@ -0,0 +1,17 @@
> +# Licensed to the Apache Software Foundation (ASF) under one or more
> +# contributor license agreements.  See the NOTICE file distributed with
> +# this work for additional information regarding copyright ownership.
> +# The ASF licenses this file to You under the Apache License, Version 2.0
> +# (the "License"); you may not use this file except in compliance with
> +# the License.  You may obtain a copy of the License at
> +#
> +# http://www.apache.org/licenses/LICENSE-2.0
> +#
> +# Unless required by applicable law or agreed to in writing, software
> +# distributed under the License is distributed on an "AS IS" BASIS,
> +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> +# See the License for the specific language governing permissions and
> +# limitations under the License.
> +# 
> -
> +#
> +# Empty file used to automatically trigger JaCoCo profile from commons 
> parent pom

Note: an empty file does not need an AL header.

Nor (pedantically speaking) can it have any content!

> http://git-wip-us.apache.org/repos/asf/commons-math/blob/4e195825/src/site/resources/profile.jacoco.disabled
> --
> diff --git a/src/site/resources/profile.jacoco.disabled 
> b/src/site/resources/profile.jacoco.disabled
> deleted file mode 100644
> index a12755f..000
> --- a/src/site/resources/profile.jacoco.disabled
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -# Licensed to the Apache Software Foundation (ASF) under one or more
> -# contributor license agreements.  See the NOTICE file distributed with
> -# this work for additional information regarding copyright ownership.
> -# The ASF licenses this file to You under the Apache License, Version 2.0
> -# (the "License"); you may not use this file except in compliance with
> -# the License.  You may obtain a copy of the License at
> -#
> -# http://www.apache.org/licenses/LICENSE-2.0
> -#
> -# Unless required by applicable law or agreed to in writing, software
> -# distributed under the License is distributed on an "AS IS" BASIS,
> -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> -# See the License for the specific language governing permissions and
> -# limitations under the License.
> -# 
> -
> -#
> -# Empty file used to automatically trigger JaCoCo profile from commons 
> parent pom
>

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

Fwd: [continuum] BUILD FAILURE: Apache Commons Validator - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

[Gary Gregory]

Is anyone else getting:

commons-validator
org.apache.commons.validator.routines.UrlValidatorTest
testIsValid(org.apache.commons.validator.routines.UrlValidatorTest)
junit.framework.AssertionFailedError: http://1.2.3.4./test1?action=view
expected: but was:

at junit.framework.Assert.fail(Assert.java:47)

at junit.framework.Assert.failNotEquals(Assert.java:280)

at junit.framework.Assert.assertEquals(Assert.java:64)

at junit.framework.Assert.assertEquals(Assert.java:146)

at
org.apache.commons.validator.routines.UrlValidatorTest.testIsValid(UrlValidatorTest.java:104)

at
org.apache.commons.validator.routines.UrlValidatorTest.testIsValid(UrlValidatorTest.java:44)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at junit.framework.TestCase.runTest(TestCase.java:164)

at junit.framework.TestCase.runBare(TestCase.java:130)

at junit.framework.TestResult$1.protect(TestResult.java:106)

at junit.framework.TestResult.runProtected(TestResult.java:124)

at junit.framework.TestResult.run(TestResult.java:109)

at junit.framework.TestCase.run(TestCase.java:120)

at junit.framework.TestSuite.runTest(TestSuite.java:230)

at junit.framework.TestSuite.run(TestSuite.java:225)

at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131)

at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)



testValidator339(org.apache.commons.validator.routines.UrlValidatorTest)
junit.framework.AssertionFailedError

at junit.framework.Assert.fail(Assert.java:47)

at junit.framework.Assert.assertTrue(Assert.java:20)

at junit.framework.Assert.assertFalse(Assert.java:34)

at junit.framework.Assert.assertFalse(Assert.java:41)

at
org.apache.commons.validator.routines.UrlValidatorTest.testValidator339(UrlValidatorTest.java:293)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at junit.framework.TestCase.runTest(TestCase.java:164)

at junit.framework.TestCase.runBare(TestCase.java:130)

at junit.framework.TestResult$1.protect(TestResult.java:106)

at junit.framework.TestResult.runProtected(TestResult.java:124)

at junit.framework.TestResult.run(TestResult.java:109)

at junit.framework.TestCase.run(TestCase.java:120)

at junit.framework.TestSuite.runTest(TestSuite.java:230)

at junit.framework.TestSuite.run(TestSuite.java:225)

at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131)

at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)


?

Gary
-- Forwarded message --
From: Apache Continuum 
Date: Tue, Jan 13, 2015 at 4:36 PM
Subject: [continuum] BUILD FAILURE: Apache Commons Validator - Apache
Commons (Group (shared) Maven 3 Build Definition (Java 1.6))
To: dev@commons.apache.org


Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=39210&projectId=106

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Tue 13 Jan 2015 21:36:03 +
  Finished at: Tue 13 Jan 2015 21:36:31 +
  Total time: 27s
  Build Trigger: Forced
  Build Number: 132
  Exit code: 1
  Building machine hostname: continuum-vm
  Operating system : Linux(unknown)
  Java Home version :
  java version "1.6.0_32"
  OpenJDK Runtime Environment (IcedTea6 1.13.4)
(6b32-1.13.4-4ubuntu0.12.04.2)
  OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)

  Builder version :
  Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da;
2013-02-19 13:51:28+)
  Maven home: /opt/apache-maven-3.0.5
  Java version: 1.6.0_32, vendor: Sun Micros

Re: [continuum] BUILD FAILURE: Apache Commons Validator - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

[sebb]

Yes.
Just updated my workspace and ran test and it failed.

I've also updated Continuum to 1.6 and that failed too

On 13 January 2015 at 21:41, Gary Gregory  wrote:
> Is anyone else getting:
>
> commons-validator
> org.apache.commons.validator.routines.UrlValidatorTest
> testIsValid(org.apache.commons.validator.routines.UrlValidatorTest)
> junit.framework.AssertionFailedError: http://1.2.3.4./test1?action=view
> expected: but was:
>
> at junit.framework.Assert.fail(Assert.java:47)
>
> at junit.framework.Assert.failNotEquals(Assert.java:280)
>
> at junit.framework.Assert.assertEquals(Assert.java:64)
>
> at junit.framework.Assert.assertEquals(Assert.java:146)
>
> at
> org.apache.commons.validator.routines.UrlValidatorTest.testIsValid(UrlValidatorTest.java:104)
>
> at
> org.apache.commons.validator.routines.UrlValidatorTest.testIsValid(UrlValidatorTest.java:44)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
>
> at junit.framework.TestCase.runTest(TestCase.java:164)
>
> at junit.framework.TestCase.runBare(TestCase.java:130)
>
> at junit.framework.TestResult$1.protect(TestResult.java:106)
>
> at junit.framework.TestResult.runProtected(TestResult.java:124)
>
> at junit.framework.TestResult.run(TestResult.java:109)
>
> at junit.framework.TestCase.run(TestCase.java:120)
>
> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>
> at junit.framework.TestSuite.run(TestSuite.java:225)
>
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131)
>
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
>
>
>
> testValidator339(org.apache.commons.validator.routines.UrlValidatorTest)
> junit.framework.AssertionFailedError
>
> at junit.framework.Assert.fail(Assert.java:47)
>
> at junit.framework.Assert.assertTrue(Assert.java:20)
>
> at junit.framework.Assert.assertFalse(Assert.java:34)
>
> at junit.framework.Assert.assertFalse(Assert.java:41)
>
> at
> org.apache.commons.validator.routines.UrlValidatorTest.testValidator339(UrlValidatorTest.java:293)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
>
> at junit.framework.TestCase.runTest(TestCase.java:164)
>
> at junit.framework.TestCase.runBare(TestCase.java:130)
>
> at junit.framework.TestResult$1.protect(TestResult.java:106)
>
> at junit.framework.TestResult.runProtected(TestResult.java:124)
>
> at junit.framework.TestResult.run(TestResult.java:109)
>
> at junit.framework.TestCase.run(TestCase.java:120)
>
> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>
> at junit.framework.TestSuite.run(TestSuite.java:225)
>
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131)
>
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
>
>
> ?
>
> Gary
> -- Forwarded message --
> From: Apache Continuum 
> Date: Tue, Jan 13, 2015 at 4:36 PM
> Subject: [continuum] BUILD FAILURE: Apache Commons Validator - Apache
> Commons (Group (shared) Maven 3 Build Definition (Java 1.6))
> To: dev@commons.apache.org
>
>
> Online report :
> https://continuum-ci.apache.org/continuum/buildResult.action?buildId=39210&projectId=106
>
> Build statistics:
>   State: Failed
>   Previous State: Ok
>   Started at: Tue 13 Jan 2015 21:36:03 +
>   Finished at: Tue 13 Jan 2015 21:36:31 +
>   Total time: 27s
>   Build Trigger: Forced
>   Build Number: 132
>   Exit code: 1
>   Building machine hostname: continuum-vm
>   Operating system : Linux(unknown)
>   Java Home

Re: [continuum] BUILD FAILURE: Apache Commons Validator - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

[sebb]

Rats! Looks like a bug here:

final String authorityASCII = DomainValidator.unicodeToASCII(authority);

This is supposed to leave the input string along if it cannot convert
punycode, but it appears to have dropped the final "." when converting
"www.cnn.com.."

Don't know why that was not noticed before.


On 13 January 2015 at 21:46, sebb  wrote:
> Yes.
> Just updated my workspace and ran test and it failed.
>
> I've also updated Continuum to 1.6 and that failed too
>
> On 13 January 2015 at 21:41, Gary Gregory  wrote:
>> Is anyone else getting:
>>
>> commons-validator
>> org.apache.commons.validator.routines.UrlValidatorTest
>> testIsValid(org.apache.commons.validator.routines.UrlValidatorTest)
>> junit.framework.AssertionFailedError: http://1.2.3.4./test1?action=view
>> expected: but was:
>>
>> at junit.framework.Assert.fail(Assert.java:47)
>>
>> at junit.framework.Assert.failNotEquals(Assert.java:280)
>>
>> at junit.framework.Assert.assertEquals(Assert.java:64)
>>
>> at junit.framework.Assert.assertEquals(Assert.java:146)
>>
>> at
>> org.apache.commons.validator.routines.UrlValidatorTest.testIsValid(UrlValidatorTest.java:104)
>>
>> at
>> org.apache.commons.validator.routines.UrlValidatorTest.testIsValid(UrlValidatorTest.java:44)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:597)
>>
>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>
>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>
>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>
>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>
>> at junit.framework.TestResult.run(TestResult.java:109)
>>
>> at junit.framework.TestCase.run(TestCase.java:120)
>>
>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>
>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
>>
>>
>>
>> testValidator339(org.apache.commons.validator.routines.UrlValidatorTest)
>> junit.framework.AssertionFailedError
>>
>> at junit.framework.Assert.fail(Assert.java:47)
>>
>> at junit.framework.Assert.assertTrue(Assert.java:20)
>>
>> at junit.framework.Assert.assertFalse(Assert.java:34)
>>
>> at junit.framework.Assert.assertFalse(Assert.java:41)
>>
>> at
>> org.apache.commons.validator.routines.UrlValidatorTest.testValidator339(UrlValidatorTest.java:293)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:597)
>>
>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>
>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>
>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>
>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>
>> at junit.framework.TestResult.run(TestResult.java:109)
>>
>> at junit.framework.TestCase.run(TestCase.java:120)
>>
>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>
>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>>
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
>>
>>
>> ?
>>
>> Gary
>> -- Forwarded message --
>> From: Apache Continuum 
>> Date: Tue, Jan 13, 2015 at 4:36 PM
>> Subject: [continuum] BUILD FAILURE: Apache Commons Validator - Apache
>> Commons (Group (shared) Maven 3 Build Definiti

Re: [continuum] BUILD FAILURE: Apache Commons Validator - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

[sebb]

On 13 January 2015 at 22:02, sebb  wrote:
> Rats! Looks like a bug here:
>
> final String authorityASCII = DomainValidator.unicodeToASCII(authority);
>
> This is supposed to leave the input string along if it cannot convert
> punycode, but it appears to have dropped the final "." when converting
> "www.cnn.com.."
>
> Don't know why that was not noticed before.

Yes, I do - the NET.unicodeToASCII method was only invoked previously
if the host contained non-ASCII characters.
This was to make sure the Java 6 method was not used unless necessary.

So it would not have been used before in the tests.

We need another test for .. after IDN hosts.

I think the 1.4.1 release is OK.

However it will presumably allow IDN hosts with .. at the end.
Not sure that is terribly serious.

>
> On 13 January 2015 at 21:46, sebb  wrote:
>> Yes.
>> Just updated my workspace and ran test and it failed.
>>
>> I've also updated Continuum to 1.6 and that failed too
>>
>> On 13 January 2015 at 21:41, Gary Gregory  wrote:
>>> Is anyone else getting:
>>>
>>> commons-validator
>>> org.apache.commons.validator.routines.UrlValidatorTest
>>> testIsValid(org.apache.commons.validator.routines.UrlValidatorTest)
>>> junit.framework.AssertionFailedError: http://1.2.3.4./test1?action=view
>>> expected: but was:
>>>

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

Re: svn commit: r1651525 - /commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java

[sebb AT ASF]

This reverts back to the 1.4 code (except for the reflection part) and
fixes the test failures.

However it is not a permanent solution.

On 13 January 2015 at 22:30,   wrote:
> Author: sebb
> Date: Tue Jan 13 22:30:28 2015
> New Revision: 1651525
>
> URL: http://svn.apache.org/r1651525
> Log:
> Add temporary hack to get round IDN.toASCII bug
> It is not supposed to change ASCII input but it converts trailing ".." to "."
>
> Modified:
> 
> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
>
> Modified: 
> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java?rev=1651525&r1=1651524&r2=1651525&view=diff
> ==
> --- 
> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
>  (original)
> +++ 
> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
>  Tue Jan 13 22:30:28 2015
> @@ -1085,6 +1085,9 @@ public class DomainValidator implements
>   */
>  // Needed by UrlValidator
>  static String unicodeToASCII(String input) {
> +if (isOnlyASCII(input)) { // TODO temporary hack to work round 
> IDN.toASCII bug
> +return input;
> +}
>  try {
>  return IDN.toASCII(input);
>  } catch (IllegalArgumentException e) { // input is not valid
> @@ -1092,4 +1095,19 @@ public class DomainValidator implements
>  }
>  }
>
> +/*
> + * Check if input contains only ASCII
> + * Treats null as all ASCII
> + */
> +private static boolean isOnlyASCII(String input) {
> +if (input == null) {
> +return true;
> +}
> +for(int i=0; i < input.length(); i++) {
> +if (input.charAt(i) > 0x7F) {
> +return false;
> +}
> +}
> +return true;
> +}
>  }
>
>

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

[MATH] results on H11 using 1.5/6/7

[sebb]

https://builds.apache.org/job/Commons%20Math%20H10/38/console
H11 - java6 - OK

https://builds.apache.org/job/Commons%20Math%20H10/39/console
H11 - java7 - OK

https://builds.apache.org/job/Commons%20Math%20H10/40/console
H11 - java5 - failed

https://builds.apache.org/job/Commons%20Math%20H10/41/console
H11 - java5 with -Djava.compiler=NONE - wait for it - a bit longer


keep waiting



and waiting


(disabling optimisation makes the test MUCH slower)



still waiting?



a bit more ...

























SUCCESS!

So I think it's almost certainly a JIT optimisation bug in 1.5

QED?

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

[ALL] Commons Parent - include Animal Sniffer?

[sebb]

I've been experimenting with Animal Sniffer in NET as a basic check
that the code does not try to use method etc which are not present in
the target Java version.
[For example, java.net.IDN requires Java 1.6+]

Although the plugin is not fool-proof, it should help to check basic
errors and allow developers to check code even if they don't have the
requisite Java version installed.

My question is - should it be included in Commons Parent?
And if so, should it be enabled by default?

There are various ways of including it:
- inline. It can then be suppressed by defining animal.sniffer.skip
- as a profile which is enabled by default, potentially disabled
manually or by use of a resource file
- as a profile which is disabled by default, but enabled manually of
by use of a resource file

The profile options would work a bit like Jacoc/Cobertura, but could
be enabled by default rather than disabled by default.

WDYT?

I would favour a profile, enabled by default, as this does not add to
the size of the main body of pom.

Note: the build helper plugin can be used to automatically convert
from the maven.compiler.target syntax (e.g. 1.6) to the Animal Sniffer
signature syntax (e.g. java16) so there is no need to maintain a
separate variable.

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

Re: [MATH] results on H11 using 1.5/6/7

[Phil Steitz]

Why only sometimes?



> On Jan 13, 2015, at 4:36 PM, sebb  wrote:
> 
> https://builds.apache.org/job/Commons%20Math%20H10/38/console
> H11 - java6 - OK
> 
> https://builds.apache.org/job/Commons%20Math%20H10/39/console
> H11 - java7 - OK
> 
> https://builds.apache.org/job/Commons%20Math%20H10/40/console
> H11 - java5 - failed
> 
> https://builds.apache.org/job/Commons%20Math%20H10/41/console
> H11 - java5 with -Djava.compiler=NONE - wait for it - a bit longer
> 
> 
> keep waiting
> 
> 
> 
> and waiting
> 
> 
> (disabling optimisation makes the test MUCH slower)
> 
> 
> 
> still waiting?
> 
> 
> 
> a bit more ...
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> SUCCESS!
> 
> So I think it's almost certainly a JIT optimisation bug in 1.5
> 
> QED?
> 
> -
> 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] Jenkins unit test failure

[Gilles]

Hi.


[...]


Everytime I added more debug output to FastMath.exp(), the tests 
succeeded.


Did you try using Math.exp or StrictMath.exp in place of FastMath.exp?



I also setup a jenkins instance with the same maven / jdk version to
build commons-math, but could never reproduce an error so far.

Without direct access to one of the failing servers, I doubt that we
will be able to find / fix this problem.


I wonder if it could be a runtime optimiser issue?
That might explain why debug affected the outcome.

Might be worth trying the non-debug code with Java 6 or 7.

If the issue is related to Java 5, then it could explain why it was
not seen by developer testing - I don't think many devs use Java 5 
(or

the incompatibility would not have crept into the release).


Was it reasonable to stick to Java 5 for so long when that's the case?


Gilles


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

Re: [Math] Maven profile for running the examples?

[Gilles]

[...]
It uses a separate minimal POM, see the JIRA.
The suggested POM is optional, and assumes the examples jar has 
been

released to Maven.



-1 to release examples jar



It was not meant to be the current discussion (cf. earlier posts).
[It might become relevant when the examples are more than... 
examples.]


What about my other proposal, about setting up code that generates
reports (to be included in the "user guide" document)?



That belongs in a new thread with a new title ...


Then, so does the part about publishing the examples.
The original issue was to _run_ them for checking that the examples
are compilable and produce the expected output.

Namely, for the purpose of creating examples that output informative
reports (see above).

Users of CM that don't use maven, would be forced to install it, 
if

they want to run the examples.


No, there is no need to install Maven if CM releases the examples 
as a

jar.
[However obviously the MATH-1187 POM would be no use to them.]

But if CM does not release the examples jar then a CM user that 
does

not want to install Maven may have a problem.

The standard way to build CM Math from source is to use Maven.
So unless CM provides a separate build method (Ant, or setup files 
for

different IDEs, or shell scripts for different OSes)



Math has a working Ant build.


 the user is going
to have to work out how to build the examples for themselves.
[CM can provide written build instructions, but the user would 
have to

translate those into their own build tools]

And (to state the obvious) if a CM user only has runtime Java and 
does
not want to install a JDK, then their only hope is if CM Math 
releases

the examples as a compiled jar.

In the case of a CM user without Maven, the user needs to be told 
what

dependencies are needed by the examples.
They then need to download all the dependencies and ensure that 
they

are available on the classpath when running the examples.

One way to do this is to ensure that the jars are all in the same
directory.
The examples jar manifest can include a Classpath entry which can 
list
the jars; there is then no need to list them on the java command 
line

(and possibly not in the pom dependency section either)
And if the manifest has a Main-Class entry, it can be invoked as 
follows:



Or use an Ant get-deps task like the math build itself does.  Ant 
is

a way better tool for this kind of thing than maven, IMO.



I'd prefer the minimum number of ways to achieve the goal.


To optimise a solution, one generally needs to know what all the
possible solutions are.
Or at least a few, in order to pick the least worst.


I don't mind your experimenting; the remark was about having one
final choice (which could be changed over time if necessary).

If we don't release the examples, ever, then the "maven -q 
exec:java"

way is fine (since the developers most likely have maven installed).


Yes, but there are still options here.
Having to quote the full name of the class is tedious, so perhaps 
need

to look at options for simplifying that.


If there are several choices, one has to "tell" the JVM what one wants;
one way or another, it won't get any significantly shorter.


If we release something (e.g. part of the examples), it looks like
the simplest and safest way (license-wise) is to write down the list
of dependencies and let the users use "whatever" to collect the
dependencies and run the code...


In that case, adding the dependencies to the manifest as Class-Path
entries makes it very easy for the end-user.
No need to create a shell script to set up the class path.


Maybe, maybe; but didn't we say it won't be published for now?
I think that we are good with "mvn -q exec ..."


Regards,
Gilles


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

[Math] Creating reports to be included in the user guide

[Gilles]

Hello.

Now that we can run the code located in the "src/userguide"
directory, I'd propose that some examples be written that
produce various reports for inclusion in the user guide.

A good starting point would be to move
  o.a.c.m.util.FastMathTestPerformance
from the "src/test" directory to "src/userguide".

Rationale: it's not really a test but actually a benchmark
that's only useful through _looking_ at the output.

Any objection?


Gilles


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

Re: [Math] Java version

[Gilles]

Raising this issue once again.
Are we going to upgrade the requirement for the next major release?

 [ ] Java 5
 [ ] Java 6
 [ ] Java 7
 [ ] Java 8
 [ ] Java 9


Counts up to now:

Java 7  -> 2
Java 7 or 8 -> 2
Java 8  -> 2

Any more opionions?

Gilles


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

Re: [Math] Java version

[Ole Ersoy]

I would love to see Java 8.

Ole

On 01/13/2015 07:31 PM, Gilles wrote:

Raising this issue once again.
Are we going to upgrade the requirement for the next major release?

 [ ] Java 5
 [ ] Java 6
 [ ] Java 7
 [ ] Java 8
 [ ] Java 9


Counts up to now:

Java 7  -> 2
Java 7 or 8 -> 2
Java 8  -> 2

Any more opionions?

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: [ALL] Commons Parent - include Animal Sniffer?

[Gary Gregory]

On Tue, Jan 13, 2015 at 6:57 PM, sebb  wrote:

> I've been experimenting with Animal Sniffer in NET as a basic check
> that the code does not try to use method etc which are not present in
> the target Java version.
> [For example, java.net.IDN requires Java 1.6+]
>
> Although the plugin is not fool-proof, it should help to check basic
> errors and allow developers to check code even if they don't have the
> requisite Java version installed.
>
> My question is - should it be included in Commons Parent?
> And if so, should it be enabled by default?
>
> There are various ways of including it:
> - inline. It can then be suppressed by defining animal.sniffer.skip
> - as a profile which is enabled by default, potentially disabled
> manually or by use of a resource file
> - as a profile which is disabled by default, but enabled manually of
> by use of a resource file
>
> The profile options would work a bit like Jacoc/Cobertura, but could
> be enabled by default rather than disabled by default.
>
> WDYT?
>
> I would favour a profile, enabled by default, as this does not add to
> the size of the main body of pom.
>

Sounds reasonable. How long does it take to run for [Net]?

Gary


>
> Note: the build helper plugin can be used to automatically convert
> from the maven.compiler.target syntax (e.g. 1.6) to the Animal Sniffer
> signature syntax (e.g. java16) so there is no need to maintain a
> separate variable.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Java version

[Gary Gregory]

Java 7 or 8.

Gary

On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
wrote:

> Raising this issue once again.
>>> Are we going to upgrade the requirement for the next major release?
>>>
>>>  [ ] Java 5
>>>  [ ] Java 6
>>>  [ ] Java 7
>>>  [ ] Java 8
>>>  [ ] Java 9
>>>
>>
> Counts up to now:
>
> Java 7  -> 2
> Java 7 or 8 -> 2
> Java 8  -> 2
>
> Any more opionions?
>
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Creating reports to be included in the user guide

[Phil Steitz]

On 1/13/15 6:24 PM, Gilles wrote:
> Hello.
>
> Now that we can run the code located in the "src/userguide"
> directory, I'd propose that some examples be written that
> produce various reports for inclusion in the user guide.
>
> A good starting point would be to move
>   o.a.c.m.util.FastMathTestPerformance
> from the "src/test" directory to "src/userguide".
>
> Rationale: it's not really a test but actually a benchmark
> that's only useful through _looking_ at the output.

Why does the report itself belong in the user guide?  Does it help
users make better decisions about how to use [math]?  That is what
the User Guide is for - to help people find things and learn how to
use the software.  If the performance tests help make decisions,
then fine; if not they should not be reproduced in the guide.  Or
are you just suggesting we move the code there so it is easier to
execute?

Phil
>
> Any objection?
>
>
> 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] Jenkins unit test failure

[Phil Steitz]

On 1/13/15 2:33 PM, sebb wrote:
> On 13 January 2015 at 21:26, Thomas Neidhart  
> wrote:
>> On 01/13/2015 09:01 PM, Phil Steitz wrote:
>>> On 1/12/15 3:21 PM, Thomas Neidhart wrote:
 On 01/12/2015 11:17 PM, Phil Steitz wrote:
> On 1/12/15 2:30 PM, Thomas Neidhart wrote:
>> On 01/12/2015 10:26 PM, Thomas Neidhart wrote:
>>> On 01/12/2015 08:09 PM, Phil Steitz wrote:
 On 1/12/15 11:37 AM, sebb wrote:
> On 12 January 2015 at 18:11, Phil Steitz  
> wrote:
>> On 1/12/15 10:50 AM, sebb wrote:
>>> On 11 January 2015 at 22:10, Phil Steitz  
>>> wrote:
 On 1/11/15 11:19 AM, Phil Steitz wrote:
> On 1/10/15 10:49 PM, Phil Steitz wrote:
>> On 1/9/15 6:09 PM, sebb wrote:
>>> On 10 January 2015 at 01:01, Phil Steitz 
>>>  wrote:
 On 1/9/15 5:32 PM, sebb wrote:
> On 9 January 2015 at 23:48, sebb  wrote:
>> Of the last 6 runs, only 1 had a problem with unit test 
>> failures.
>>
>> All the builds ran on ubuntu3, apart from the failure which 
>> ran on H10.
>> This may have some bearing on the result; I don't yet know.
>>
>> I had a quick look at 2 tests that failed:
>>
>> SimpleRegressionTest.testPerfect
>>
>> SimpleRegressionTest.testPerfectNegative
>>
>> Although the test case has some instance data, these 
>> particular tests
>> do not use any, so it does not look like a concurrency issue 
>> in the
>> unit test itself.
>>
>> The SimpleRegression class has mutable instance data, but 
>> the test
>> cases create their own instance.
>>
>> I don't know anything about the math functions involved, but 
>> it looks
>> as though Infinity might result from getSignificance() if
>> getSlopeStdErr() returns 0, as the latter is used as a 
>> divisor. Or if
>> the field sumXX is 0 because that is also used as a divisor.
>>
>> Maybe the H10 host has different floating point hardware?
>>
>> I'll try running some more tests on H10.
> the build failed again on H10; exactly the same tests failed 
> as before:
>
> This test:
> https://builds.apache.org/job/Commons%20Math%20H10/1/console
>
> Previous failure:
> https://builds.apache.org/job/Commons%20Math/14/console
 This is actually a bug.  Thanks, sebb (and Jenkins)!

 Has been here since 1.x.  What is going on is that the data 
 sets
 used in the test cases are set up to be perfect linear
 relationships, which should in fact lead to mean square error 
 (and
 hence slope standard error) equal to 0.  The Jenkins box must 
 be
 getting exact 0.  The funny thing is the test is there to 
 validate
 correct performance for models like this.  Its success 
 unfortunately
 depends on poor precision.

 I will open a JIRA for this.  I don't think it is a release 
 blocker
 for 3.4.1, as I am sure you would get the same thing in any 
 earlier
 version of [math].
>>> OK good to know.
>>>
>>> I'll leave the H10 Jenkins job for now to make it easy to 
>>> retest.
>> My first guess here was wrong.  The infinities are being handled
>> correctly for the JDKs I have.  Something must be going awry in 
>> the
>> t distribution cumulative probability computation for +INF on the
>> box that is failing.  Is there a way to find out exactly what JDK
>> and OS version are being used?
> I just committed a test that tests the t distribution computations
> directly.  It seems to have run clean; but the other test ran 
> clean
> too.  Is there any way to force the build to use the host that 
> fails?
 I can't make any sense of what is going on with the Jenkins builds.
 Clean runs and then lots of errors.  This one explains the
 SimpleRegression "problem" (which is not a problem with that class
 at least)

 testCumulativeProbablilityExtremes(org.apache.common

Re: [continuum] BUILD FAILURE: Apache Commons Validator - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

[Benedikt Ritter]

2015-01-13 23:11 GMT+01:00 sebb :

> On 13 January 2015 at 22:02, sebb  wrote:
> > Rats! Looks like a bug here:
> >
> > final String authorityASCII = DomainValidator.unicodeToASCII(authority);
> >
> > This is supposed to leave the input string along if it cannot convert
> > punycode, but it appears to have dropped the final "." when converting
> > "www.cnn.com.."
> >
> > Don't know why that was not noticed before.
>
> Yes, I do - the NET.unicodeToASCII method was only invoked previously
> if the host contained non-ASCII characters.
> This was to make sure the Java 6 method was not used unless necessary.
>
> So it would not have been used before in the tests.
>
> We need another test for .. after IDN hosts.
>
> I think the 1.4.1 release is OK.
>
> However it will presumably allow IDN hosts with .. at the end.
> Not sure that is terribly serious.
>

I've only tested with Java 8 before committing my changes. Maybe this is a
bug in IDN only in Java 6? Sorry for this and thank you for fixing the
issue!

Benedikt


>
> >
> > On 13 January 2015 at 21:46, sebb  wrote:
> >> Yes.
> >> Just updated my workspace and ran test and it failed.
> >>
> >> I've also updated Continuum to 1.6 and that failed too
> >>
> >> On 13 January 2015 at 21:41, Gary Gregory 
> wrote:
> >>> Is anyone else getting:
> >>>
> >>> commons-validator
> >>> org.apache.commons.validator.routines.UrlValidatorTest
> >>> testIsValid(org.apache.commons.validator.routines.UrlValidatorTest)
> >>> junit.framework.AssertionFailedError:
> http://1.2.3.4./test1?action=view
> >>> expected: but was:
> >>>
>
> -
> 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