[ 
https://issues.apache.org/jira/browse/LUCENE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087832#comment-17087832
 ] 

Uwe Schindler commented on LUCENE-9317:
---------------------------------------

Hi David,

on a first look, this is no too bad. I am still not sure if all stuff from the 
oal.utils package should be moved over to core.

The second thing that I already mentioned: The Factory base classes should be 
next to the TokenFilter, CharFilter, Tokenizer base classes. I know this would 
need to change all "extends" in all filters, but maybe we can for a while keep 
a fake subclass CharFilterFactory, TokenizerFactory classes in utils (just as 
some backwards compatibility layer).

Also the changes here are not commitable - not even to master:
- The META-INF/services files need to be refactored, too. Tests for loading 
from SPI need to be added to core, too.
- Also many classes are auto-generated, so the whole logic in Ant/Gradle's 
build files need to be moved. E.g, the code to generate UnicodeData.java (see 
the header of that file).

Uwe

P.S.: You sent me a private mail on the weekend, did you get my response? I 
just want to make sure that it was not lost in spam checks.

> Resolve package name conflicts for StandardAnalyzer to allow Java module 
> system support
> ---------------------------------------------------------------------------------------
>
>                 Key: LUCENE-9317
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9317
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/other
>    Affects Versions: master (9.0)
>            Reporter: David Ryan
>            Priority: Major
>              Labels: build, features
>
>  
> To allow Lucene to be modularised there are a few preparatory tasks to be 
> completed prior to this being possible.  The Java module system requires that 
> jars do not use the same package name in different jars.  The lucene-core and 
> lucene-analyzers-common both share the package 
> org.apache.lucene.analysis.standard.
> Possible resolutions to this issue are discussed by Uwe on the mailing list 
> here:
>  
> [http://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3CCAM21Rt8FHOq_JeUSELhsQJH0uN0eKBgduBQX4fQKxbs49TLqzA%40mail.gmail.com%3E]????
> {quote}About StandardAnalyzer: Unfortunately I aggressively complained a 
> while back when Mike McCandless wanted to move standard analyzer out of the 
> analysis package into core (“for convenience”). This was a bad step, and IMHO 
> we should revert that or completely rename the packages and everything. The 
> problem here is: As the analysis services are only part of lucene-analyzers, 
> we had to leave the factory classes there, but move the implementation 
> classes in core. The package has to be the same. The only way around that is 
> to move the analysis factory framework also to core (I would not be against 
> that). This would include all factory base classes and the service loading 
> stuff. Then we can move standard analyzer and some of the filters/tokenizers 
> including their factories to core an that problem would be solved.
> {quote}
> There are two options here, either move factory framework into core or revert 
> StandardAnalyzer back to lucene-analyzers.  In the email, the solution lands 
> on reverting back as per the task list:
> {quote}Add some preparatory issues to cleanup class hierarchy: Move Analysis 
> SPI to core / remove StandardAnalyzer and related classes out of core back to 
> anaysis
> {quote}
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to