[
https://issues.apache.org/jira/browse/LUCENE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17082538#comment-17082538
]
Uwe Schindler commented on LUCENE-9317:
---------------------------------------
bq. Did you try "ant eclipse"? While Gradle build is already in a good shape,
it is ongoing project for now. Still we use Ant build as our first class build
system and it will help you when you see Gradle tasks doesn't work for you.
Be warned a bit: The eclipse setup has a huge classpath with all JAR files in
main classpath. So it only helps using Eclipse to develop code, but you should
always run the tests command line, because it does not split modules, so you
want find any dependency problem. So Use eclipse to move stuff anround and let
Eclipse do auto-refactoring, but be sure to always compile and run tests with
Ant (or Gradle).
bq. My first roadblock to getting setup is understanding the cyclic
dependencies between core, codecs and the test-framework.
This should not be a problem now, but it may later be a problem when we
modularize Lucene. There are no cyclic dependencies for userland code (so maven
artifacts used by solr or other software does not have cyclic dependencies).
The bad guy is just lucene-test-framework, which won't be modularized (it can't
be as it uses split packages extensively - like all tests code - one common
problem with modularizing: test code often accesses package private stuff and
so needs to share same package structures). We just have to figure out how to
setup the tests once we added module-info.java, I think running tests should
always be classpath based! This may be a separate issue.
> 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
