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
&
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
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
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
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
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
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.
>
>
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
>
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
/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
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
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:
>
>
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
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
14 matches
Mail list logo