Hi,
Here is the PR to disable errorprone with forked compiler:
https://github.com/apache/lucene/pull/12808; it makes no difference in
main, but on 9.x it will fix the issue.
I will merge the commit also to Solr as Jenkins fails there the same way.
Uwe
Am 14.11.2023 um 19:35 schrieb Dawid
Thanks Uwe!
On Tue, Nov 14, 2023 at 7:27 PM Uwe Schindler wrote:
> Hi,
>
> For now the simplest is to disable always is an alternate JVM is used,
> just remove the second part of the first IF statement. In Main it is no
> longer relevant, as the runtime JDK is always >= 17, so it would always
>
Hi,
For now the simplest is to disable always is an alternate JVM is used,
just remove the second part of the first IF statement. In Main it is no
longer relevant, as the runtime JDK is always >= 17, so it would always
trigger the first if.
I would not spend too much time, until errorprone
Hi Dawid,
The problem does not happen on Java 17, because errorprone is not
enabled when the forked JDK is > Java 15. We did this because earlier
versions worked correctly. But new versions of errorprone always fail
when the JDK is forked while compiling.
if (rootProject.usesAltJvm &&
Hi Uwe,
Hah, the issue happens only if you pass CI=true (this is set by CI
> systems), so errorprone is enabled. so do "export CI=true" and then build
> with that config.
>
Darn... I hate that flag. I'll take a look unless you beat me to it.
D.
>
Hi Dawid,
Hah, the issue happens only if you pass CI=true (this is set by CI
systems), so errorprone is enabled. so do "export CI=true" and then
build with that config.
So it looks like a combination of errorprone enabled with Java 11 OpenJ9.
Uwe
Am 13.11.2023 um 09:09 schrieb Dawid Weiss:
I linked to this thread on the upstream (OpenJ9) issue about recent Lucene
CI build failures: https://github.com/eclipse-openj9/openj9/issues/18400
Mike McCandless
http://blog.mikemccandless.com
On Mon, Nov 13, 2023 at 3:09 AM Dawid Weiss wrote:
>
> Sure, thanks. What's strange is that we
Sure, thanks. What's strange is that we don't use add-opens anywhere, I
think (there is a mention of it I left in one of the
comments, but nothing else across the codebase uses this directive).
> Task :lucene:distribution.tests:compileTestJava
warning: [options] --add-opens has no effect at
Will check tomorrow, it's too late now.
On Jenkins there were no windows builds with IBM and Java 11 yet:
https://jenkins.thetaphi.de/job/Lucene-9.x-Windows/
Am 12.11.2023 um 22:00 schrieb Dawid Weiss:
Hi Uwe,
Can you reproduce this on Windows with the same JVM versions though?
Seems like
Hi Uwe,
Can you reproduce this on Windows with the same JVM versions though? Seems
like I have exactly the same setup and yet this works for me just fine.
Strange.
Dawid
On Sun, Nov 12, 2023 at 9:52 PM Uwe Schindler wrote:
> This one was my first idea, too.
>
> It fails only with IBM Semeru
This one was my first idea, too.
It fails only with IBM Semeru in combination with Gradle using Temurin.
I will dig tomorrow on Jenkins server and print all debug info.
Uwe
Am 12. November 2023 21:48:54 MEZ schrieb Dawid Weiss :
>I can't reproduce this though - used exactly the same JVMs (on
I can't reproduce this though - used exactly the same JVMs (on Windows):
> gradlew :lucene:distribution.tests:compileTestJava --rerun-tasks
--console=plain
Generating gradle.properties
...
> Task :altJvmWarning
NOTE: Alternative java toolchain will be used for compilation and tests:
Project
One addition: Solr is affected on same way.
Am 12. November 2023 21:39:07 MEZ schrieb Uwe Schindler :
>Thanks.
>
>I have the feeling it is because of same major version. If Gradle JDK is
>Eclipse Temurin and runtime JDK is same version but OpenJ9 it fails.
>
>Interestingly only in 11 (branch
Thanks.
I have the feeling it is because of same major version. If Gradle JDK is
Eclipse Temurin and runtime JDK is same version but OpenJ9 it fails.
Interestingly only in 11 (branch 9x). On main it worked for long time. Jdk17 as
Gradle runtime by Temurin and openj9 as runtime.
If runtime and
Hi Uwe,
Will dig tomorrow. Maybe Dawid has an idea? It looks like the alternate
> runtime is correctly detected, but why is Gradle passing compiler runzine
> options without -J in just this case. In Main the same works where Gradle
> runs with Java17-Temurin and J9 is used as runtime.
>
I think
It is unclear why this happens with Java 11 version of OpenJ9 only. Java 17
works.
The compiler is forked as Gradle runs with Temurin, J9 is used via
RUNTIME_JAVA_HOME.
Will dig tomorrow. Maybe Dawid has an idea? It looks like the alternate runtime
is correctly detected, but why is Gradle
16 matches
Mail list logo
