Re: [VOTE] Release Apache Commons JCS 2.2 based on RC1

[Gary Gregory]

This VOTE is 7 days old. Has it been tallied? Did I miss it?

Gary

On Wed, Aug 2, 2017 at 6:32 AM, Thomas Vandahl  wrote:

> I would like to release the [jcs] component to resolve some overdue bugs
>
> Apache Commons JCS 2.2 RC1 is available for review at:
>   https://dist.apache.org/repos/dist/dev/commons/jcs/ (r20728).
>
> Maven artifacts are at:
>   https://repository.apache.org/content/repositories/orgapachecommons-1256
> .
>
> The Subversion tag is:
>
> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2
> (r1803806).
>
> The release notes are at:
>
> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/
> commons-jcs-2.2/RELEASE-NOTES.txt
> (r1803806).
>
> The staged site is available as a tarball at
>
> https://dist.apache.org/repos/dist/dev/commons/jcs/commons-
> jcs-site-2.2.tar.gz
> (r20723).
>
> Please review the release candidate and vote.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Bye, Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Jenkins: where are the projects?

[Gary Gregory]

I thought we already had a new view, I guess not :-(

Gary

On Wed, Aug 9, 2017 at 5:17 PM, Gilles  wrote:

> Hi.
>
> The top view does not show "Commons" anymore.
> [I do recall some notice about a change on Jenkins.
> But, no, I don't know whether every developer had to
> do something and, if so, what and how...]
>
> Thanks,
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[All] Jenkins: where are the projects?

[Gilles]

Hi.

The top view does not show "Commons" anymore.
[I do recall some notice about a change on Jenkins.
But, no, I don't know whether every developer had to
do something and, if so, what and how...]

Thanks,
Gilles


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

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gary Gregory]

On Wed, Aug 9, 2017 at 4:52 PM, Gilles  wrote:

> On Thu, 10 Aug 2017 01:31:04 +0200, Gilles wrote:
>
>> On Wed, 9 Aug 2017 16:10:58 -0700, Gary Gregory wrote:
>>
>>> On Wed, Aug 9, 2017 at 3:52 PM, Gilles 
>>> wrote:
>>>
>>> On Wed, 9 Aug 2017 15:23:23 -0700, Gary Gregory wrote:

 I would start by updating the Maven plugins and any third party deps.
>
> For example:
>
> [INFO] --- maven-jgit-buildnumber-plugin:1.2.10:extract-buildnumber
> (default) @ commons-math4 ---
>
> [ERROR]
>
> org.eclipse.jgit.errors.RevWalkException: Walk failure.
>
> Why not try updating maven-jgit-buildnumber-plugin to the current
> version?
>
>
 To which version?
 Isn't this supposed to be defined in the "parent"?


>>> You can check
>>>
>>> https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22maven-
>>> jgit-buildnumber-plugin%22
>>>
>>
>> This link confirms that 1.2.10 is the latest version of the
>> tool used by Commons Math's POM.
>>
>> Then, there is another (with a different GroupId) that is at
>> 1.2.11. I'll try that one...
>>
>
> Done, didn't change a thing:
>   https://travis-ci.org/apache/commons-math/jobs/262883559


What other plugins are out of date? Jacoco looks out of date. There is a
Maven command for that: mvn versions:display-plugin-updates

Gary

>
>
> Gilles
>
>
>
>> Gilles
>>
>>
>>> Gary
>>>
>>>
 Gilles



 Gary
>
>
> On Wed, Aug 9, 2017 at 3:19 PM, Gilles 
> wrote:
>
> On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:
>
>>
>> On 9 August 2017 at 13:51, Gilles 
>> wrote:
>>
>>>
>>> Hi.
>>>

 Build with Java 8 runs fine:
   https://travis-ci.org/apache/commons-math/jobs/262647212

 But with Java 7:
   https://travis-ci.org/apache/commons-math/jobs/262647211

 Is anyone willing to debug this failure?


 1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it
>>> cannot
>>> find the current git info
>>>
>>>
>>> That's not what makes the build fail since it happens in both.
>>
>> 2) Bug in JVM - buffer overflow.
>>
>>
>>>
>>> That's the issue.
>>
>> [I should have mentioned that I had also read the job log,
>> before posting.]
>>
>>
>> Both of these could happen with any Java version.
>>
>>>
>>> Or is this a hint for making Java 8 the minimum supported
>>>
>>> version for the next release?


 That is not a valid conclusion from the evidence.
>>>
>>>
>>> How do you draw that conclusion?
>>
>> More to the point, my request is: What to do to fix the negative
>> advertisement for the project which this Travis issue propagates
>> (see badge):
>>   https://github.com/apache/commons-math
>>
>>
>> Regards,
>> Gilles
>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gilles]

On Thu, 10 Aug 2017 01:48:48 +0200, Gilles wrote:

On Thu, 10 Aug 2017 00:30:59 +0100, sebb wrote:
On 10 August 2017 at 00:08, Gilles  
wrote:

On Wed, 9 Aug 2017 23:48:30 +0100, sebb wrote:


On 9 August 2017 at 23:19, Gilles  
wrote:


On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:



On 9 August 2017 at 13:51, Gilles  
wrote:



Hi.

Build with Java 8 runs fine:
  https://travis-ci.org/apache/commons-math/jobs/262647212

But with Java 7:
  https://travis-ci.org/apache/commons-math/jobs/262647211

Is anyone willing to debug this failure?




1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it 
cannot

find the current git info




That's not what makes the build fail since it happens in both.


2) Bug in JVM - buffer overflow.




That's the issue.

[I should have mentioned that I had also read the job log,
before posting.]



Yes, that would have saved others some effort.



Hmm, when asking for help to "debug the issue", I thought that
it was obvious that reading the log was involved necessary but
not sufficient...


But there is no debugging involved here...



Both of these could happen with any Java version.


Or is this a hint for making Java 8 the minimum supported
version for the next release?




That is not a valid conclusion from the evidence.




