[lang] Todo utility class

[Matt Benson]

I have often thought about creating a utility class that allows me to write
skeletal code that still compiles but will remind me to go back and finish
it. This is a weird meta area of programming, but here are some basic usage
examples:

Foo foo = Todo.todo(); //returns null
Bar bar = Todo.todo(THROWING_EXCEPTION); //throws NotImplementedException
Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null and
prints a message to System.err

I would also think it a good (if odd) idea to make the whole class
deprecated so that its use is flagged in tools, etc.

Does the community think this code would be suited to the commons-lang
component?

Matt

[GitHub] commons-text issue #77: Annotated version

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/77
  

[![Coverage 
Status](https://coveralls.io/builds/15979804/badge)](https://coveralls.io/builds/15979804)

Coverage remained the same at 97.74% when pulling 
**0b6585ea4a8bb1e2abdf9b431761adb87db88b04 on NhatDinh:annotated-version** into 
**7d2b51191064626994db6ca91cae968542696788 on apache:master**.



---

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

[GitHub] commons-text pull request #77: Annotated version

[NhatDinh]

Github user NhatDinh closed the pull request at:

https://github.com/apache/commons-text/pull/77


---

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

[GitHub] commons-text pull request #77: Annotated version

[NhatDinh]

GitHub user NhatDinh opened a pull request:

https://github.com/apache/commons-text/pull/77

Annotated version



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/NhatDinh/commons-text annotated-version

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-text/pull/77.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #77


commit bc5d5256d54475a50523b7f6d88a4d1c5ddb3ebc
Author: nd 
Date:   2018-03-11T18:30:41Z

Modified commons-text.xml

commit b76a7af3ea0e2b5e33668fa96f05105a72e6
Author: Nhat Dinh <35314819+nhatdinh@...>
Date:   2018-03-11T18:56:52Z

Update README.md

commit c163d79f1704350267f246756f1064d821c8ab1a
Author: nd 
Date:   2018-03-11T19:26:40Z

Merge branch 'annotated-version' of 
https://github.com/NhatDinh/commons-text into annotated-version

commit 285b609bf231a620abfe9845d769eb75d1136e93
Author: Nhat Dinh <35314819+nhatdinh@...>
Date:   2018-03-11T23:02:13Z

Update README.md

Removed optional

commit 0b6585ea4a8bb1e2abdf9b431761adb87db88b04
Author: nd 
Date:   2018-03-14T20:32:17Z

Updated pom.xml




---

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

[CANCEL][VOTE] Release Commons JCS 2.2.1 based on RC3

[Romain Manni-Bucau]

Think I didn't send the cancel mail - gmail didn't find it at least, if I
did please ignore.

Since the thread is very old and was not straight forward it would be very
weird to keep it now so it is probably cleaner to start fresh with a RC4 or
even a 2.3 a bit later.

Sorry for the delay.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2017-12-28 14:16 GMT+01:00 Jean-Louis MONTEIRO :

> Thanks Romain for pushing this release so hard.
> I have yank JCS from my project and replaced with another impl.
>
> Thanks anyway.
>
>
> Le dim. 24 déc. 2017 à 10:23, Romain Manni-Bucau  a
> écrit :
>
> > My own +1 (dont think the issues we found are worth blocking a release
> but
> > would be happy to get help to solve them next year)
> >
> > And merry Xmas to everybody
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn 
> >
> > 2017-12-23 13:52 GMT+01:00 Jörg Schaible :
> >
> > > Am Sat, 23 Dec 2017 09:06:41 +0100 schrieb Romain Manni-Bucau:
> > >
> > > > Hi Jorg,
> > > >
> > > > It doesnt break IDE support but has some "dead" code from my
> > > > understanding,
> > > > no?
> > >
> > > OK, I should have checked it myself. I got Oliver wrong and thought it
> > > contains only cruft, but the cruft is only
> > > additional ;-)
> > >
> > > In that case I change my vote to +1
> > >
> > > Merry Xmas,
> > > Jörg
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>

Re: Github usage

[Matt Sicker]

When you have a GitHub origin, you can checkout pulls/42/head to check out
PR#42. You can pull/merge from that branch as well to merge the PR (by
committing and pushing that merge, GitHub will notice and mark the PR as
merged). You can also use the "hub" command line tool that GitHub publishes
which adds a bunch of convenience commands to do the same thing.

On 14 March 2018 at 10:19, Gilles  wrote:

