-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
Just to be clear, I'm not suggesting that you or the Solr project should
use the module system. I agree that it is not for every project, however,
more and more projects and libraries are moving slowly to using the module
system or making their libraries compatible. I'm not suggesting you add
While the module system sounds nice in theory, my experience is
unfortunately that it is quite difficult to use for any application with
many existing dependencies, 90% or more of projects don't use it and
therefore wind up in the default module. I've wasted many hours trying to
get it to work in
Hi Uwe,
As I mentioned in the original post, the main issue I've come across with
being able to support Java 11 modules is that Lucene doesn't cleanly
separate the use of package names across jar libraries which results in
errors like:
"The package org.apache.lucene.analysis.standard is
Hi,
this is a known problem since many year and there are no plans to change this
yet. The main reason for Java 11 support is not to introduce the module system,
but instead use the new features of Java 11 and to get rid MR-JAR complications
to make use of new intrinsics.
Servers like
12 matches
Mail list logo