How do you draw that conclusion?



Because there is no proof that the failure is caused by using Java 
7

rather than because the test uses a specific version of the Java 7
JVM.

JVM crashes tend to be specific to particular implementations.
It any case, a test that fails with a JVM crash is not a failure 
of

the code being tested but of the JVM itself.



Sure. Never implied that the problem was in the Java code...


But you did imply that the problem was related to Java 7, which it 
is not.



More to the point, my request is: What to do to fix the negative
advertisement for the project which this Travis issue propagates
(see badge):
  https://github.com/apache/commons-math



No idea. Ask a Travis guru.



More more to the point, that's the purpose of my posting here!


You asked for debugging help, which is not the same.


The negative publicity belongs to the specific Java 7 JVM which is
crashing.



Sure. Never implied anything else.


But you did imply that the problem was related to Java 7, which it 
is not.



Commons Math should really be praised for exposing the bug.



And what will we do of it?
That was the "hint" referred to above: if there is no interest in
fixing that bug in a Java7 JVM, we should at least stop submitting
that job to Travis.

You are, of course, right that we do not have to target Java 8.
My point was: Is there anyone reading this interested in keeping
Java 7 compatibility?
And, if yes, then _those_ people should IMHO be interested in
fixing the problem reported here.


The obvious thing to try is to use a different Java 7 compiler.

I think this just shows that automated checks are only useful if 
it is

clearly understood how the checkers measure success/failure.



I don't follow.


Travis is an automated check.
People who rely on the check need to know what success/failure means
to avoid being misled by the report.


[Or do you suggest that Travis should report
"success" because the code succeeded in crashing the JVM ;-) ].


I am saying that Travis is reporting failure against Commons Math 
when

it is the JVM that failed.

The most that can be said of Math in this case is that the testing 
was

incomplete, so its state is unknown.
(If the JVM had not crashed, the test might still have failed later)

The point is that Travis reports failure, but failure in this case
does not mean a problem with Math.


But where did you see that I implied there was a problem with Math?
All along, I asked whether someone knows how to fix Travis (what to
do, where to ask).


A search on the web[1] seems to point to an old problem:
  https://github.com/travis-ci/travis-ci/issues/5227
but no solution from there (IIUC).

Gilles

[1] "*** buffer overflow detected ***: 
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java terminated"




Thanks,
Gilles




Gilles





Regards,
Gilles





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



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

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gilles]

On Thu, 10 Aug 2017 01:31:04 +0200, Gilles wrote:

On Wed, 9 Aug 2017 16:10:58 -0700, Gary Gregory wrote:
On Wed, Aug 9, 2017 at 3:52 PM, Gilles 
 wrote:



On Wed, 9 Aug 2017 15:23:23 -0700, Gary Gregory wrote:

I would start by updating the Maven plugins and any third party 
deps.


For example:

[INFO] --- 
maven-jgit-buildnumber-plugin:1.2.10:extract-buildnumber

(default) @ commons-math4 ---

[ERROR]

org.eclipse.jgit.errors.RevWalkException: Walk failure.

Why not try updating maven-jgit-buildnumber-plugin to the current 
version?




To which version?
Isn't this supposed to be defined in the "parent"?



You can check

https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22maven-jgit-buildnumber-plugin%22


This link confirms that 1.2.10 is the latest version of the
tool used by Commons Math's POM.

Then, there is another (with a different GroupId) that is at
1.2.11. I'll try that one...


Done, didn't change a thing:
  https://travis-ci.org/apache/commons-math/jobs/262883559

Gilles



Gilles



Gary



Gilles




Gary


On Wed, Aug 9, 2017 at 3:19 PM, Gilles 


wrote:

On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:


On 9 August 2017 at 13:51, Gilles  
wrote:


Hi.


Build with Java 8 runs fine:
  https://travis-ci.org/apache/commons-math/jobs/262647212

But with Java 7:
  https://travis-ci.org/apache/commons-math/jobs/262647211

Is anyone willing to debug this failure?


1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it 
cannot

find the current git info



That's not what makes the build fail since it happens in both.

2) Bug in JVM - buffer overflow.





That's the issue.

[I should have mentioned that I had also read the job log,
before posting.]


Both of these could happen with any Java version.


Or is this a hint for making Java 8 the minimum supported


version for the next release?



That is not a valid conclusion from the evidence.



How do you draw that conclusion?

More to the point, my request is: What to do to fix the negative
advertisement for the project which this Travis issue propagates
(see badge):
  https://github.com/apache/commons-math


Regards,
Gilles






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

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gilles]

On Thu, 10 Aug 2017 00:30:59 +0100, sebb wrote:
On 10 August 2017 at 00:08, Gilles  
wrote:

On Wed, 9 Aug 2017 23:48:30 +0100, sebb wrote:


On 9 August 2017 at 23:19, Gilles  
wrote:


On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:



On 9 August 2017 at 13:51, Gilles  
wrote:



Hi.

Build with Java 8 runs fine:
  https://travis-ci.org/apache/commons-math/jobs/262647212

But with Java 7:
  https://travis-ci.org/apache/commons-math/jobs/262647211

Is anyone willing to debug this failure?




1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it 
cannot

find the current git info




That's not what makes the build fail since it happens in both.


2) Bug in JVM - buffer overflow.




That's the issue.

[I should have mentioned that I had also read the job log,
before posting.]



Yes, that would have saved others some effort.



Hmm, when asking for help to "debug the issue", I thought that
it was obvious that reading the log was involved necessary but
not sufficient...


But there is no debugging involved here...



Both of these could happen with any Java version.


Or is this a hint for making Java 8 the minimum supported
version for the next release?




That is not a valid conclusion from the evidence.




How do you draw that conclusion?



Because there is no proof that the failure is caused by using Java 
7

rather than because the test uses a specific version of the Java 7
JVM.

JVM crashes tend to be specific to particular implementations.
It any case, a test that fails with a JVM crash is not a failure of
the code being tested but of the JVM itself.