> Hi.
>
> On Wed, 14 Mar 2018 14:16:42 +, Otto Fowler wrote:
>
>> I should be more specific, this is for looking at github pr’s.
>> So if your submitters are forking, submitting prs on github.
>>
>> We also have scripts for committing, but we are doing git -> github mirror
>>
>
> My knowledge of "git" is small; my knowledge of GitHub smaller
> (and zero for functionalities that require being logged in). :-}
>
> Assuming a "git" repository (where "origin" is on an Apache server)
> with a local "clone" (i.e. on my machine), is it possible to create
> a branch, say "gimo_work", such that
>
>  $ git checkout gimo_work
>  $ git ... ? ... (equivalent to "pull" wrt "origin")
>
> will retrieve the latest Gimo's commits on the fork made
> from the Apache repository?
>
> Gilles
>
> On March 14, 2018 at 10:15:04, Otto Fowler (ottobackwa...@gmail.com)
>> wrote:
>>
>> We have script to help reviewers checkout PR’s in git, either in their own
>> repo
>> or just doing it in ~/tmp or something into a new repo.
>>
>> So, I would run:
>>
>> checkout-pr 999
>>>
>>
>> in the tmp directory, and end up with a local version that I can then
>> build
>> and do whatever with.
>> would that help?
>>
>>
>> On March 14, 2018 at 10:08:47, Gilles (gil...@harfang.homelinux.org)
>> wrote:
>>
>> On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>>
>>> On Mar 13, 2018, at 11:20 AM, Gilles 
 wrote:


 I didn't find it very easy to cooperate with developers who fork on
 GitHub and submit PRs. I've now found the "git" command that creates a
 branch from a PR, but it would be so much more comfortable to just
 switch directory and do "git pull".


>>> Just as a point of information, it is possible to reverse the Github
>>> <- Apache mirroring most projects use to be Github -> Apache.
>>>
>>
>> It seems that a good-enough-for-me solution would be to "clone"
>> (on my local system) the repository forked by the GSoC participant.
>>
>> Does it make sense?
>>
>> Thanks,
>> Gilles
>>
>> What
>>> that means is that merging PRs from Github becomes one click in the
>>> Github UI.
>>>
>>> There are other consequences, of course, especially related to other
>>> integrations Commons may be using (e.g. integration between Github
>>> and
>>> JIRA).
>>>
>>> Of course, INFRA are the folks to talk to if this sounds interesting.
>>> At Apache Jena, we looked into it but have taken no action because we
>>> still have some open questions about when some of our workflow
>>> integrations will become possible with "reversed mirroring".
>>>
>>> Adam Soroka ; aj...@apache.org
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Matt Sicker 

Re: Github usage

[Gilles]

Hi.

On Wed, 14 Mar 2018 14:16:42 +, Otto Fowler wrote:

I should be more specific, this is for looking at github pr’s.
So if your submitters are forking, submitting prs on github.

We also have scripts for committing, but we are doing git -> github 
mirror


My knowledge of "git" is small; my knowledge of GitHub smaller
(and zero for functionalities that require being logged in). :-}

Assuming a "git" repository (where "origin" is on an Apache server)
with a local "clone" (i.e. on my machine), is it possible to create
a branch, say "gimo_work", such that

 $ git checkout gimo_work
 $ git ... ? ... (equivalent to "pull" wrt "origin")

will retrieve the latest Gimo's commits on the fork made
from the Apache repository?

Gilles

On March 14, 2018 at 10:15:04, Otto Fowler (ottobackwa...@gmail.com) 
wrote:


We have script to help reviewers checkout PR’s in git, either in 
their own

repo
or just doing it in ~/tmp or something into a new repo.

So, I would run:


checkout-pr 999


in the tmp directory, and end up with a local version that I can then 
build

and do whatever with.
would that help?


On March 14, 2018 at 10:08:47, Gilles (gil...@harfang.homelinux.org) 
wrote:


On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:

On Mar 13, 2018, at 11:20 AM, Gilles 
wrote:


I didn't find it very easy to cooperate with developers who fork on
GitHub and submit PRs. I've now found the "git" command that 
creates a

branch from a PR, but it would be so much more comfortable to just
switch directory and do "git pull".



Just as a point of information, it is possible to reverse the Github
<- Apache mirroring most projects use to be Github -> Apache.


