o check that it’s in-line)
>>
>>
>>
>> I don’t want Lucene work with automodules in Java 11, it should be fully
>> modularized.
>>
>>
>>
>> If you want to help and express interest: Please open an issue for the
>> preparatory work listing
is up as described above: Analysis issues with
> standardanalyzer, codecs pkg-private apis, sandbox.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
ate all META-INF/services/* to module-info.java (before doing this,
>>> figure out of the META-INF files must stays for non-module usage, or if
>>> Java is clever enough to also look into module descriptor to find
>>> services). We may need all services at both locations (for module or
&
utomodules in Java 11, it should be
>fully modularized.
>>
>>
>>
>> If you want to help and express interest: Please open an issue for
>the preparatory work listing the cases of same-package in different jar
>files. I would split this up as described above: Analysis is
terest: Please open an issue for the
> preparatory work listing the cases of same-package in different jar files. I
> would split this up as described above: Analysis issues with
> standardanalyzer, codecs pkg-private apis, sandbox.
>
>
>
> Uwe
>
>
>
> -
>
>
s with standardanalyzer,
codecs pkg-private apis, sandbox.
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
From: David Ryan
Sent: Saturday, April 11, 2020 9:30 AM
To: dev@lucene.apache.org
Subject: Re: Lucene 9.0 Java module
Thanks, I had probably missed some of what Uwe was saying in regards to the
limitation of what would be possible even if the suggested changes were
made. Given your points and the fact that it would take a while to have any
of the changes filter into a release version, I decided to develop a
patch-
: If the changes I proposed are still viewed as having too many downstream
: impacts, my fallback position will be to patch the jars. This involves
: using the gradle import system to get the jars from Maven, then using a
: patch script to manually unzip the jars, move the offending classes into
:
}
>> }
>> }
>> zip.close();
>> }
>> }
>> }
>>
>> public static void addFiles(List files, String directoryName) {
>> File directory = new F
em, but instead use the new features of Java 11 and to get rid
>> MR-JAR complications to make use of new intrinsics.
>>
>>
>>
>> Servers like Solr or Elasticsearch are shipped as an application, so the
>> module system does not bring any benefit.
>>
>>
>&g
stings formats, analyzers, see
> https://issues.apache.org/jira/browse/LUCENE-9281). The only way to make
> it work at runtime is to put all of Lucene into one module.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
>
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
From: David Ryan
Sent: Tuesday, March 24, 2020 8:05 AM
To: dev@lucene.apache.org
Subject: Lucene 9.0 Java module system support
Hi all,
I've been investigating the use of Lucene as
Hi all,
I've been investigating the use of Lucene as part of an application that
uses the Java Module System. Initially, I used Gradle to bring in
lucene-core, lucene-spatial and lucene-queries using version 8.5.0. This
works with the automated module naming. However, bringing in
lucene-queryparse
13 matches
Mail list logo