Sure. Never implied that the problem was in the Java code...


But you did imply that the problem was related to Java 7, which it is 
not.



More to the point, my request is: What to do to fix the negative
advertisement for the project which this Travis issue propagates
(see badge):
  https://github.com/apache/commons-math



No idea. Ask a Travis guru.



More more to the point, that's the purpose of my posting here!


You asked for debugging help, which is not the same.


The negative publicity belongs to the specific Java 7 JVM which is
crashing.



Sure. Never implied anything else.


But you did imply that the problem was related to Java 7, which it is 
not.



Commons Math should really be praised for exposing the bug.



And what will we do of it?
That was the "hint" referred to above: if there is no interest in
fixing that bug in a Java7 JVM, we should at least stop submitting
that job to Travis.

You are, of course, right that we do not have to target Java 8.
My point was: Is there anyone reading this interested in keeping
Java 7 compatibility?
And, if yes, then _those_ people should IMHO be interested in
fixing the problem reported here.


The obvious thing to try is to use a different Java 7 compiler.

I think this just shows that automated checks are only useful if it 
is

clearly understood how the checkers measure success/failure.



I don't follow.


Travis is an automated check.
People who rely on the check need to know what success/failure means
to avoid being misled by the report.


[Or do you suggest that Travis should report
"success" because the code succeeded in crashing the JVM ;-) ].


I am saying that Travis is reporting failure against Commons Math 
when

it is the JVM that failed.

The most that can be said of Math in this case is that the testing 
was

incomplete, so its state is unknown.
(If the JVM had not crashed, the test might still have failed later)

The point is that Travis reports failure, but failure in this case
does not mean a problem with Math.


But where did you see that I implied there was a problem with Math?
All along, I asked whether someone knows how to fix Travis (what to
do, where to ask).

Thanks,
Gilles




Gilles





Regards,
Gilles





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

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gilles]

On Wed, 9 Aug 2017 16:10:58 -0700, Gary Gregory wrote:
On Wed, Aug 9, 2017 at 3:52 PM, Gilles  
wrote:



On Wed, 9 Aug 2017 15:23:23 -0700, Gary Gregory wrote:

I would start by updating the Maven plugins and any third party 
deps.


For example:

[INFO] --- maven-jgit-buildnumber-plugin:1.2.10:extract-buildnumber
(default) @ commons-math4 ---

[ERROR]

org.eclipse.jgit.errors.RevWalkException: Walk failure.

Why not try updating maven-jgit-buildnumber-plugin to the current 
version?




To which version?
Isn't this supposed to be defined in the "parent"?



You can check

https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22maven-jgit-buildnumber-plugin%22


This link confirms that 1.2.10 is the latest version of the
tool used by Commons Math's POM.

Then, there is another (with a different GroupId) that is at
1.2.11. I'll try that one...

Gilles



Gary



Gilles




Gary


On Wed, Aug 9, 2017 at 3:19 PM, Gilles 


wrote:

On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:


On 9 August 2017 at 13:51, Gilles  
wrote:


Hi.


Build with Java 8 runs fine:
  https://travis-ci.org/apache/commons-math/jobs/262647212

But with Java 7:
  https://travis-ci.org/apache/commons-math/jobs/262647211

Is anyone willing to debug this failure?


1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it 
cannot

find the current git info



That's not what makes the build fail since it happens in both.

2) Bug in JVM - buffer overflow.





That's the issue.

[I should have mentioned that I had also read the job log,
before posting.]


Both of these could happen with any Java version.


Or is this a hint for making Java 8 the minimum supported


version for the next release?



That is not a valid conclusion from the evidence.



How do you draw that conclusion?

More to the point, my request is: What to do to fix the negative
advertisement for the project which this Travis issue propagates
(see badge):
  https://github.com/apache/commons-math


Regards,
Gilles






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





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

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[sebb]

On 10 August 2017 at 00:08, Gilles  wrote:
> On Wed, 9 Aug 2017 23:48:30 +0100, sebb wrote:
>>
>> On 9 August 2017 at 23:19, Gilles  wrote:
>>>
>>> On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:


 On 9 August 2017 at 13:51, Gilles  wrote:
>
>
> Hi.
>
> Build with Java 8 runs fine:
>   https://travis-ci.org/apache/commons-math/jobs/262647212
>
> But with Java 7:
>   https://travis-ci.org/apache/commons-math/jobs/262647211
>
> Is anyone willing to debug this failure?



 1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it cannot
 find the current git info
>>>
>>>
>>>
>>> That's not what makes the build fail since it happens in both.
>>>
 2) Bug in JVM - buffer overflow.
>>>
>>>
>>>
>>> That's the issue.
>>>
>>> [I should have mentioned that I had also read the job log,
>>> before posting.]
>>
>>
>> Yes, that would have saved others some effort.
>
>
> Hmm, when asking for help to "debug the issue", I thought that
> it was obvious that reading the log was involved necessary but
> not sufficient...

But there is no debugging involved here...


 Both of these could happen with any Java version.

> Or is this a hint for making Java 8 the minimum supported
> version for the next release?



 That is not a valid conclusion from the evidence.
>>>
>>>
>>>
>>> How do you draw that conclusion?
>>
>>
>> Because there is no proof that the failure is caused by using Java 7
>> rather than because the test uses a specific version of the Java 7
>> JVM.
>>
>> JVM crashes tend to be specific to particular implementations.
>> It any case, a test that fails with a JVM crash is not a failure of
>> the code being tested but of the JVM itself.
>
>
> Sure. Never implied that the problem was in the Java code...

But you did imply that the problem was related to Java 7, which it is not.

>>> More to the point, my request is: What to do to fix the negative
>>> advertisement for the project which this Travis issue propagates
>>> (see badge):
>>>   https://github.com/apache/commons-math
>>
>>
>> No idea. Ask a Travis guru.
>
>
> More more to the point, that's the purpose of my posting here!

You asked for debugging help, which is not the same.

