[
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: [email protected]
For additional commands, e-mail: [email protected]
