Apologies for not replying yesterday and thank you, Greg, for answering the
question.
All I could add is that it's a pretty common semantic versioning scheme
[1], although there is no rigorous method of policing it - very often it's
just relying on common sense. Lucene often does add big code chan
Hi Jonathan-
The main branch is the tip of development, and what will eventually become
10.0. It can use a later version of Java, make (some)
non-backwards-compatible API changes, etc. branch_9x tracks the latest 9.x
release, and must run on the version of Java supported by 9.x releases,
must be A
Thanks. What are the rules for what should go into main vs branch_9x?
On Fri, May 5, 2023 at 1:54 PM Dawid Weiss wrote:
>
> The main branch is on Java 17, see build.gradle:
>
> // Minimum Java version required to compile and run Lucene.
> minJavaVersion = JavaVersion.VERSION_17
>
> Also, do
The main branch is on Java 17, see build.gradle:
// Minimum Java version required to compile and run Lucene.
minJavaVersion = JavaVersion.VERSION_17
Also, don't use the default gradle task created by convention; use this one:
./gradlew mavenToLocal
it's an alias but it publishes only a subs
Actually my hack doesn't work, the manifest file changes but the .class
files do not.
On Fri, May 5, 2023 at 12:38 PM Jonathan Ellis wrote:
> `./gradlew publishToMavenLocal` gives me Java 17 class files by default,
> which surprises me since AFAIK 11 is still the minimum to run Lucene.
>
> I hac
`./gradlew publishToMavenLocal` gives me Java 17 class files by default,
which surprises me since AFAIK 11 is still the minimum to run Lucene.
I hacked it to work by editing javac.gradle
sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11
Is there a c
e great to allow a lot of folks to make a "take two" on these
>>>> algorithms with vectorization in mind. This is just my opinion.
>>>>
>>>> On Mon, Sep 13, 2021 at 2:10 PM Uwe Schindler wrote:
>>>> >
>>>> > There are no good re
no good reasons to do Java 17 and it is way too early.
>>>> >
>>>> >
>>>> >
>>>> > Reagrding real optimizations, Lucene 17 is unfortunately not containing
>>>> > Project Panama or Vector API, so it lo
zation in mind. This is just my opinion.
>>>
>>> On Mon, Sep 13, 2021 at 2:10 PM Uwe Schindler wrote:
>>> >
>>> > There are no good reasons to do Java 17 and it is way too early.
>>> >
>>> >
>>> >
>>> > Reagrd
gt; >
>> >
>> > Reagrding real optimizations, Lucene 17 is unfortunately not containing
>> Project Panama or Vector API, so it looks more like Java 18/19 is a good
>> candidate as a new minimum at a later stage.
>> >
>> >
>> >
>> >
>
> >
> >
> > Reagrding real optimizations, Lucene 17 is unfortunately not containing
> Project Panama or Vector API, so it looks more like Java 18/19 is a good
> candidate as a new minimum at a later stage.
> >
> >
> >
> > I’d release Lucene 9 with J
d it is way too early.
>
>
>
> Reagrding real optimizations, Lucene 17 is unfortunately not containing
> Project Panama or Vector API, so it looks more like Java 18/19 is a good
> candidate as a new minimum at a later stage.
>
>
>
> I’d release Lucene 9 with Java 11 (which is
There are no good reasons to do Java 17 and it is way too early.
Reagrding real optimizations, Lucene 17 is unfortunately not containing Project
Panama or Vector API, so it looks more like Java 18/19 is a good candidate as a
new minimum at a later stage.
I’d release Lucene 9 with Java 11
Hi Devs,
What are our thoughts on Java 11 and 17 version compatibility going forward
for Lucene 9? Will we support both? If so, would Java 11 support likely
continue for the entire 9.x release line?
Is there a JIRA tracking this?
Thanks,
Mike
trimming down the Solr distribution. There's no good reason for Solr, which
>>> is in effect just a distributed layer on top of Lucene, to be a 200MB
>>> download.
>>>
>>> On Fri, 30 Oct, 2020, 9:50 pm Uwe Schindler, wrote:
>>>
>>>> I
> If we can't support it, there's no need to keep it. If someone wants, they
> can assume ownership of a third party package.
I am the author/ owner of that third party package, Ishan... and I've
been working for two weeks to understand how Solr distributed
processing works so that I could write
2020, 9:50 pm Uwe Schindler, wrote:
>>
>>> I fully agree with Erick,
>>>
>>> Please don't start and try to get 8.x on Java 11. Release Lucene/Solr 9!
>>>
>>> Uwe
>>>
>>> -
>>> Uwe Schindler
>>> Achter
; download.
>
> On Fri, 30 Oct, 2020, 9:50 pm Uwe Schindler, wrote:
>
>> I fully agree with Erick,
>>
>> Please don't start and try to get 8.x on Java 11. Release Lucene/Solr 9!
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> Achter
lr, which
is in effect just a distributed layer on top of Lucene, to be a 200MB
download.
On Fri, 30 Oct, 2020, 9:50 pm Uwe Schindler, wrote:
> I fully agree with Erick,
>
> Please don't start and try to get 8.x on Java 11. Release Lucene/Solr 9!
>
> Uwe
>
> -
> U
I fully agree with Erick,
Please don't start and try to get 8.x on Java 11. Release Lucene/Solr 9!
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: [email protected]
> -Original Message-
> From: Erick Erickson
> Sent: Friday, October 30
LR-14974 is about a contrib, the clustering contrib in particular.
> That contrib is a plugin, and it will eventually be "packaged" --
> https://issues.apache.org/jira/browse/SOLR-14688 which will ultimately
> mean that someone running on Solr 8 that is also using Java 11 can i
ntrib, the clustering contrib in particular. That
> contrib is a plugin, and it will eventually be "packaged" --
> https://issues.apache.org/jira/browse/SOLR-14688 which will ultimately mean
> that someone running on Solr 8 that is also using Java 11 can install that
> package
SOLR-14974 is about a contrib, the clustering contrib in particular. That
contrib is a plugin, and it will eventually be "packaged" --
https://issues.apache.org/jira/browse/SOLR-14688 which will ultimately mean
that someone running on Solr 8 that is also using Java 11 can install th
I’m always reluctant to change something like this for a point release.
I’ve been supposing that we’d release Solr 9 for a while, I always thought
that moving to Java 11 would be a driver for the 9.0 release but I wasn’t
correct in that.
That expectation has been complicated by the whole
I've run into this in SOLR-14974. The dependency is on Java 11.
Everything works if you build and run under Java 11 but of course it
won't fly on Java 8 (won't even compile).
I wonder what are your thoughts on keeping Java 8 as the minimum for
Solr 8x. Is 8.x going to be on Java 8
om: [email protected]
> Sent: Monday, August 31, 2020 10:52 AM
> To: [email protected]
> Subject: [lucene-solr] branch master updated: master is on java 11!
>
> This is an automated email from the ASF dual-hosted git repository.
>
> rmuir pushed a commit to branch m
om: Adrien Grand
Sent: Sunday, August 30, 2020 9:00 AM
To: Lucene Dev
Subject: Re: Performance in Solr 9 / Java 11
Tomoko is correct, an MR JAR is created not only upon release but also every
time you create a lucene-core JAR on branch_8x.
On Sun, Aug 30, 2020 at 5:49 AM Tom
master branch when the minimum java version
> was bumped up to java 11 (LUCENE-8738); if my understanding is correct.
>
> $ jar tf core/lucene-core-8.6.1.jar | grep META-INF/versions
> META-INF/versions/
> META-INF/versions/9/
> META-INF/versions/9/org/
> META-INF/versions/9/org
I believe mr-jar build is enabled in the 8x branch (LUCENE-7966), and the
workaround was dropped on the master branch when the minimum java version
was bumped up to java 11 (LUCENE-8738); if my understanding is correct.
$ jar tf core/lucene-core-8.6.1.jar | grep META-INF/versions
META-INF
e to use in my current
>> work today. I have suspicions that there may be some performance
>> improvements in Java 11 that we can exploit further. I'm curious as to if
>> there has been any investigation, possibly Mark Miller or
>> @[email protected] , into performance
that there may be some performance
> improvements in Java 11 that we can exploit further. I'm curious as to if
> there has been any investigation, possibly Mark Miller or @[email protected]
> , into performance improvements specific to the newer
> version of Java in Master? There a
In my IDE, I have a few profiling tools that I bounce between that I
started using in my work at Lucidworks but I continue to use in my current
work today. I have suspicions that there may be some performance
improvements in Java 11 that we can exploit further. I'm curious as to if
there has
[
https://issues.apache.org/jira/browse/SOLR-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed SOLR-13631.
---
> Java 11 date parsing causing NPEs
> -
>
>
[
https://issues.apache.org/jira/browse/SOLR-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-13631.
-
Resolution: Duplicate
I dug into this; see my first comment on : SOLR-13606
> Java 11 d
blem if Lucene.
> Java 11 date parsing causing NPEs
> -
>
> Key: SOLR-13631
> URL: https://issues.apache.org/jira/browse/SOLR-13631
> Project: Solr
> Issue Type: Improvement
> Securit
ion:
{code}
[ishan@chromebox core] $ java -version
openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment 18.9 (build 11.0.3+7)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode, sharing)
{code}
Kernel: 5.1.16-300.fc30.x86_64
JDK was installed via "sudo dnf instal
edora 30
Java version:
{code}
[ishan@chromebox core] $ java -version
openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment 18.9 (build 11.0.3+7)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode, sharing)
{code}
Kernel: 5.1.16-300.fc30.x86_64
> Java 11 date par
Ishan Chattopadhyaya created SOLR-13631:
---
Summary: Java 11 date parsing causing NPEs
Key: SOLR-13631
URL: https://issues.apache.org/jira/browse/SOLR-13631
Project: Solr
Issue Type
"testing" versions of 13 are affected by
JDK-8224829, but I don't actually know how to verify that)
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: http
running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>
nditional assigment, rendering the conditional logic useless
(cherry picked from commit c8c2f2f25b28da694fae88868b12347bc5a2393c)
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
>
nditional assigment, rendering the conditional logic useless
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
>
mmit 150e4f9863147354a489bbd62519bf2e586f41b9 in lucene-solr's branch
refs/heads/branch_8x from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=150e4f9 ]
SOLR-12988: Revert changes
> Skip running tests with SSL on Java
mmit e3752e87d005d407108f95e72b14c82d60f1c082 in lucene-solr's branch
refs/heads/master from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e3752e8 ]
SOLR-12988: Revert changes
> Skip running tests with SSL on Java
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Attachment: (was: SOLR-12988.patch)
> Skip running tests with SSL on Java 11 to 11.
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Attachment: SOLR-12988.patch
> Skip running tests with SSL on Java 11 to 11.
and the problem, we just need a way to handle the test
now which it seems you will handle it properly and more stable than me.
Just a note here, since the awaitsFix of Mark 6 months ago + the enforcment of
using Java 11 on master. None tests on master were run with HTTPS. Hoping that
this issue
good" patch (that can be backported
to 8x) i *STILL* think we need to revert all of these changes, and not move
forward with any patch (or existing changes to allow SSL testing on java11)
until the jenkins boxes are running 11.0.3.
> Skip running tests with SSL on Java 11 to 11.0.2
>
atch matched to your idea?
> Skip running tests with SSL on Java 11 to 11.0.2
>
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
>
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Attachment: SOLR-12988.patch
> Skip running tests with SSL on Java 11 to 11.
y. THEN we can continue doing what we should
do after discussion.
Thirdly, I quite understand your idea now, so we should call {{assumFalse()}}
in {{SSLTestConfig}} whenever SSL is enabled on Java 11 -> 11.0.2. Luckily that
it still matches with issue's name and we do not need to change issue
on your
JVM because it's broken even though that's not what would happen if you tried
to actually run solr on ths broken JVM" is the absolute worst possible thing we
can do.
> Skip running tests with SSL on Java 11 to 11.0.2
>
mmit 64e3cc1789bfd69c2f11caeec6c2c268239f409e in lucene-solr's branch
refs/heads/branch_8x from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=64e3cc1 ]
SOLR-12988: Skip running tests with SSL on Java 11 to 11.0.2
> Skip running tests with SSL on Java
mmit 91944a468e6bf68bb46f1dad986533c9728c0690 in lucene-solr's branch
refs/heads/master from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=91944a4 ]
SOLR-12988: Skip running tests with SSL on Java 11 to 11.0.2
> Skip running tests with SSL on Java
.
It caused some test failures below, therefore we should skip running tests with
SSL on Java 11 to 11.0.2.
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of the
time when run with java11 (or java12), regardless of seed, on both master & 7x.
The nature of the proble
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12988:
Summary: Skip running tests with SSL on Java 11 to 11.0.2 (was: Avoid
using TLSv1.3 for
.i'm not sure why the {{\-build-raw-pdf}} target doesn't generate the same
warnings, but i don't think there is much we can do about it until there is a
jruby fix
> Ref Guide PDF build throws Java warnings after requi
, it just makes
the variance on short running tests less evident, but the average is identical.
> Improve ByteBufferGuard in Java 11
> --
>
> Key: LUCENE-8780
> URL: https://issues.apache.org/jira/browse/LUCENE-8780
>
care about.
> Improve ByteBufferGuard in Java 11
> --
>
> Key: LUCENE-8780
> URL: https://issues.apache.org/jira/browse/LUCENE-8780
> Project: Lucene - Core
> Issue Type: Improvement
>
nt code most cases where you open an index, start
a query and then close the reader. This only works shortly after program
started and everything is not yet optimized. As soon as there were multiple
queries already running and you close the JVM lat
nd you close the JVM later, it SIGSEGV almost always.
Not even "opaque" semantics help here.
- With the current code we can go a bit further, but we have some slowdown, but
it's still not save.
> Improve ByteBufferGuard in Java 11
> --
>
t always.
Not even "opaque" semantics help here.
- With the current code we can go a bit further, but we have some slowdown, but
it's still not save.
> Improve ByteBufferGuard in Java 11
> --
>
> Key: LUCENE-8780
>
ad access to the boolean" --
when did that happen, do you have a reference openjdk Jira issue?
> Improve ByteBufferGuard in Java 11
> --
>
> Key: LUCENE-8780
> URL: https://issues.apache.org/jira/browse/LUCE
but I was curious so I ran a few tests, and one
thing I saw is that if you limit to a single searcher thread, you see only the
negative side of this distribution, or at least it becomes more negative.
> Improve ByteBufferGuard in Java 11
> --
>
>
ed. Not sure how to interpret this.
> Improve ByteBufferGuard in Java 11
> --
>
> Key: LUCENE-8780
> URL: https://issues.apache.org/jira/browse/LUCENE-8780
> Project: Lucene - Core
> Issue Type: Imp
9.78 (11.0%) 10.25 (18.2%)
4.8% ( -21% - 38%)
HighTermMonthSort 23.40 (26.5%) 27.11 (32.1%)
15.9% ( -33% - 101%)
{noformat}
The total runtime of each run did not change. Not sure how to interpret this.
&g
run did not change. Not sure how to interpret this.
> Improve ByteBufferGuard in Java 11
> --
>
> Key: LUCENE-8780
> URL: https://issues.apache.org/jira/browse/LUCENE-8780
> Project: Lucene - Co
uschindler opened a new pull request #658: LUCENE-8780: Improve ByteBufferGuard
with Java 11 VarHandles and new …
URL: https://github.com/apache/lucene-solr/pull/658
…memory model
This is an automated message from the Apache
sier review and perf testing (easy chackout of
branch from my github repo): https://github.com/apache/lucene-solr/pull/658
> Improve ByteBufferGuard in Java 11
> --
>
> Key: LUCENE-8780
> URL: https://issues.apache.org/jira
[
https://issues.apache.org/jira/browse/LUCENE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8780:
--
Labels: Java11 (was: )
> Improve ByteBufferGuard in Java
stop the caller from accessing the underlying ByteBuffer. This
worked most of the time, until the JVM optimized away the plain read access to
the boolean (you can easily see this after some runtime of our by-default
ignored testcase).
With master on Java 11, we can improve the whole thing. Using
[
https://issues.apache.org/jira/browse/LUCENE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8780:
--
Attachment: LUCENE-8780.patch
> Improve ByteBufferGuard in Java
stop the caller from accessing the underlying ByteBuffer. This
worked most of the time, until the JVM optimized away the plain read access to
the boolean (you can easily see this after some runtime of our by-default
ignored testcase).
With master on Java 11, we can improve the whole thing. Using
Improve ByteBufferGuard in Java 11
> --
>
> Key: LUCENE-8780
> URL: https://issues.apache.org/jira/browse/LUCENE-8780
> Project: Lucene - Core
> Issue Type: Improvement
> Compone
Uwe Schindler created LUCENE-8780:
-
Summary: Improve ByteBufferGuard in Java 11
Key: LUCENE-8780
URL: https://issues.apache.org/jira/browse/LUCENE-8780
Project: Lucene - Core
Issue Type
d of gone full circle!) or should we still keep
it as part of this?
> Building Solr (master) using Java 11 with Maven has some old plugins
>
>
> Key: SOLR-11579
> URL: https://iss
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-11579:
--
Attachment: (was: SOLR-11579_4)
> Building Solr (master) using Java 11 and Maven has s
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-11579:
--
Summary: Building Solr (master) using Java 11 with Maven has some old
plugins (was: Building
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-11579:
--
Attachment: SOLR-11579.patch
> Building Solr (master) using Java 11 and Maven has some iss
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-11579:
--
Attachment: (was: SOLR-11579_2)
> Building Solr (master) using Java 11 and Maven has s
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-11579:
--
Description:
I'm calling this minor as I don't believe we officially support Ja
ll
patch together for that.
> Building Solr (master) using Java 11 and Maven has some issues
> --
>
> Key: SOLR-11579
> URL: https://issues.apache.org/jira/browse/SOLR-11579
> Pro
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-11579:
--
Description:
I'm calling this minor as I don't believe we officially support Ja
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-11579:
--
Description:
I'm calling this minor as I don't believe we officially support Ja
[
https://issues.apache.org/jira/browse/SOLR-13424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-13424:
-
Summary: Ref Guide PDF build throws Java warnings after requiring Java 11
on master
e/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/bare-bones-html/
{code}
> Ref Guide PDF build throws Java errors after requiring Java 11 on master
>
>
>
Cassandra Targett created SOLR-13424:
Summary: Ref Guide PDF build throws Java errors after requiring
Java 11 on master
Key: SOLR-13424
URL: https://issues.apache.org/jira/browse/SOLR-13424
known.
Uwe
Am April 16, 2019 6:22:09 PM UTC schrieb Chris Hostetter
:
>
>: The master branch was updated to use Java 11 - all Jenkins Jobs are
>back online! Let's see if additional Jenkins failures occur.
>
>FYI: first oddity i noticed is coming from some groovy code that see
Hi again,
I was on my mobile only, so here is the "lengthy" explanation:
> FYI: first oddity i noticed is coming from some groovy code that seems
> to run as part of "common.test" ?
> -check-totals:
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective acces
: > - The HTML linter based on HTML Tidy was disabled until we found a
: > replacement (no HTML 5 support - Java 11 produces HTML5 Javadocs). So it
: > might happen that bad javadocs are not detected in master but after merge
: > to 8.x branch they might suddenly appear.
:
: Mayb
: The master branch was updated to use Java 11 - all Jenkins Jobs are back
online! Let's see if additional Jenkins failures occur.
FYI: first oddity i noticed is coming from some groovy code that seems
to run as part of "common.test" ?
$ git clean -fx && cd solr/core/
16, 2019, at 5:13 AM, Uwe Schindler wrote:
>
> Hi,
>
> The master branch was updated to use Java 11 - all Jenkins Jobs are back
> online! Let's see if additional Jenkins failures occur.
>
> Go ahead and update your local dev environment:
>
>> As discussed on
Hi,
The master branch was updated to use Java 11 - all Jenkins Jobs are back
online! Let's see if additional Jenkins failures occur.
Go ahead and update your local dev environment:
> As discussed on https://issues.apache.org/jira/browse/LUCENE-8738, we are
> planning to switch maste
Hi committers,
As discussed on https://issues.apache.org/jira/browse/LUCENE-8738, we are
planning to switch master branch to use Java 11 tomorrow. The Apache and
Policeman Jenkins servers are prepared to handle that change, but now it's your
turn:
- Install a JDK 11 (remark: no Oracle J
[
https://issues.apache.org/jira/browse/LUCENE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8763:
--
Labels: Java11 (was: )
> Update to OpenClover that works with Java
8763:
-
Commit 831e940e02305eef6d99799bc1ba52e62d7190f5 in lucene-solr's branch
refs/heads/jira/LUCENE-8738 from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=831e940 ]
LUCENE-8738, LUCENE-8763: Disable OpenClover until a release with Java 11
support is available
&g
Uwe Schindler created LUCENE-8763:
-
Summary: Update to OpenClover that works with Java 11
Key: LUCENE-8763
URL: https://issues.apache.org/jira/browse/LUCENE-8763
Project: Lucene - Core
Issue
[
https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Collins updated SOLR-11579:
--
Summary: Building Solr (master) using Java 11 and Maven has some issues
(was: Building Solr
;>> Hello,
>>>
>>> Now that Lucene/Solr 8.0 has shipped I'd like us to consider requiring
>>> Java 11 for 9.0, currently the master branch. We had 18 months between
>>> 7.0 and 8.0, so if we assume a similar interval between 8.0 and 9.0
>>
ey
>
>
> On Tue, Mar 19, 2019 at 2:23 PM Adrien Grand wrote:
>
>> Hello,
>>
>> Now that Lucene/Solr 8.0 has shipped I'd like us to consider requiring
>> Java 11 for 9.0, currently the master branch. We had 18 months between
>> 7.0 and 8.0, so if we assume a
1 - 100 of 121 matches
Mail list logo