>> The negative publicity belongs to the specific Java 7 JVM which is
>> crashing.
>
>
> Sure. Never implied anything else.

But you did imply that the problem was related to Java 7, which it is not.

>> Commons Math should really be praised for exposing the bug.
>
>
> And what will we do of it?
> That was the "hint" referred to above: if there is no interest in
> fixing that bug in a Java7 JVM, we should at least stop submitting
> that job to Travis.
>
> You are, of course, right that we do not have to target Java 8.
> My point was: Is there anyone reading this interested in keeping
> Java 7 compatibility?
> And, if yes, then _those_ people should IMHO be interested in
> fixing the problem reported here.

The obvious thing to try is to use a different Java 7 compiler.

>> I think this just shows that automated checks are only useful if it is
>> clearly understood how the checkers measure success/failure.
>
>
> I don't follow.

Travis is an automated check.
People who rely on the check need to know what success/failure means
to avoid being misled by the report.

> [Or do you suggest that Travis should report
> "success" because the code succeeded in crashing the JVM ;-) ].

I am saying that Travis is reporting failure against Commons Math when
it is the JVM that failed.

The most that can be said of Math in this case is that the testing was
incomplete, so its state is unknown.
(If the JVM had not crashed, the test might still have failed later)

The point is that Travis reports failure, but failure in this case
does not mean a problem with Math.

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

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

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gary Gregory]

On Wed, Aug 9, 2017 at 3:52 PM, Gilles  wrote:

> On Wed, 9 Aug 2017 15:23:23 -0700, Gary Gregory wrote:
>
>> I would start by updating the Maven plugins and any third party deps.
>>
>> For example:
>>
>> [INFO] --- maven-jgit-buildnumber-plugin:1.2.10:extract-buildnumber
>> (default) @ commons-math4 ---
>>
>> [ERROR]
>>
>> org.eclipse.jgit.errors.RevWalkException: Walk failure.
>>
>> Why not try updating maven-jgit-buildnumber-plugin to the current version?
>>
>
> To which version?
> Isn't this supposed to be defined in the "parent"?
>

You can check
https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22maven-jgit-buildnumber-plugin%22

Gary

>
> Gilles
>
>
>
>> Gary
>>
>>
>> On Wed, Aug 9, 2017 at 3:19 PM, Gilles 
>> wrote:
>>
>> On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:
>>>
>>> On 9 August 2017 at 13:51, Gilles  wrote:

 Hi.
>
> Build with Java 8 runs fine:
>   https://travis-ci.org/apache/commons-math/jobs/262647212
>
> But with Java 7:
>   https://travis-ci.org/apache/commons-math/jobs/262647211
>
> Is anyone willing to debug this failure?
>
>
 1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it cannot
 find the current git info


>>> That's not what makes the build fail since it happens in both.
>>>
>>> 2) Bug in JVM - buffer overflow.
>>>


>>> That's the issue.
>>>
>>> [I should have mentioned that I had also read the job log,
>>> before posting.]
>>>
>>>
>>> Both of these could happen with any Java version.

 Or is this a hint for making Java 8 the minimum supported

> version for the next release?
>
>
 That is not a valid conclusion from the evidence.


>>> How do you draw that conclusion?
>>>
>>> More to the point, my request is: What to do to fix the negative
>>> advertisement for the project which this Travis issue propagates
>>> (see badge):
>>>   https://github.com/apache/commons-math
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>>
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gilles]

On Wed, 9 Aug 2017 23:48:30 +0100, sebb wrote:
On 9 August 2017 at 23:19, Gilles  
wrote:

On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:


On 9 August 2017 at 13:51, Gilles  
wrote:


Hi.

Build with Java 8 runs fine:
  https://travis-ci.org/apache/commons-math/jobs/262647212

But with Java 7:
  https://travis-ci.org/apache/commons-math/jobs/262647211

Is anyone willing to debug this failure?



1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it 
cannot

find the current git info



That's not what makes the build fail since it happens in both.


2) Bug in JVM - buffer overflow.



That's the issue.

[I should have mentioned that I had also read the job log,
before posting.]


Yes, that would have saved others some effort.


Hmm, when asking for help to "debug the issue", I thought that
it was obvious that reading the log was involved necessary but
not sufficient...



Both of these could happen with any Java version.


Or is this a hint for making Java 8 the minimum supported
version for the next release?



That is not a valid conclusion from the evidence.



How do you draw that conclusion?


Because there is no proof that the failure is caused by using Java 7
rather than because the test uses a specific version of the Java 7
JVM.

JVM crashes tend to be specific to particular implementations.
It any case, a test that fails with a JVM crash is not a failure of
the code being tested but of the JVM itself.


Sure. Never implied that the problem was in the Java code...


More to the point, my request is: What to do to fix the negative
advertisement for the project which this Travis issue propagates
(see badge):
  https://github.com/apache/commons-math


No idea. Ask a Travis guru.


More more to the point, that's the purpose of my posting here!

The negative publicity belongs to the specific Java 7 JVM which is 
crashing.


Sure. Never implied anything else.


Commons Math should really be praised for exposing the bug.


And what will we do of it?
That was the "hint" referred to above: if there is no interest in
fixing that bug in a Java7 JVM, we should at least stop submitting
that job to Travis.

You are, of course, right that we do not have to target Java 8.
My point was: Is there anyone reading this interested in keeping
Java 7 compatibility?
And, if yes, then _those_ people should IMHO be interested in
fixing the problem reported here.

I think this just shows that automated checks are only useful if it 
is

clearly understood how the checkers measure success/failure.


I don't follow. [Or do you suggest that Travis should report
"success" because the code succeeded in crashing the JVM ;-) ].

Gilles




Regards,
Gilles



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

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gilles]

On Wed, 9 Aug 2017 15:23:23 -0700, Gary Gregory wrote:

I would start by updating the Maven plugins and any third party deps.

For example:

[INFO] --- maven-jgit-buildnumber-plugin:1.2.10:extract-buildnumber
(default) @ commons-math4 ---

