-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 the cases of same-pa
bove: 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
>
>
>
> *From:* David R
TA-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
>>>
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 issues with
t: 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
>
>
>
> -
>
> Uwe
issues 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
: 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
gt;
>> public static void addFiles(List files, String directoryName) {
>> File directory = new File(directoryName);
>> for (File file : directory.listFiles()) {
>> if (file.isFile()) {
>> files.add(file);
>> }
;
>>
>> Servers like Solr or Elasticsearch are shipped as an application, so the
>> module system does not bring any benefit.
>>
>>
>>
>> Th general recommendation is to combine all required Lucene libraries
>> into a separate JAR file during the maven / gradl
ake
> it work at runtime is to put all of Lucene into one module.
>
>
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* David Ryan
>
-
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 a
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
13 matches
Mail list logo
