[
https://issues.apache.org/jira/browse/LUCENE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17084123#comment-17084123
]
David Ryan commented on LUCENE-9317:
------------------------------------
I did a new experiment. This is quite severe looking, however, it could make
sense.
[https://github.com/oobles/lucene-solr/commit/5e25a9a9f4af9641b2ca01565060d4cb244b9266]
The main changes are to move the following packages from common analysis to
core:
* org.apache.lucene.analysis.core
* org.apache.lucene.analysis.custom
* org.apache.lucene.analysis.standard (Just StandardTokenizerFactory)
* org.apache.lucene.analysis.util
This is based on the following comments from Uwe:
{quote}One reason why the factories should move to core is that once we did
this, one no longer need to depend on analyzers-common anymore. If he has a set
of factories and tokenizers/filters and otherwise only requires the default
ones, he can completely remove the huge common.jar file! Also public and
commonly used abstract base classes should not be part of an optional module!
{quote}
Potentially not all of the classes in those packages need to be moved and would
need someone with more knowledge than me to decide. Moving these to core has
the benefit of not needing to change any of their names and leaves
StandardAnalysis. No need for constructor changes either. The factory test
cases will need to be updated so they don't rely on all the classes in common
analysis. As the Tokenizers and TokenFilters are split over both jars, I tested
to ensure both were loaded in the common analysis test cases which of course
they were.
The next changes look severe, but I think have less flow on effects. I've
renamed org.apache.lucene.analysis to org.apache.lucene.common.analysis. This
has the benefit of now matching the jar name and future module name. It removes
any conflicts for packages. I moved classic from standard to classic package.
I moved the UAX29* classes from standard to email. Both of these could have
been left in oal.common.analysis.standard too.
There's a few test cases I would need to fix if you think this approach is
worth continuing, but I think generally makes a lot of sense. Most test cases
are passing and I added Ignore to a few that need updating.
Apologies that the commit is difficult to review. I staged the changes and
moves in one commit when I should have done it as moves then changes. Let me
know if you'd rather I redo it.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