[ERROR]

org.eclipse.jgit.errors.RevWalkException: Walk failure.

Why not try updating maven-jgit-buildnumber-plugin to the current 
version?


To which version?
Isn't this supposed to be defined in the "parent"?

Gilles




Gary


On Wed, Aug 9, 2017 at 3:19 PM, Gilles  
wrote:



On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:

On 9 August 2017 at 13:51, Gilles  
wrote:



Hi.

Build with Java 8 runs fine:
  https://travis-ci.org/apache/commons-math/jobs/262647212

But with Java 7:
  https://travis-ci.org/apache/commons-math/jobs/262647211

Is anyone willing to debug this failure?



1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it 
cannot

find the current git info



That's not what makes the build fail since it happens in both.

2) Bug in JVM - buffer overflow.




That's the issue.

[I should have mentioned that I had also read the job log,
before posting.]



Both of these could happen with any Java version.

Or is this a hint for making Java 8 the minimum supported

version for the next release?



That is not a valid conclusion from the evidence.



How do you draw that conclusion?

More to the point, my request is: What to do to fix the negative
advertisement for the project which this Travis issue propagates
(see badge):
  https://github.com/apache/commons-math


Regards,
Gilles





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

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[sebb]

On 9 August 2017 at 23:19, Gilles  wrote:
> On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:
>>
>> On 9 August 2017 at 13:51, Gilles  wrote:
>>>
>>> Hi.
>>>
>>> Build with Java 8 runs fine:
>>>   https://travis-ci.org/apache/commons-math/jobs/262647212
>>>
>>> But with Java 7:
>>>   https://travis-ci.org/apache/commons-math/jobs/262647211
>>>
>>> Is anyone willing to debug this failure?
>>
>>
>> 1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it cannot
>> find the current git info
>
>
> That's not what makes the build fail since it happens in both.
>
>> 2) Bug in JVM - buffer overflow.
>
>
> That's the issue.
>
> [I should have mentioned that I had also read the job log,
> before posting.]

Yes, that would have saved others some effort.

>>
>> Both of these could happen with any Java version.
>>
>>> Or is this a hint for making Java 8 the minimum supported
>>> version for the next release?
>>
>>
>> That is not a valid conclusion from the evidence.
>
>
> How do you draw that conclusion?

Because there is no proof that the failure is caused by using Java 7
rather than because the test uses a specific version of the Java 7
JVM.

JVM crashes tend to be specific to particular implementations.
It any case, a test that fails with a JVM crash is not a failure of
the code being tested but of the JVM itself.

> More to the point, my request is: What to do to fix the negative
> advertisement for the project which this Travis issue propagates
> (see badge):
>   https://github.com/apache/commons-math

No idea. Ask a Travis guru.

The negative publicity belongs to the specific Java 7 JVM which is crashing.

Commons Math should really be praised for exposing the bug.

I think this just shows that automated checks are only useful if it is
clearly understood how the checkers measure success/failure.

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

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

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gary Gregory]

I would start by updating the Maven plugins and any third party deps.

For example:

[INFO] --- maven-jgit-buildnumber-plugin:1.2.10:extract-buildnumber
(default) @ commons-math4 ---

[ERROR]

org.eclipse.jgit.errors.RevWalkException: Walk failure.

Why not try updating maven-jgit-buildnumber-plugin to the current version?

Gary


On Wed, Aug 9, 2017 at 3:19 PM, Gilles  wrote:

> On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:
>
>> On 9 August 2017 at 13:51, Gilles  wrote:
>>
>>> Hi.
>>>
>>> Build with Java 8 runs fine:
>>>   https://travis-ci.org/apache/commons-math/jobs/262647212
>>>
>>> But with Java 7:
>>>   https://travis-ci.org/apache/commons-math/jobs/262647211
>>>
>>> Is anyone willing to debug this failure?
>>>
>>
>> 1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it cannot
>> find the current git info
>>
>
> That's not what makes the build fail since it happens in both.
>
> 2) Bug in JVM - buffer overflow.
>>
>
> That's the issue.
>
> [I should have mentioned that I had also read the job log,
> before posting.]
>
>
>> Both of these could happen with any Java version.
>>
>> Or is this a hint for making Java 8 the minimum supported
>>> version for the next release?
>>>
>>
>> That is not a valid conclusion from the evidence.
>>
>
> How do you draw that conclusion?
>
> More to the point, my request is: What to do to fix the negative
> advertisement for the project which this Travis issue propagates
> (see badge):
>   https://github.com/apache/commons-math
>
>
> Regards,
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gilles]

On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:
On 9 August 2017 at 13:51, Gilles  
wrote:

Hi.

Build with Java 8 runs fine:
  https://travis-ci.org/apache/commons-math/jobs/262647212

But with Java 7:
  https://travis-ci.org/apache/commons-math/jobs/262647211

Is anyone willing to debug this failure?


1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it cannot
find the current git info


That's not what makes the build fail since it happens in both.


2) Bug in JVM - buffer overflow.


That's the issue.

[I should have mentioned that I had also read the job log,
before posting.]



Both of these could happen with any Java version.


Or is this a hint for making Java 8 the minimum supported
version for the next release?


That is not a valid conclusion from the evidence.


How do you draw that conclusion?

More to the point, my request is: What to do to fix the negative
advertisement for the project which this Travis issue propagates
(see badge):
  https://github.com/apache/commons-math


Regards,
Gilles


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

[GitHub] commons-imaging pull request #30: add-tests

[TheRealHaui]

Github user TheRealHaui commented on a diff in the pull request:

https://github.com/apache/commons-imaging/pull/30#discussion_r132311416
  
--- Diff: pom.xml ---
@@ -209,6 +209,12 @@
   2.5
   test
 
+
--- End diff --

Understand your point.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-imaging pull request #30: add-tests

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-imaging/pull/30#discussion_r132310660
  
--- Diff: pom.xml ---
@@ -209,6 +209,12 @@
   2.5
   test
 
