s.thetaphi.de/job/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
ast few days, in
>>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 see
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 8x builds (even when using
>> jdk11 i think because precommit on 8x doesn't do this check
>anymore?)
>> and it doesn't
t do this check anymore?)
> 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
>
ate: Mon, 06 May 2019 20: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
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 ecj
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
> /Users/Erick/apache/solrVersions/play
Both Kevin Risden and I are seeing:
[ecj-lint] 1. ERROR in
/Users/Erick/apache/solrVersions/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 28)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]
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 y
My new precommit failure for Solr test classes driving directly from
LuceneTestCase is giving a spurious error. If you see "Solr test cases should
extend SolrTestCase rather than LuceneTestCase” ignore it, I’ll fix momentarily.
Sorry for the noise
Erick
--
/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. B
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
> wrote:
>>
>> I'm getting this pr
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:
>
> -documentation-lint:
>
> [ec
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 that
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 precommit failure on a fresh clon
I'm getting this precommit failure on a fresh clone of master:
-documentation-lint:
[echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
[delete] Deleting directory
/Users/Erick/apache/solrVersions/solr-12028/lucene/build/jtidy_tmp
[echo
Some unused imports, I'll check the fix in as part of SOLR-10101 shortly
Erick
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
18 matches
Mail list logo