[
https://issues.apache.org/jira/browse/LUCENE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088607#comment-17088607
]
David Ryan commented on LUCENE-9317:
------------------------------------
Hi [~uschindler]
I've just been looking at moving the factories from oal.analysis.util to
oal.analysis. As suggested I looked at creating some fake subclasses for the
factories in util. Like many things, this is actually more difficult than it
looks. The static methods in the factory are difficult to proxy back to the
moved factory. In particular look at the start of this test fake
TokenFilterFactory:
{code:java}
public abstract class TokenFilterFactory extends
org.apache.lucene.analysis.TokenFilterFactory {
// As this return a fake TokenFilterFactory we would need to wrap the real one
with a factory.
// To make this work ProxyTokenFilterFactory needs to proxy all methods through
to the real factory
public static TokenFilterFactory forName(String name, Map<String,String> args) {
return new
ProxyTokenFilterFactory(org.apache.lucene.analysis.TokenFilterFactory.forName(name,
args));
}
// As the Class returned by this should extend the fake TokenFilterFactory this
is near impossible to fake.
// There's no real point changing this to return a Class of the real
TokenFilterFactory, because if the user
// tries to instantiate and cast it there will be an error if the class only
extends the moved TokenFilterFactory.
public static Class<? extends TokenFilterFactory> lookupClass(String name) {
// Type mismatch: cannot convert from Class<capture#1-of ? extends
TokenFilterFactory> to
// Class<? extends TokenFilterFactory>
return org.apache.lucene.analysis.TokenFilterFactory.lookupClass(name);
}
// This method has the same erasure as the parent so can't use the same method
name.
// Name clash: The method findSPIName(Class<? extends TokenFilterFactory>) of
type TokenFilterFactory
// has the same erasure as findSPIName(Class<? extends TokenFilterFactory>) of
type TokenFilterFactory
// but does not hide it
public static String findSPIName(Class<? extends TokenFilterFactory>
serviceClass) {
return org.apache.lucene.analysis.TokenFilterFactory.findSPIName(serviceClass);
}
}
{code}
Based on the above, I'd say there are the following options:
# Don't create the fake factory classes and describe changes required to
upgrade. Requires static methods and extend class package changes.
# -Create a minimal fake factory without any static methods. Allows the user
to continue to extend, but requires any static methods to be updated.- I just
tried this and it won't work as once you move ResourceLoader and
ResourceLoaderAware these can't be faked by extending the interface. May as
well not create the fake factory classes.
# Move the whole util package and as suggested previously and leave names as
is.
# Something else?
I'll leave it at that for today and see if I think of something new tomorrow.
If you'd be happy with option 1 let me know and I'll prepare commits
demonstrating changes.
> 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
