You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Tomoko Uchida (Jira)" <ji...@apache.org> on 2020/05/11 18:22:00 UTC
[jira] [Comment Edited] (LUCENE-9317) Resolve package name
conflicts for StandardAnalyzer to allow Java module system support
[ https://issues.apache.org/jira/browse/LUCENE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104741#comment-17104741 ]
Tomoko Uchida edited comment on LUCENE-9317 at 5/11/20, 6:21 PM:
-----------------------------------------------------------------
Can we make the changes as small as possible - let me know if I'm wrong, but moving o.a.l.a.core/custom/util to "lucene-core" wouldn't be necessary for resolving package name conflicts (if it's really needed, we can open another issue for them) ?
I would propose below (hopefully baby) steps:
* Move only analysis factory base classes and their dependencies in "analyzers-common" o.a.l.a.util to "lucene-core" o.a.l.a.
* (Keep o.a.l.a.util under "analyzers-common".)
* Refactor all concrete analysis factories: just change import statements.
* Create fake factory base classes in o.a.l.a.util for backward compatibility.
* Move "o.a.l.a.standard.StandardTokenizerFactory" to "lucene-core".
* Split o.a.l.a.standard in "analyzers-common" to o.a.l.a.classic and o.a.l.a.email.
* Refactor all service provider files (META-INF/services/...).
* Move / Fix tests : some mock factory classes will be needed since we can't use concrete factories in "analyzers-common" for tests in "lucene-core".
* Fix Ant/Gradle scripts.
* Add MIGRATE/CHANGES entry.
I just tried that on my local branch today, it seems to work; although total volume of changes is rather large. Once the refactoring is done, there should be no package name conflicts.
* "o.a.l.a.util" and newly created "o.a.l.a.classic" and "o.a.l.a.email" only exist in "analyzers-common"
* "o.a.l.a.standard" only exists in "lucene-core"
* other packages are not touched.
What do you think ? [~oobles] are you still working on or interested in this ?
was (Author: tomoko uchida):
Can we make the changes as small as possible - let me know if I'm wrong, but moving o.a.l.a.core/custom/util to "lucene-core" wouldn't be necessary for resolving package name conflicts (if it's really needed, we can open another issue for them) ?
I would propose below (hopefully baby) steps:
* Move only analysis factory base classes and their dependencies in "analyzers-common" o.a.l.a.util to "lucene-core" o.a.l.a.
* (Keep o.a.l.a.util under "analyzers-common".)
* Refactor all concrete analysis factories: just change import statements.
* Create fake factory base classes in o.a.l.a.util for backward compatibility.
* Move "o.a.l.a.standard.StandardTokenizerFactory" to "lucene-core".
* Split o.a.l.a.standard in "analyzers-common" to o.a.l.a.classic and o.a.l.a.email.
* Refactor all service provider files (META-INF/services/...).
* Move / Fix tests : some mock factory classes will be needed since we can't use concrete factories in "analyzers-common" for tests in "lucene-core".
* Fix Ant/Gradle scripts and MIGRATE/CHANGES entry.
I just tried that on my local branch today, it seems to work; although total volume of changes is rather large. Once the refactoring is done, there should be no package name conflicts.
* "o.a.l.a.util" and newly created "o.a.l.a.classic" and "o.a.l.a.email" only exist in "analyzers-common"
* "o.a.l.a.standard" only exists in "lucene-core"
* other packages are not touched.
What do you think ? [~oobles] are you still working on or interested in this ?
> 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: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org