+
--- End diff --

Indeed, and I may even use it in some projects at work. However, other 
commons components use - as far as I can remember - JUnit with some local 
helper classes for tests. So my line of thinking, is that even though it looks 
useful, others would have to learn and remember to use it, or eventually we 
would end up with calls to Equalsverifier methods, and in some other places the 
old way. But again, -0 is not a blocker, if others prefer to have it, I'm fine 
with it :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-imaging issue #30: add-tests

[TheRealHaui]

Github user TheRealHaui commented on the issue:

https://github.com/apache/commons-imaging/pull/30
  
Changes incorporated.
Build working.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-imaging pull request #30: add-tests

[TheRealHaui]

Github user TheRealHaui commented on a diff in the pull request:

https://github.com/apache/commons-imaging/pull/30#discussion_r132308184
  
--- Diff: pom.xml ---
@@ -209,6 +209,12 @@
   2.5
   test
 
+
--- End diff --

Well, Equalsverifier checks equals and hashCode methods soroly.
Therefore I considered to use it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-imaging pull request #30: add-tests

[TheRealHaui]

Github user TheRealHaui commented on a diff in the pull request:

https://github.com/apache/commons-imaging/pull/30#discussion_r132307800
  
--- Diff: 
src/test/java/org/apache/commons/imaging/formats/tiff/taginfos/TagInfoByteOrShortTest.java
 ---