It seems that a good-enough-for-me solution would be to "clone"
(on my local system) the repository forked by the GSoC participant.

Does it make sense?

Thanks,
Gilles


What
that means is that merging PRs from Github becomes one click in the
Github UI.

There are other consequences, of course, especially related to other
integrations Commons may be using (e.g. integration between Github
and
JIRA).

Of course, INFRA are the folks to talk to if this sounds 
interesting.
At Apache Jena, we looked into it but have taken no action because 
we

still have some open questions about when some of our workflow
integrations will become possible with "reversed mirroring".

Adam Soroka ; aj...@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 normal : commons-validator #64

[Gary Gregory]

On Wed, Mar 14, 2018 at 8:46 AM, sebb  wrote:

> FIxed by changing the Jenkins JDK to 1.8 (latest).
>
> Also had to exclude some nodes (e.g. cassandra-*) which don't seem to
> have publish rights.
>

Ugh, what a mess :-(

Gary


>
> On 14 March 2018 at 13:42, Apache Jenkins Server
>  wrote:
> > See  >
> >
>
> -
> 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 normal : commons-validator #64

[sebb]

FIxed by changing the Jenkins JDK to 1.8 (latest).

Also had to exclude some nodes (e.g. cassandra-*) which don't seem to
have publish rights.

On 14 March 2018 at 13:42, Apache Jenkins Server
 wrote:
> See 
>

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

Re: Github usage Was: [Statistics] Port codes from Commons Math

[Otto Fowler]

I should be more specific, this is for looking at github pr’s.
So if your submitters are forking, submitting prs on github.

We also have scripts for committing, but we are doing git -> github mirror

On March 14, 2018 at 10:15:04, Otto Fowler (ottobackwa...@gmail.com) wrote:

We have script to help reviewers checkout PR’s in git, either in their own
repo
or just doing it in ~/tmp or something into a new repo.

So, I would run:

> checkout-pr 999

in the tmp directory, and end up with a local version that I can then build
and do whatever with.
would that help?


On March 14, 2018 at 10:08:47, Gilles (gil...@harfang.homelinux.org) wrote:

On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>> On Mar 13, 2018, at 11:20 AM, Gilles 
>> wrote:
>>
>>
>> I didn't find it very easy to cooperate with developers who fork on
>> GitHub and submit PRs. I've now found the "git" command that creates a
>> branch from a PR, but it would be so much more comfortable to just
>> switch directory and do "git pull".
>>
>
> Just as a point of information, it is possible to reverse the Github
> <- Apache mirroring most projects use to be Github -> Apache.

It seems that a good-enough-for-me solution would be to "clone"
(on my local system) the repository forked by the GSoC participant.

Does it make sense?

Thanks,
Gilles

> What
> that means is that merging PRs from Github becomes one click in the
> Github UI.
>
> There are other consequences, of course, especially related to other
> integrations Commons may be using (e.g. integration between Github
> and
> JIRA).
>
> Of course, INFRA are the folks to talk to if this sounds interesting.
> At Apache Jena, we looked into it but have taken no action because we
> still have some open questions about when some of our workflow
> integrations will become possible with "reversed mirroring".
>
> Adam Soroka ; aj...@apache.org


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

Re: Github usage Was: [Statistics] Port codes from Commons Math

[Otto Fowler]

We have script to help reviewers checkout PR’s in git, either in their own
repo
or just doing it in ~/tmp or something into a new repo.

So, I would run:

> checkout-pr 999

in the tmp directory, and end up with a local version that I can then build
and do whatever with.
would that help?


On March 14, 2018 at 10:08:47, Gilles (gil...@harfang.homelinux.org) wrote:

On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>> On Mar 13, 2018, at 11:20 AM, Gilles 
>> wrote:
>>
>>
>> I didn't find it very easy to cooperate with developers who fork on
>> GitHub and submit PRs. I've now found the "git" command that creates a
>> branch from a PR, but it would be so much more comfortable to just
>> switch directory and do "git pull".
>>
>
> Just as a point of information, it is possible to reverse the Github
> <- Apache mirroring most projects use to be Github -> Apache.

It seems that a good-enough-for-me solution would be to "clone"
(on my local system) the repository forked by the GSoC participant.

Does it make sense?

Thanks,
Gilles

> What
> that means is that merging PRs from Github becomes one click in the
> Github UI.
>
> There are other consequences, of course, especially related to other
> integrations Commons may be using (e.g. integration between Github
> and
> JIRA).
>
> Of course, INFRA are the folks to talk to if this sounds interesting.
> At Apache Jena, we looked into it but have taken no action because we
> still have some open questions about when some of our workflow
> integrations will become possible with "reversed mirroring".
>
> Adam Soroka ; aj...@apache.org


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

Re: Github usage Was: [Statistics] Port codes from Commons Math

[Gilles]

On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
On Mar 13, 2018, at 11:20 AM, Gilles  
wrote:



I didn't find it very easy to cooperate with developers who fork on 
GitHub and submit PRs. I've now found the "git" command that creates a 
branch from a PR, but it would be so much more comfortable to just 
switch directory and do "git pull".




Just as a point of information, it is possible to reverse the Github
<- Apache mirroring most projects use to be Github -> Apache.


It seems that a good-enough-for-me solution would be to "clone"
(on my local system) the repository forked by the GSoC participant.

Does it make sense?

Thanks,
Gilles


What
that means is that merging PRs from Github becomes one click in the
Github UI.

There are other consequences, of course, especially related to other
integrations Commons may be using (e.g. integration between Github 
and

JIRA).

Of course, INFRA are the folks to talk to if this sounds interesting.
At Apache Jena, we looked into it but have taken no action because we
still have some open questions about when some of our workflow
integrations will become possible with "reversed mirroring".

Adam Soroka ; aj...@apache.org



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

Re: [Statistics] Port codes from Commons Math

[Gilles]

Hi.

On Tue, 13 Mar 2018 23:37:24 +0530, Gimhana Nadeeshan wrote:

Hello Devs,

Thanks Gilles and Eric for guidance.

I have cloned the Commons repos and forked the Common's Stat repo. Is 
it

possible to make pull requests to that repo to be reviewed?


That's certainly possible, but I'm afraid that it will become
quite unwieldy from my side if I have to delete/create branches
for every PR.

If you want to start playing with the code, we could just begin
by having discussions here (on design) and on JIRA (for processing
minor issues) based on the current state of your repository.
[What's the link to look it up?]


Or should I
follow a specific method?


I'll inquire about a more efficient method (than the above)...

By referring the API docs I got some idea of the separation of 
modules.


In the current Commons's stat repo there are some classes under the
package  distribution. I think those can be refactored using java 8 
in

build statistics functionalities. Please correct me if I wrong.


An example perhaps?

As Eric said separation of function and streaming implementations is 
good
idea as designing. (In my point of view, it means method overloading 
->

Again correct me if I didn't understand your fact correctly)


?


And I will share my draft proposal here for your review soon.


OK.

Thanks again for your interest,
Gilles



Best Regards.

On 13 March 2018 at 20:50, Gilles  
wrote:



Hello.

On Tue, 13 Mar 2018 09:25:19 +0100, Eric Barnhill wrote:

On Tue, Mar 13, 2018 at 12:47 AM, Gilles 


wrote:




Where can we find the old code before port into new Commons 
components?



The code bases are managed by the "git" software; the whole 
history is

available:
  
https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=log


[I'd advise to "clone" the repositories on your local computer, 
and

use the command line tools.]




I believe you will want to clone the commons-math repositories, but 
then
develop your own "fork" of the commons-statistics repository. 
Gilles can

correct me if that is wrong.



Actually, I know only my workflow:
 $ git clone ...
 $ git branch ...
 $ git commit ...
 $ git push

:-}

I didn't find it very easy to cooperate with developers who
fork on GitHub and submit PRs.
I've now found the "git" command that creates a branch from
a PR, but it would be so much more comfortable to just switch
directory and do "git pull".

In the context of GSoC, would it be possible to grant some
privilege to non-committers so that they can update a selected
"git" repository?
If not, what is the next easiest way to share a "common space"
(aka "sandbox") from which it would be easy to copy reviewed
bits over to the official source repository?



As


you mentioned it will be a good approach to redesign process.



You don't necessarily need to analyze how the code was before
the port/refactoring; looking at how it is now is sufficient,
unless you suspect that something is wrong now and might have
been better before. ;-)


In particular, the statistics library was designed before Java 8. 
Java 8
however has provided both efficient programming strategies for 
these
statistical methods (in the form of lambdas and streams) as well as 
some
built-in methods providing summary statistics functions (see 
discussion at

http://markmail.org/message/7t2mjaprsuvb3waj).



Very good point, indeed.
IMO, the new component should be targeted Java 8.
Even Java 9 (enforcing modularity with JPMS): if by the time we 
think
of releasing the code, we still want to avoid "multi-release" JARs 
it
will be easy to just remove the "module-info" files (I don't think 
much

else Java 9 specific would used by "Commons Statistics").

In fact, given the very slow pace at which new components are being
brought to releasable state, I'd like to ask whether it would be OK
to make "incremental" releases?  That would mean: focus on (maven)
modules that seem close to feature-complete and bug-free, fix the
remaining issues and perform a release with that module added.

It seems that the expectations were set to high (content-wise given
the amount of human resources), so that neither CM can be released
(too many non-fixed issues) nor its "Commons Numbers" spin-off that
contains many modules, some of which are blocked by lack of 
consensus

or dangling discussions.

It probably makes sense, as a design strategy, to separate the 
function

implementation from the streaming implementation. For example, a 2D
integer
array will probably require a different streaming implementation 
than a 1D
double array, but they can  probably both be passed the same 
function

handle to collect, say, the mean or max value.

The role of commons might then be to provide a convenient 
interface, so
that the user can simply call a static method like 
SummaryStats.mean() and

not have to worry about the implementation.

The other difficulty I see, is that quantile and median statistics 

Re: [VALIDATOR] Update of packages used by Validator?

[Gilles]

On Tue, 13 Mar 2018 15:51:39 -0400, Rob Tompkins wrote:
On Mar 13, 2018, at 3:48 PM, Gary Gregory  
wrote:


On Tue, Mar 13, 2018 at 1:47 PM, Rob Tompkins  
wrote:

[...]

My plan is to test run commons-parent 45 on the next release. I’m
indifferent over whether it’s Commons Text or Commons Validator. Is 
there a

preference?



Selfishly, I have a need for new Commons Text sooner rather than 
later.


Ok. I’ll try to do both fairly quickly. It shouldn’t be too bad as
the work to release is now smaller.


Hi Rob.

Sorry for further hijacking the thread but... you do know that
[RNG] is in the queue, don't you? ;-)

Regards,
Gilles


[...]



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

AW: Build failed in Jenkins: commons-validator #61

[jhm]

It seems that there is lot of work on the nodes ATM.
So we have to wait for results ...

Jan

> -Ursprüngliche Nachricht-
> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> Gesendet: Mittwoch, 14. März 2018 09:33
> An: 'Commons Developers List'
> Betreff: AW: Build failed in Jenkins: commons-validator #61
> 
> I solved the same problem for commons-email.
> https://builds.apache.org/view/All/job/commons-email/configure
> 
> The project requires via the chosen Maven profile a specific Java
> version.
> This Java installation must be available via a specific environment
> variable "JAVA_1_7_HOME".
> 
> commons-validator sets this to a fixed value, where I don't know this
> location exists on the build node.
> 
> Jenkins could inject the value, but on another name
> "JDK_1_7_LATEST__HOME".
> 'Inject environment variables to the build process > Properties
> Content': "JAVA_1_7_HOME=$JDK_1_7_LATEST__HOME"
> and specify the required value sources via 'Tool Environment'.
> 
> 
> I adapted the email configuration and started a new build.
> 
> 
> Jan
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: sebb [mailto:seb...@gmail.com]
> > Gesendet: Mittwoch, 14. März 2018 00:58
> > An: Commons Developers List
> > Betreff: Re: Build failed in Jenkins: commons-validator #61
> >
> > I think this has happened before.
> >
> > Jenkins now needs Java 8.
> > It attempts recovery but that does not work.
> >
> > On 13 March 2018 at 16:17, Gary Gregory 
> wrote:
> > > Thoughts on how to fix this?
> > >
> > > Gary
> > >
> > > -- Forwarded message -
> > > From: Apache Jenkins Server 
> > > Date: Tue, Mar 13, 2018, 09:48
> > > Subject: Build failed in Jenkins: commons-validator #61
> > > To: 
> > >
> > >
> > > See
> > >  validator/61/display/redirect
> > > >
> > >
> > > --
> > > Started by user ggregory
> > > [EnvInject] - Loading node environment variables.
> > > Building remotely on windows-2012-1 (Windows) in workspace <
> > > https://builds.apache.org/job/commons-validator/ws/>
> > > Updating
> > > https://svn.apache.org/repos/asf/commons/proper/validator/trunk at
> > revision '2018-03-13T15:47:38.139 +'
> > > At revision 1826655
> > >
> > > No changes for
> > > https://svn.apache.org/repos/asf/commons/proper/validator/trunk
> > > since the previous build [EnvInject] - Executing scripts and
> > > injecting environment variables after the SCM step.
> > > [EnvInject] - Injecting as environment variables the properties
> > > content JAVA_1_6_HOME=/home/jenkins/tools/java/latest1.6/
> > >
> > > [EnvInject] - Variables injected successfully.
> > > Parsing POMs
> > > Established TCP socket on 62574
> > > maven35-agent.jar already up to date maven35-interceptor.jar
> already
> > > up to date maven3-interceptor-commons.jar already up to date
> > > [commons-validator] $ f:\\jenkins\\tools\\java\\latest1.7/bin/java
> > > -Xmx2g -Xms256m -cp
> > > f:\jenkins\jenkins-slave\maven35-
> > agent.jar;f:\jenkins\tools\maven\late
> > > st3\boot\plexus-classworlds-
> > 2.5.2.jar;f:\\jenkins\\tools\\maven\\lates
> > > t3/conf/logging jenkins.maven3.agent.Maven35Main
> > > f:\\jenkins\\tools\\maven\\latest3
> > > F:\jenkins\jenkins-slave\slave.jar
> > > f:\jenkins\jenkins-slave\maven35-interceptor.jar
> > > f:\jenkins\jenkins-slave\maven3-interceptor-commons.jar 62574
> > > <===[JENKINS REMOTING CAPACITY]===>   channel started
> > > ERROR:
> > >
> >
> ==
> > > ==
> > > ERROR: Invalid project setup:
> jenkins/security/MasterToSlaveCallable
> > :
> > > Unsupported major.minor version 52.0
> > > ERROR: [JENKINS-18403][JENKINS-28294] JDK 'JDK 1.7 (latest)' not
> > > supported to run Maven projects.
> > > ERROR: Maven projects have to be launched with a Java version
> > > greater or equal to the minimum version required by the master.
> > > ERROR: Use the Maven JDK Toolchains (plugin) to build your maven
> > > project with an older JDK.
> > > ERROR: Retrying with slave Java and setting compile/test properties
> > to
> > > point to f:\\jenkins\\tools\\java\\latest1.7.
> > > ERROR:
> > >
> >
> ==
> > > ==
> > > Established TCP socket on 62579
> > > maven35-agent.jar already up to date maven35-interceptor.jar
> already
> > > up to date maven3-interceptor-commons.jar already up to date
> > > [commons-validator] $ "C:\Program Files\Java\jre1.8.0_152/bin/java"
> > > -Xmx2g -Xms256m -cp
> > > f:\jenkins\jenkins-slave\maven35-
> > agent.jar;f:\jenkins\tools\maven\late
> > > st3\boot\plexus-classworlds-
> > 2.5.2.jar;f:\\jenkins\\tools\\maven\\lates
> > > t3/conf/logging jenkins.maven3.agent.Maven35Main
> > > f:\\jenkins\\tools\\maven\\latest3
> > > F:\jenkins\jenkins-slave\slave.jar
> > > 

AW: Build failed in Jenkins: commons-validator #61

[jhm]

I solved the same problem for commons-email.
https://builds.apache.org/view/All/job/commons-email/configure

The project requires via the chosen Maven profile a specific Java version.
This Java installation must be available via a specific environment variable 
"JAVA_1_7_HOME".

commons-validator sets this to a fixed value, where I don't know this location 
exists on the build node.

Jenkins could inject the value, but on another name "JDK_1_7_LATEST__HOME".
'Inject environment variables to the build process > Properties Content': 
"JAVA_1_7_HOME=$JDK_1_7_LATEST__HOME"
and specify the required value sources via 'Tool Environment'.


I adapted the email configuration and started a new build.


Jan


> -Ursprüngliche Nachricht-
> Von: sebb [mailto:seb...@gmail.com]
> Gesendet: Mittwoch, 14. März 2018 00:58
> An: Commons Developers List
> Betreff: Re: Build failed in Jenkins: commons-validator #61
> 
> I think this has happened before.
> 
> Jenkins now needs Java 8.
> It attempts recovery but that does not work.
> 
> On 13 March 2018 at 16:17, Gary Gregory  wrote:
> > Thoughts on how to fix this?
> >
> > Gary
> >
> > -- Forwarded message -
> > From: Apache Jenkins Server 
> > Date: Tue, Mar 13, 2018, 09:48
> > Subject: Build failed in Jenkins: commons-validator #61
> > To: 
> >
> >
> > See
> > 
> >
> > --
> > Started by user ggregory
> > [EnvInject] - Loading node environment variables.
> > Building remotely on windows-2012-1 (Windows) in workspace <
> > https://builds.apache.org/job/commons-validator/ws/>
> > Updating
> > https://svn.apache.org/repos/asf/commons/proper/validator/trunk at
> revision '2018-03-13T15:47:38.139 +'
> > At revision 1826655
> >
> > No changes for
> > https://svn.apache.org/repos/asf/commons/proper/validator/trunk since
> > the previous build [EnvInject] - Executing scripts and injecting
> > environment variables after the SCM step.
> > [EnvInject] - Injecting as environment variables the properties
> > content JAVA_1_6_HOME=/home/jenkins/tools/java/latest1.6/
> >
> > [EnvInject] - Variables injected successfully.
> > Parsing POMs
> > Established TCP socket on 62574
> > maven35-agent.jar already up to date
> > maven35-interceptor.jar already up to date
> > maven3-interceptor-commons.jar already up to date [commons-validator]
> > $ f:\\jenkins\\tools\\java\\latest1.7/bin/java -Xmx2g -Xms256m -cp
> > f:\jenkins\jenkins-slave\maven35-
> agent.jar;f:\jenkins\tools\maven\late
> > st3\boot\plexus-classworlds-
> 2.5.2.jar;f:\\jenkins\\tools\\maven\\lates
> > t3/conf/logging jenkins.maven3.agent.Maven35Main
> > f:\\jenkins\\tools\\maven\\latest3
> > F:\jenkins\jenkins-slave\slave.jar
> > f:\jenkins\jenkins-slave\maven35-interceptor.jar
> > f:\jenkins\jenkins-slave\maven3-interceptor-commons.jar 62574
> > <===[JENKINS REMOTING CAPACITY]===>   channel started
> > ERROR:
> >
> ==
> > ==
> > ERROR: Invalid project setup: jenkins/security/MasterToSlaveCallable
> :
> > Unsupported major.minor version 52.0
> > ERROR: [JENKINS-18403][JENKINS-28294] JDK 'JDK 1.7 (latest)' not
> > supported to run Maven projects.
> > ERROR: Maven projects have to be launched with a Java version greater
> > or equal to the minimum version required by the master.
> > ERROR: Use the Maven JDK Toolchains (plugin) to build your maven
> > project with an older JDK.
> > ERROR: Retrying with slave Java and setting compile/test properties
> to
> > point to f:\\jenkins\\tools\\java\\latest1.7.
> > ERROR:
> >
> ==
> > ==
> > Established TCP socket on 62579
> > maven35-agent.jar already up to date
> > maven35-interceptor.jar already up to date
> > maven3-interceptor-commons.jar already up to date [commons-validator]
> > $ "C:\Program Files\Java\jre1.8.0_152/bin/java" -Xmx2g -Xms256m -cp
> > f:\jenkins\jenkins-slave\maven35-
> agent.jar;f:\jenkins\tools\maven\late
> > st3\boot\plexus-classworlds-
> 2.5.2.jar;f:\\jenkins\\tools\\maven\\lates
> > t3/conf/logging jenkins.maven3.agent.Maven35Main
> > f:\\jenkins\\tools\\maven\\latest3
> > F:\jenkins\jenkins-slave\slave.jar
> > f:\jenkins\jenkins-slave\maven35-interceptor.jar
> > f:\jenkins\jenkins-slave\maven3-interceptor-commons.jar 62579
> > <===[JENKINS REMOTING CAPACITY]===>   channel started
> > Executing Maven:  -B -f <
> > https://builds.apache.org/job/commons-validator/ws/pom.xml>
> > -Dmaven.repo.local=f:\jenkins\jenkins-slave\maven-repositories\0 -V
> > clean install --batch-mode -Dgpg.skip -Prelease -Pjava-1.6  [1mApache
> > Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> > 2017-10-18T07:58:13Z) [m
> > Maven home: F:\jenkins\tools\maven\latest3 Java version: 1.8.0_152,
> > vendor: Oracle