Re: precommit failures
Created https://issues.apache.org/jira/browse/LUCENE-9041 - will post a patch hopefully today. I'll look at 8.x as well. Kevin Risden On Sat, Nov 9, 2019 at 5:41 PM Uwe Schindler wrote: > Interesting, 8.x uses 3.18... 🤔 > > So let's upgrade both. > > Uwe > > Am November 9, 2019 10:38:33 PM UTC schrieb Uwe Schindler >: >> >> Yes should be easy possible. Just make sure it passes build (and use >> latest version). >> >> Not sure if branch 8.x is affected, but if the same ecj version is used >> there, upgrade it, too. >> >> Uwe >> >> Am November 9, 2019 9:26:42 PM UTC schrieb Kevin Risden < >> kris...@apache.org>: >>> >>> I saw this happen again and on a whim did some googling to see if it was >>> reported/fixed: >>> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=547181 >>> >>> and a duplicate >>> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=550263 >>> >>> These both seem to think that this is fixed in a September build, which >>> I think would be >>> >>> >>> org.eclipse.jdt >>> ecj >>> 3.19.0 >>> >>> >>> The current Lucene build version is 3.17.0: >>> >>> >>> https://github.com/apache/lucene-solr/blob/master/lucene/common-build.xml#L2039 >>> >>> Is it possible that it is simple to just upgrade the ecj version? >>> >>> Kevin Risden >>> >>> >>> On Thu, Jun 13, 2019 at 6:42 PM Chris Hostetter < >>> hossman_luc...@fucit.org> wrote: >>> >>>> >>>> So, FWIW: these ecj/precommit ERRORS related to "javax.naming.*" >>>> packages/classes still seems to be happening periodically >>>> but unpredictibly & unreliably... >>>> >>>> 1) speaking persnally: it happens on my machine periodically, even with >>>> "ant clean precommit" and then goes away the very next time i run "ant >>>> clean precommit" -- w/o any changes to the source code, working dir, >>>> java >>>> version, etc... >>>> >>>> openjdk version "11.0.2" 2019-01-15 >>>> OpenJDK Runtime Environment 18.9 (build 11.0.2+9) >>>> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >>>> >>>> (It's possible it relates to something in the ivy cache, but if so, it >>>> can >>>> aparently "self fix" or "self break" w/o any other java processes >>>> running >>>> on on the machine in the meantime) >>>> >>>> 2) It also happens periodically to jenkins builds, as recently as >>>> yesterday, on multiple jenkins clusters and diff build OSs... >>>> >>>> https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5195/ >>>> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7988/ >>>> https://jenkins.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 past 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 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 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.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 >>>> parameter. >>>> : >>>> : Is Java version really fully identical including vendor? >>>> : >>>> : The strange th
Re: precommit failures
Interesting, 8.x uses 3.18... 🤔 So let's upgrade both. Uwe Am November 9, 2019 10:38:33 PM UTC schrieb Uwe Schindler : >Yes should be easy possible. Just make sure it passes build (and use >latest version). > >Not sure if branch 8.x is affected, but if the same ecj version is used >there, upgrade it, too. > >Uwe > >Am November 9, 2019 9:26:42 PM UTC schrieb Kevin Risden >: >>I saw this happen again and on a whim did some googling to see if it >>was >>reported/fixed: >> >>https://bugs.eclipse.org/bugs/show_bug.cgi?id=547181 >> >>and a duplicate >> >>https://bugs.eclipse.org/bugs/show_bug.cgi?id=550263 >> >>These both seem to think that this is fixed in a September build, >which >>I >>think would be >> >> >>org.eclipse.jdt >>ecj >>3.19.0 >> >> >>The current Lucene build version is 3.17.0: >> >>https://github.com/apache/lucene-solr/blob/master/lucene/common-build.xml#L2039 >> >>Is it possible that it is simple to just upgrade the ecj version? >> >>Kevin Risden >> >> >>On Thu, Jun 13, 2019 at 6:42 PM Chris Hostetter >> >>wrote: >> >>> >>> So, FWIW: these ecj/precommit ERRORS related to "javax.naming.*" >>> packages/classes still seems to be happening periodically >>> but unpredictibly & unreliably... >>> >>> 1) speaking persnally: it happens on my machine periodically, even >>with >>> "ant clean precommit" and then goes away the very next time i run >>"ant >>> clean precommit" -- w/o any changes to the source code, working dir, >>java >>> version, etc... >>> >>> openjdk version "11.0.2" 2019-01-15 >>> OpenJDK Runtime Environment 18.9 (build 11.0.2+9) >>> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >>> >>> (It's possible it relates to something in the ivy cache, but if so, >>it can >>> aparently "self fix" or "self break" w/o any other java processes >>running >>> on on the machine in the meantime) >>> >>> 2) It also happens periodically to jenkins builds, as recently as >>> yesterday, on multiple jenkins clusters and diff build OSs... >>> >>> https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5195/ >>> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7988/ >>> https://jenkins.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 past 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 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 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.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 >>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 in ant's classpath? >>> : >>> : Uwe >>> : >>> : Am May 6, 2019 7:47:45 PM UTC schrieb Erick Erickson < >>> erickerick...@gmail.com>: >>> : >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
Re: precommit failures
Yes should be easy possible. Just make sure it passes build (and use latest version). Not sure if branch 8.x is affected, but if the same ecj version is used there, upgrade it, too. Uwe Am November 9, 2019 9:26:42 PM UTC schrieb Kevin Risden : >I saw this happen again and on a whim did some googling to see if it >was >reported/fixed: > >https://bugs.eclipse.org/bugs/show_bug.cgi?id=547181 > >and a duplicate > >https://bugs.eclipse.org/bugs/show_bug.cgi?id=550263 > >These both seem to think that this is fixed in a September build, which >I >think would be > > >org.eclipse.jdt >ecj >3.19.0 > > >The current Lucene build version is 3.17.0: > >https://github.com/apache/lucene-solr/blob/master/lucene/common-build.xml#L2039 > >Is it possible that it is simple to just upgrade the ecj version? > >Kevin Risden > > >On Thu, Jun 13, 2019 at 6:42 PM Chris Hostetter > >wrote: > >> >> So, FWIW: these ecj/precommit ERRORS related to "javax.naming.*" >> packages/classes still seems to be happening periodically >> but unpredictibly & unreliably... >> >> 1) speaking persnally: it happens on my machine periodically, even >with >> "ant clean precommit" and then goes away the very next time i run >"ant >> clean precommit" -- w/o any changes to the source code, working dir, >java >> version, etc... >> >> openjdk version "11.0.2" 2019-01-15 >> OpenJDK Runtime Environment 18.9 (build 11.0.2+9) >> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >> >> (It's possible it relates to something in the ivy cache, but if so, >it can >> aparently "self fix" or "self break" w/o any other java processes >running >> on on the machine in the meantime) >> >> 2) It also happens periodically to jenkins builds, as recently as >> yesterday, on multiple jenkins clusters and diff build OSs... >> >> https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5195/ >> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7988/ >> https://jenkins.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 past 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 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 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.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 >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 in ant's classpath? >> : >> : Uwe >> : >> : Am May 6, 2019 7:47:45 PM UTC schrieb Erick Erickson < >> erickerick...@gmail.com>: >> : >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. >> : >> >> : >> 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/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java >> : >(at line 28) >> : >>> [ecj-lint] import javax.naming.InitialContext; >
Re: precommit failures
I saw this happen again and on a whim did some googling to see if it was reported/fixed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=547181 and a duplicate https://bugs.eclipse.org/bugs/show_bug.cgi?id=550263 These both seem to think that this is fixed in a September build, which I think would be org.eclipse.jdt ecj 3.19.0 The current Lucene build version is 3.17.0: https://github.com/apache/lucene-solr/blob/master/lucene/common-build.xml#L2039 Is it possible that it is simple to just upgrade the ecj version? Kevin Risden On Thu, Jun 13, 2019 at 6:42 PM Chris Hostetter wrote: > > So, FWIW: these ecj/precommit ERRORS related to "javax.naming.*" > packages/classes still seems to be happening periodically > but unpredictibly & unreliably... > > 1) speaking persnally: it happens on my machine periodically, even with > "ant clean precommit" and then goes away the very next time i run "ant > clean precommit" -- w/o any changes to the source code, working dir, java > version, etc... > > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) > > (It's possible it relates to something in the ivy cache, but if so, it can > aparently "self fix" or "self break" w/o any other java processes running > on on the machine in the meantime) > > 2) It also happens periodically to jenkins builds, as recently as > yesterday, on multiple jenkins clusters and diff build OSs... > > https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5195/ > https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7988/ > https://jenkins.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 past 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 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 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.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 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 in ant's classpath? > : > : Uwe > : > : Am May 6, 2019 7:47:45 PM UTC schrieb Erick Erickson < > erickerick...@gmail.com>: > : >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. > : >> > : >> 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/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java > : >(at line 28) > : >>> [ecj-lint] import javax.naming.InitialContext; > : >>> [ecj-lint]^^^ > : >>> [ecj-lint] The type javax.naming.InitialContext is not accessible``` > : >>> > : >>> This import hasn’t been changed since 2009. > : >>> > : >>> I'm using: openjdk version “11.0.2” 2019-01-15 > : >>> > : >>> I tried a fresh clone of master and cleaned the ivy cache, still the > : >same problem. But we can't be the only ones seeing this, any clues? > : >>> > : >- > : >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >
Re: precommit failures
So, FWIW: these ecj/precommit ERRORS related to "javax.naming.*" packages/classes still seems to be happening periodically but unpredictibly & unreliably... 1) speaking persnally: it happens on my machine periodically, even with "ant clean precommit" and then goes away the very next time i run "ant clean precommit" -- w/o any changes to the source code, working dir, java version, etc... openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) (It's possible it relates to something in the ivy cache, but if so, it can aparently "self fix" or "self break" w/o any other java processes running on on the machine in the meantime) 2) It also happens periodically to jenkins builds, as recently as yesterday, on multiple jenkins clusters and diff build OSs... https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5195/ https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7988/ https://jenkins.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 past 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 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 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.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 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 in ant's classpath? : : Uwe : : Am May 6, 2019 7:47:45 PM UTC schrieb 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. : >> : >> 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/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java : >(at line 28) : >>> [ecj-lint] import javax.naming.InitialContext; : >>> [ecj-lint]^^^ : >>> [ecj-lint] The type javax.naming.InitialContext is not accessible``` : >>> : >>> This import hasn’t been changed since 2009. : >>> : >>> I'm using: openjdk version “11.0.2” 2019-01-15 : >>> : >>> I tried a fresh clone of master and cleaned the ivy cache, still the : >same problem. But we can't be the only ones seeing this, any clues? : >>> : >- : >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org : >>> For additional commands, e-mail: dev-h...@lucene.apache.org : >>> : >> : >> - : >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org : >> For additional commands, e-mail: dev-h...@lucene.apache.org : >> : > : > : >- : >To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org : >For additional commands, e-mail: dev-h...@lucene.apache.org : : -- : Uwe Schindler : Achterdiek 19, 28357 Bremen : https://www.thetaphi.de -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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 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 in ant's classpath? Uwe Am May 6, 2019 7:47:45 PM UTC schrieb 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. >> >> 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/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java >(at line 28) >>> [ecj-lint] import javax.naming.InitialContext; >>> [ecj-lint]^^^ >>> [ecj-lint] The type javax.naming.InitialContext is not accessible``` >>> >>> This import hasn’t been changed since 2009. >>> >>> I'm using: openjdk version “11.0.2” 2019-01-15 >>> >>> I tried a fresh clone of master and cleaned the ivy cache, still the >same problem. But we can't be the only ones seeing this, any clues? >>> >- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > >- >To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >For additional commands, e-mail: dev-h...@lucene.apache.org -- Uwe Schindler Achterdiek 19, 28357 Bremen https://www.thetaphi.de
Re: precommit failures
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. > > 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/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java >> (at line 28) >> [ecj-lint] import javax.naming.InitialContext; >> [ecj-lint]^^^ >> [ecj-lint] The type javax.naming.InitialContext is not accessible``` >> >> This import hasn’t been changed since 2009. >> >> I'm using: openjdk version “11.0.2” 2019-01-15 >> >> I tried a fresh clone of master and cleaned the ivy cache, still the same >> problem. But we can't be the only ones seeing this, any clues? >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: precommit failures
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/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java > (at line 28) > [ecj-lint] import javax.naming.InitialContext; > [ecj-lint]^^^ > [ecj-lint] The type javax.naming.InitialContext is not accessible``` > > This import hasn’t been changed since 2009. > > I'm using: openjdk version “11.0.2” 2019-01-15 > > I tried a fresh clone of master and cleaned the ivy cache, still the same > problem. But we can't be the only ones seeing this, any clues? > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
precommit failures
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]^^^ [ecj-lint] The type javax.naming.InitialContext is not accessible``` This import hasn’t been changed since 2009. I'm using: openjdk version “11.0.2” 2019-01-15 I tried a fresh clone of master and cleaned the ivy cache, still the same problem. But we can't be the only ones seeing this, any clues? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Precommit failures
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 you're the pigeon, and sometimes you're the statue... On Mon, Mar 11, 2019 at 9:56 AM Erick Erickson wrote: > > 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Precommit failures
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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Precommit failures
Requirements for javadocs vary between Lucene and Solr (and between packages) as far as I understand it. https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.3.0/lucene/build.xml#L156-L199 is for Lucene and there is a semi-equivalent at https://github.com/apache/lucene-solr/blob/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 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 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] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [echo] Checking for missing docs... [exec] [exec] build/docs/spatial3d/org/apache/lucene/spatial3d/geom/SidedPlane.html [exec] missing Methods: strictlyWithin-double-double-double- [exec] missing Methods: strictlyWithin-org.apache.lucene.spatial3d.geom.Vector- [exec] [exec] Missing javadocs were found! Anyone have a clue? I don't see Jenkins failures for this so maybe it's just me somehow. Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
Re: Precommit failures
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 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] Checking for broken links... >> [exec] >> [exec] Crawl/parse... >> [exec] >> [exec] Verify... >> [echo] Checking for missing docs... >> [exec] >> [exec] >> build/docs/spatial3d/org/apache/lucene/spatial3d/geom/SidedPlane.html >> [exec] missing Methods: strictlyWithin-double-double-double- >> [exec] missing Methods: >> strictlyWithin-org.apache.lucene.spatial3d.geom.Vector- >> [exec] >> [exec] Missing javadocs were found! >> >> Anyone have a clue? I don't see Jenkins failures for this so maybe >> it's just me somehow. >> >> Erick >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Precommit failures
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: > > [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] Checking for broken links... > [exec] > [exec] Crawl/parse... > [exec] > [exec] Verify... > [echo] Checking for missing docs... > [exec] > [exec] build/docs/spatial3d/org/apache/lucene/spatial3d/geom/ > SidedPlane.html > [exec] missing Methods: strictlyWithin-double-double-double- > [exec] missing Methods: > strictlyWithin-org.apache.lucene.spatial3d.geom.Vector- > [exec] > [exec] Missing javadocs were found! > > Anyone have a clue? I don't see Jenkins failures for this so maybe > it's just me somehow. > > Erick > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Precommit failures
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 all public methods *do* have javadocs, unless they're overriding a method in a parent class/interface that already has javadoc. (IDEs will display the parent javadoc in those cases) I find it frustrating when I'm using a public API in a library and it's not documented to show how it can be used. While it's true that good choices for all the class/method/parameter names can sometimes make the exposed API self-documenting, often the usage is just too complex for that, or has gotchas that require explanation. Probably a good idea for all public fields to have javadoc as well, but I wouldn't expect that to be a requirement.If javadoc on "protected" items is published, then I think those should require javadoc too, so someone extending the class will know what those things do. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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 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 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] Checking for broken links... > [exec] > [exec] Crawl/parse... > [exec] > [exec] Verify... > [echo] Checking for missing docs... > [exec] > [exec] > build/docs/spatial3d/org/apache/lucene/spatial3d/geom/SidedPlane.html > [exec] missing Methods: strictlyWithin-double-double-double- > [exec] missing Methods: > strictlyWithin-org.apache.lucene.spatial3d.geom.Vector- > [exec] > [exec] Missing javadocs were found! > > Anyone have a clue? I don't see Jenkins failures for this so maybe > it's just me somehow. > > Erick > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
Precommit failures
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] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [echo] Checking for missing docs... [exec] [exec] build/docs/spatial3d/org/apache/lucene/spatial3d/geom/SidedPlane.html [exec] missing Methods: strictlyWithin-double-double-double- [exec] missing Methods: strictlyWithin-org.apache.lucene.spatial3d.geom.Vector- [exec] [exec] Missing javadocs were found! Anyone have a clue? I don't see Jenkins failures for this so maybe it's just me somehow. Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
precommit failures
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