@@ -0,0 +1,55 @@
+/*
+ * 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.
+ */
+package org.apache.commons.imaging.formats.tiff.taginfos;
+
+import org.junit.Test;
+import static org.junit.Assert.*;
+import java.nio.ByteOrder;
+import org.apache.commons.imaging.formats.tiff.constants.TiffDirectoryType;
+
+/**
+ * Unit tests for class {@link TagInfoByteOrShort}.
+ *
+ * @date 2017-08-01
+ * @see TagInfoByteOrShort
+ *
+ **/
+public class TagInfoByteOrShortTest{
+
+  @Test
+  public void 
testEncodeValueTaking1And1AndEncodeValueTaking1And1AndEncodeValueTaking1And1ReturningNonEmptyArrayOne()
 {
+  TiffDirectoryType tiffDirectoryType = 
TiffDirectoryType.EXIF_DIRECTORY_MAKER_NOTES;
+  TagInfoByteOrShort tagInfoByteOrShort = new TagInfoByteOrShort("r", 
500, 500, tiffDirectoryType);
+  ByteOrder byteOrder = ByteOrder.BIG_ENDIAN;
+  short[] shortArray = new short[2];
+  byte[] byteArray = tagInfoByteOrShort.encodeValue(byteOrder, 
shortArray);
+
+  assertArrayEquals(new byte[] {(byte)0, (byte)0, (byte)0, (byte)0}, 
byteArray);
+  }
+
+  @Test
+  public void 
testEncodeValueTaking1And1AndEncodeValueTaking1And1AndEncodeValueTaking1And1ReturningNonEmptyArrayTwo()
 {
--- End diff --

Renamed test methods.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-imaging pull request #30: add-tests

[TheRealHaui]

Github user TheRealHaui commented on a diff in the pull request:

https://github.com/apache/commons-imaging/pull/30#discussion_r132306981
  
--- Diff: 
src/test/java/org/apache/commons/imaging/formats/pnm/PgmFileInfoTest.java ---
@@ -0,0 +1,49 @@
+/*
+ * 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.
+ */
+package org.apache.commons.imaging.formats.pnm;
+
+import org.apache.commons.imaging.ImageReadException;
+import org.junit.Test;
+import static org.junit.Assert.*;
+
+/**
+ * Unit tests for class {@link PgmFileInfo}.
+ *
+ * @date 2017-08-01
+ * @see PgmFileInfo
+ *
+ **/
+public class PgmFileInfoTest{
+
+  @Test(expected = ImageReadException.class)
--- End diff --

Reformatted code.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-imaging pull request #30: add-tests

[TheRealHaui]

Github user TheRealHaui commented on a diff in the pull request:

https://github.com/apache/commons-imaging/pull/30#discussion_r132306138
  
--- Diff: 
src/test/java/org/apache/commons/imaging/formats/pnm/PgmFileInfoTest.java ---
@@ -0,0 +1,49 @@
+/*
+ * 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.
+ */
+package org.apache.commons.imaging.formats.pnm;
+
+import org.apache.commons.imaging.ImageReadException;
+import org.junit.Test;
+import static org.junit.Assert.*;
+
+/**
+ * Unit tests for class {@link PgmFileInfo}.
+ *
+ * @date 2017-08-01
--- End diff --

Removed the class comment.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Ready for JDK 9 ?

[Gary Gregory]

On Wed, Aug 9, 2017 at 1:00 PM, Ralph Goers 
wrote:

> I have my doubts about the module system but I am not sure why you would
> think multi-release jars will cause problems.
>

IIRC, multi-release jars causes problem in the Android tool chain. I
imagine there are going to be a lot of catching up to do from a lot of
vendors, tools and libraries. What a mess.

Gary


> Ralph
>
> > On Aug 9, 2017, at 8:28 AM, Gary Gregory  wrote:
> >
> > On Wed, Aug 9, 2017 at 1:09 AM, Jörg Schaible <
> > joerg.schai...@bpm-inspire.com >
> wrote:
> >
> >> Hi Simon,
> >>
> >> Simon Spero wrote:
> >>
> >>> Compress HEAD is tested against the equivalent of RC. The main issues
> >> were
> >>> with tests; some types of mocking (especially of concrete classes)
> don't
> >>> work. This might have been fixed by now.
> >>> I believe that the latest jacoco is 9 compatible.
> >>>
> >>> [The biggest problem was caused by a bug in the zip code handling a
> >>> particular kind of timestamp; massive changes to the jdk implementation
> >> of
> >>> zip caused tests that had been passing (but shouldn't have) to fail
> >>> properly.]
> >>>
> >>> NOTE:
> >>>
> >>> Adding a Module name manifest header asserts that the code is tested
> >>> against Java 9. This is documented in the minutes of the armistice
> talks.
> >>>
> >>> jigsaw modules are pretty useless for most of Commons (consumers pretty
> >>> much have to shade dependencies). [ subliminal whisper about benefits
> of
> >>> having correct OSGI headers]
> >>
> >> OK, that means we should at least test those releases that contain a
> Module
> >> name now and silently assume, that the other stuff is not necessarily
> >> compatible. Do we have an overview, which components were released with
> >> such
> >> a name?
> >>
> >> Cheers,
> >> Jörg
> >>
> >> BWT: I am also not convinced by the benefits of Java 9 looking at the
> >> module
> >> system or the multi-version jars. I fear they will rather harm the Java
> >> ecosystem.
> >>
> >
> > Very sad indeed. These are all "features" that break applications left
> and
> > right.
> >
> > Gary
> >
> >
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org  dev-unsubscr...@commons.apache.org>
> >> For additional commands, e-mail: dev-h...@commons.apache.org  dev-h...@commons.apache.org>
>

Re: Ready for JDK 9 ?

[Ralph Goers]

I have my doubts about the module system but I am not sure why you would think 
multi-release jars will cause problems.

Ralph

> On Aug 9, 2017, at 8:28 AM, Gary Gregory  wrote:
> 
> On Wed, Aug 9, 2017 at 1:09 AM, Jörg Schaible <
> joerg.schai...@bpm-inspire.com > wrote:
> 
>> Hi Simon,
>> 
>> Simon Spero wrote:
>> 
>>> Compress HEAD is tested against the equivalent of RC. The main issues
>> were
>>> with tests; some types of mocking (especially of concrete classes) don't
>>> work. This might have been fixed by now.
>>> I believe that the latest jacoco is 9 compatible.
>>> 
>>> [The biggest problem was caused by a bug in the zip code handling a
>>> particular kind of timestamp; massive changes to the jdk implementation
>> of
>>> zip caused tests that had been passing (but shouldn't have) to fail
>>> properly.]
>>> 
>>> NOTE:
>>> 
>>> Adding a Module name manifest header asserts that the code is tested
>>> against Java 9. This is documented in the minutes of the armistice talks.
>>> 
>>> jigsaw modules are pretty useless for most of Commons (consumers pretty
>>> much have to shade dependencies). [ subliminal whisper about benefits of
>>> having correct OSGI headers]
>> 
>> OK, that means we should at least test those releases that contain a Module
>> name now and silently assume, that the other stuff is not necessarily
>> compatible. Do we have an overview, which components were released with
>> such
>> a name?
>> 
>> Cheers,
>> Jörg
>> 
>> BWT: I am also not convinced by the benefits of Java 9 looking at the
>> module
>> system or the multi-version jars. I fear they will rather harm the Java
>> ecosystem.
>> 
> 
> Very sad indeed. These are all "features" that break applications left and
> right.
> 
> Gary
> 
> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@commons.apache.org 
>> 

Re: Ready for JDK 9 ?

[Amey Jadiye]

Hi Jorg,

Yes,  I think rather just checking latest released source we should check
the HEAD of components to ensure we will not break next planned release
with java 9, at least we can fix if there is some issue from java9 RC it
self, that will ensure future stability.

Looking at commons-text latest build via Travis its still using EA,  Java
HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode)., RC is build 9+181.

I have raised requested Travis-ci to update it [1] , lets see.

[1] https://github.com/travis-ci/travis-ci/issues/8233

Regards,
Amey


On Wed, Aug 9, 2017 at 1:33 PM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi Amey,
>
> Amey Jadiye wrote:
>
> > Hmm, isn't that easy with just Travis ? We just have to add java9
> > option(not sure it have RC) and trigger build it will automatically check
> > build and tests. IIRC for few components we are having java9 Travis env
> > already set.
>
> That would only ensure that the head revision runs with the Java 9 version,
> that is supplied by Travis ... is that already the RC?
>
> Cheers,
> Jörg
>
>
> -
> 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: Ready for JDK 9 ?

[Gary Gregory]

On Wed, Aug 9, 2017 at 1:09 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi Simon,
>
> Simon Spero wrote:
>
> > Compress HEAD is tested against the equivalent of RC. The main issues
> were
> > with tests; some types of mocking (especially of concrete classes) don't
> > work. This might have been fixed by now.
> > I believe that the latest jacoco is 9 compatible.
> >
> > [The biggest problem was caused by a bug in the zip code handling a
> > particular kind of timestamp; massive changes to the jdk implementation
> of
> > zip caused tests that had been passing (but shouldn't have) to fail
> > properly.]
> >
> > NOTE:
> >
> > Adding a Module name manifest header asserts that the code is tested
> > against Java 9. This is documented in the minutes of the armistice talks.
> >
> > jigsaw modules are pretty useless for most of Commons (consumers pretty
> > much have to shade dependencies). [ subliminal whisper about benefits of
> > having correct OSGI headers]
>
> OK, that means we should at least test those releases that contain a Module
> name now and silently assume, that the other stuff is not necessarily
> compatible. Do we have an overview, which components were released with
> such
> a name?
>
> Cheers,
> Jörg
>
> BWT: I am also not convinced by the benefits of Java 9 looking at the
> module
> system or the multi-version jars. I fear they will rather harm the Java
> ecosystem.
>

Very sad indeed. These are all "features" that break applications left and
right.

Gary


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

Re: [Math][ALL] Travis failing (with JDK7 but not JDK8)

[sebb]

On 9 August 2017 at 13:51, Gilles  wrote:
> Hi.
>
> Build with Java 8 runs fine:
>   https://travis-ci.org/apache/commons-math/jobs/262647212
>
> But with Java 7:
>   https://travis-ci.org/apache/commons-math/jobs/262647211
>
> Is anyone willing to debug this failure?

1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it cannot
find the current git info
2) Bug in JVM - buffer overflow.

Both of these could happen with any Java version.

> Or is this a hint for making Java 8 the minimum supported
> version for the next release?

That is not a valid conclusion from the evidence.

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

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

[Math][ALL] Travis failing (with JDK7 but not JDK8)

[Gilles]

Hi.

Build with Java 8 runs fine:
  https://travis-ci.org/apache/commons-math/jobs/262647212

But with Java 7:
  https://travis-ci.org/apache/commons-math/jobs/262647211

Is anyone willing to debug this failure?

Or is this a hint for making Java 8 the minimum supported
version for the next release?


Regards,
Gilles


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

Re: [ALL] Automated requirements (e.g. CheckStyle)?

[sebb]

On 9 August 2017 at 03:57, Gilles  wrote:
> On Tue, 8 Aug 2017 18:49:44 -0700, Chas Honton wrote:
>>
>> Since most of us work in an IDE, the "wasted" time of checkstyle for
>> every build is negligible.

IDEs vary in how easy it is to set up the checks to agree with the
project settings.
And IDEs vary in the impact on the build time.

>
> It's not just the wasted time of running the tool (which might
> well be negligible), it's the forcing of e.g. documenting a code
> that might turn out to be transient on the path to a complete
> fix.
>
>> At my day job, all code is automatically
>> reformatted as part of the build. It's just another step along with
>> PMD, CPD, findbugs, sonar, jacoco, junit, and a few other static
>> analyses. The more we automate, the less we need to remember and the
>> higher the quality of our code.
>
>
> That's not always the case: I don't particularly like the "feature"
> of IDEs that automatically inserts Javadoc templates:
>
> /**
>  *
>  *
>  * @param a
>  * @param b
>  * @return int
>  */
> public int doSomething(int a, int b) {
>   // ...
> }
>
> Which then often remain useless as actual documentation. ;-)
>
>
> Regards,
> Gilles
>
>
>>
>> Chas
>>
>>> On Aug 8, 2017, at 4:13 PM, Gilles  wrote:
>>>
>>> Hello.
>>>
 On Wed, 9 Aug 2017 00:20:00 +0200, Karl-Philipp Richter wrote:
 Hi,

> Am 07.08.2017 um 15:09 schrieb Gilles:
> Less work for the maintainers is good. :-)
>
> By "taking time" I meant that validating should not be enforced when
> calling "mvn compile" or "mvn test".

 I wouldn't worry about the time consumption of the validation even if
 it's run by every dev before very compilation since the sum of
 conversation parts in patch/PR discussion in the form of "LGTM, except
 for the indentation at line xy" - "OK, I fixed that now" - "Oh, no wait,
 I forgot the trailing space at line yz" - ... - merged takes an infinite
 more of time and energy.
>>>
>>>
>>> I agree, but that is with respect to interaction with someone not used
>>> to the coding style/rules; what I meant is that when doing one's "own"
>>> work, one shouldn't have to wait for CheckStyle at every compilation,
>>> when you know that you'll fix the missing doc _after_ fixing the code.
>>>
 Regarding the phase where checkstyle should be run I have some
 additional thoughts to my initial post:

  * If running checkstyle will be enforced the only phase that makes
 sense is `validate` because you don't won't to build something that's
 invalid because it's somehow unlogical and a waiste of time if you don't
 fail the build as early as possible. In order to avoid annoyance for
 users who aren't used to fix checkstyle errors before being able to
 build I'd suggest a profile with deactivated checkstyle which allows
 that rather an putting checkstyle in a separate profile.
>>>
>>>
>>> IIUC, that would be fine (since it takes care of the above scenario).
>>>
  * Running checkstyle in the site or any other reporting phase is in
 Maven speak afaik "show what might be wrong with my build given the fact
 that I consider it passing after compilation, unit and integration tests
 passed" or "show me some statistics about style issues - 150, wow that's
 12 less than last build".
>>>
>>>
>>> That's what we've done up to now; and the number of errors is supposed
>>> to be zero before a release.  But I agree that the risk of a lot of work
>>> for the RM would be reduced by enforcing checks at least before
>>> committing
>>> to the "master" branch.
>>>
>>> Is anyone objecting?
>>>
>>> I think that the profile should be defined in the "parent" POM.
>>> Can someone make the necessary additions?
>>>
>>> Thanks,
>>> 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: Ready for JDK 9 ?

[Jörg Schaible]

Hi Simon,

Simon Spero wrote:

> Compress HEAD is tested against the equivalent of RC. The main issues were
> with tests; some types of mocking (especially of concrete classes) don't
> work. This might have been fixed by now.
> I believe that the latest jacoco is 9 compatible.
> 
> [The biggest problem was caused by a bug in the zip code handling a
> particular kind of timestamp; massive changes to the jdk implementation of
> zip caused tests that had been passing (but shouldn't have) to fail
> properly.]
> 
> NOTE:
> 
> Adding a Module name manifest header asserts that the code is tested
> against Java 9. This is documented in the minutes of the armistice talks.
> 
> jigsaw modules are pretty useless for most of Commons (consumers pretty
> much have to shade dependencies). [ subliminal whisper about benefits of
> having correct OSGI headers]

OK, that means we should at least test those releases that contain a Module 
name now and silently assume, that the other stuff is not necessarily 
compatible. Do we have an overview, which components were released with such 
a name?

Cheers,
Jörg

BWT: I am also not convinced by the benefits of Java 9 looking at the module 
system or the multi-version jars. I fear they will rather harm the Java 
ecosystem.



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

Re: Ready for JDK 9 ?

[Jörg Schaible]

Hi Amey,

Amey Jadiye wrote:

> Hmm, isn't that easy with just Travis ? We just have to add java9
> option(not sure it have RC) and trigger build it will automatically check
> build and tests. IIRC for few components we are having java9 Travis env
> already set.

That would only ensure that the head revision runs with the Java 9 version, 
that is supplied by Travis ... is that already the RC?

Cheers,
Jörg


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