precommit failures

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

precommit failures

Erick Erickson

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: precommit failures

Dawid Weiss-2
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: precommit failures

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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: precommit failures

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 ecj in ant's classpath?

Uwe

Am May 6, 2019 7:47:45 PM UTC schrieb Erick Erickson <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]


To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
Reply | Threaded
Open this post in threaded view
|

Re: precommit failures

Chris Hostetter-3

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 +0000
: From: Uwe Schindler <[hidden email]>
: Reply-To: [hidden email]
: To: [hidden email], Erick Erickson <[hidden email]>
: 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 <[hidden email]>:
: >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 <[hidden email]>
: >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
: ><[hidden email]> 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: [hidden email]
: >>> For additional commands, e-mail: [hidden email]
: >>>
: >>
: >> ---------------------------------------------------------------------
: >> To unsubscribe, e-mail: [hidden email]
: >> For additional commands, e-mail: [hidden email]
: >>
: >
: >
: >---------------------------------------------------------------------
: >To unsubscribe, e-mail: [hidden email]
: >For additional commands, e-mail: [hidden email]
:
: --
: Uwe Schindler
: Achterdiek 19, 28357 Bremen
: https://www.thetaphi.de

-Hoss
http://www.lucidworks.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: precommit failures

Kevin Risden-3
I saw this happen again and on a whim did some googling to see if it was reported/fixed:


and a duplicate


These both seem to think that this is fixed in a September build, which I think would be 

<dependency>
    <groupId>org.eclipse.jdt</groupId>
    <artifactId>ecj</artifactId>
    <version>3.19.0</version>
</dependency>


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 <[hidden email]> 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 +0000
: From: Uwe Schindler <[hidden email]>
: Reply-To: [hidden email]
: To: [hidden email], Erick Erickson <[hidden email]>
: 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 <[hidden email]>:
: >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 <[hidden email]>
: >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
: ><[hidden email]> 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: [hidden email]
: >>> For additional commands, e-mail: [hidden email]
: >>>
: >>
: >> ---------------------------------------------------------------------
: >> To unsubscribe, e-mail: [hidden email]
: >> For additional commands, e-mail: [hidden email]
: >>
: >
: >
: >---------------------------------------------------------------------
: >To unsubscribe, e-mail: [hidden email]
: >For additional commands, e-mail: [hidden email]
:
: --
: Uwe Schindler
: Achterdiek 19, 28357 Bremen
: https://www.thetaphi.de

-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: precommit failures

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 <[hidden email]>:
I saw this happen again and on a whim did some googling to see if it was reported/fixed:


and a duplicate


These both seem to think that this is fixed in a September build, which I think would be 

<dependency>
    <groupId>org.eclipse.jdt</groupId>
    <artifactId>ecj</artifactId>
    <version>3.19.0</version>
</dependency>


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 <[hidden email]> 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 +0000
: From: Uwe Schindler <[hidden email]>
: Reply-To: [hidden email]
: To: [hidden email], Erick Erickson <[hidden email]>
: 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 <[hidden email]>:
: >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 <[hidden email]>
: >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
: ><[hidden email]> 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: [hidden email]
: >>> For additional commands, e-mail: [hidden email]
: >>>
: >>
: >> ---------------------------------------------------------------------
: >> To unsubscribe, e-mail: [hidden email]
: >> For additional commands, e-mail: [hidden email]
: >>
: >
: >
: >---------------------------------------------------------------------
: >To unsubscribe, e-mail: [hidden email]
: >For additional commands, e-mail: [hidden email]
:
: --
: Uwe Schindler
: Achterdiek 19, 28357 Bremen
: https://www.thetaphi.de

-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
Reply | Threaded
Open this post in threaded view
|

Re: precommit failures

Uwe Schindler
Interesting, 8.x uses 3.18... 🤔

So let's upgrade both.

Uwe

Am November 9, 2019 10:38:33 PM UTC schrieb Uwe Schindler <[hidden email]>:
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 <[hidden email]>:
I saw this happen again and on a whim did some googling to see if it was reported/fixed:


and a duplicate


These both seem to think that this is fixed in a September build, which I think would be 

<dependency>
    <groupId>org.eclipse.jdt</groupId>
    <artifactId>ecj</artifactId>
    <version>3.19.0</version>
</dependency>


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 <[hidden email]> 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 +0000
: From: Uwe Schindler <[hidden email]>
: Reply-To: [hidden email]
: To: [hidden email], Erick Erickson <[hidden email]>
: 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 <[hidden email]>:
: >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 <[hidden email]>
: >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
: ><[hidden email]> 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: [hidden email]
: >>> For additional commands, e-mail: [hidden email]
: >>>
: >>
: >> ---------------------------------------------------------------------
: >> To unsubscribe, e-mail: [hidden email]
: >> For additional commands, e-mail: [hidden email]
: >>
: >
: >
: >---------------------------------------------------------------------
: >To unsubscribe, e-mail: [hidden email]
: >For additional commands, e-mail: [hidden email]
:
: --
: Uwe Schindler
: Achterdiek 19, 28357 Bremen
: https://www.thetaphi.de

-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
Reply | Threaded
Open this post in threaded view
|

Re: precommit failures

Kevin Risden-3
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
I saw this happen again and on a whim did some googling to see if it was reported/fixed:


and a duplicate


These both seem to think that this is fixed in a September build, which I think would be 

<dependency>
    <groupId>org.eclipse.jdt</groupId>
    <artifactId>ecj</artifactId>
    <version>3.19.0</version>
</dependency>


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 <[hidden email]> 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 +0000
: From: Uwe Schindler <[hidden email]>
: Reply-To: [hidden email]
: To: [hidden email], Erick Erickson <[hidden email]>
: 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 <[hidden email]>:
: >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 <[hidden email]>
: >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
: ><[hidden email]> 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: [hidden email]
: >>> For additional commands, e-mail: [hidden email]
: >>>
: >>
: >> ---------------------------------------------------------------------
: >> To unsubscribe, e-mail: [hidden email]
: >> For additional commands, e-mail: [hidden email]
: >>
: >
: >
: >---------------------------------------------------------------------
: >To unsubscribe, e-mail: [hidden email]
: >For additional commands, e-mail: [hidden email]
:
: --
: Uwe Schindler
: Achterdiek 19, 28357 Bremen
: https://www.thetaphi.de

-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de