Re: precommit failures

2019-11-11 Thread Kevin Risden
ob/Lucene-Solr-master-Linux/24208/ >>>> https://builds.apache.org/job/Lucene-Solr-Tests-master/3365/ >>>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1360/ >>>> >>>> ...that's just a handful of examples from the past few days, in &

Re: precommit failures

2019-11-09 Thread Uwe Schindler
n >>generally >>> ERRORs that start with "The type javax.naming." seem to pop up on at >>least >>> 1 jenkins build a day. >>> >>> The only commonality seems to be builds of *master* using jdk11 >>> ... it doesn't seem to pop up in any 8

Re: precommit failures

2019-11-09 Thread Uwe Schindler
build a day. >> >> The only commonality seems to be builds of *master* using jdk11 >> ... it doesn't seem to pop up in any 8x builds (even when using >> jdk11 i think because precommit on 8x doesn't do this check >anymore?) >> and it doesn't show up in Policeman mas

Re: precommit failures

2019-11-09 Thread Kevin Risden
ore?) > and it doesn't show up in Policeman master builds using jdk12 & jdk13 > > anybody have any idea WTF is happening here? > > > > > : Date: Mon, 06 May 2019 20:25:46 + > : From: Uwe Schindler > : Reply-To: dev@lucene.apache.org > : To: dev@lucene.apache.o

Re: precommit failures

2019-06-13 Thread Chris Hostetter
25:46 + : From: Uwe Schindler : Reply-To: dev@lucene.apache.org : To: dev@lucene.apache.org, Erick Erickson : Subject: Re: precommit failures : : I am not fully sure if the "java.naming" module is enabled by default in Java 11. Maybe that's a side effect of some global configuration p

Re: precommit failures

2019-05-06 Thread Uwe Schindler
I am not fully sure if the "java.naming" module is enabled by default in Java 11. Maybe that's a side effect of some global configuration parameter. Is Java version really fully identical including vendor? The strange thing is that only ecj breaks. Could it be that you have older version of

Re: precommit failures

2019-05-06 Thread Erick Erickson
Weirder and weirder. My mac pro precommits successfully, same Java version but my MBP fails every time. > On May 6, 2019, at 9:03 AM, Dawid Weiss wrote: > > I had it this morning before committing the fst patch from Mike. > Cleaned the repo, re-ran precommit and it passed... Very strange. > >

Re: precommit failures

2019-05-06 Thread Dawid Weiss
I had it this morning before committing the fst patch from Mike. Cleaned the repo, re-ran precommit and it passed... Very strange. D. On Mon, May 6, 2019 at 5:53 PM Erick Erickson wrote: > > > Both Kevin Risden and I are seeing: > > [ecj-lint] 1. ERROR in >

Re: Precommit failures

2019-03-11 Thread Erick Erickson
Fixed, a new pull should fix things. I suspect the various test machines didn't have "solr/" in the path which was the trigger for testing whether LuceneTestCase was extended. Who'd a thunk somebody might clone the code into a directory with "lucene-solr/" in its ancestry. Siiiggghhh. Sometimes

Re: Precommit failures

2018-04-13 Thread Christine Poerschke (BLOOMBERG/ LONDON)
/releases/lucene-solr/7.3.0/solr/build.xml#L678 for Solr. Christine From: dev@lucene.apache.org At: 04/13/18 03:56:17To: dev@lucene.apache.org Subject: Re: Precommit failures It's happening to me too! I added a /** anything */ comment on these two methods and the warning went away. But we

Re: Precommit failures

2018-04-13 Thread Erick Erickson
Thanks all! On Thu, Apr 12, 2018 at 8:28 PM, Karl Wright wrote: > I've been having inconsistent runs of precommit. Sometimes it complains, > sometimes not. But easily fixed -- I'll push javadoc now. > > Karl > > On Thu, Apr 12, 2018 at 8:50 PM, Erick Erickson

Re: Precommit failures

2018-04-12 Thread Karl Wright
I've been having inconsistent runs of precommit. Sometimes it complains, sometimes not. But easily fixed -- I'll push javadoc now. Karl On Thu, Apr 12, 2018 at 8:50 PM, Erick Erickson wrote: > I'm getting this precommit failure on a fresh clone of master: > >

Re: Precommit failures

2018-04-12 Thread Shawn Heisey
On 4/12/2018 8:56 PM, David Smiley wrote: It's happening to me too!  I added a /** anything */ comment on these two methods and the warning went away.  But we don't have rules about requiring comments on public methods (I thought)? I thought the point of the javadoc check was to make sure

Re: Precommit failures

2018-04-12 Thread David Smiley
It's happening to me too! I added a /** anything */ comment on these two methods and the warning went away. But we don't have rules about requiring comments on public methods (I thought)? On Thu, Apr 12, 2018 at 8:51 PM Erick Erickson wrote: > I'm getting this