> As I recall one issue was around where to put analysis packages? It's LUCENE-9317. I had worked on it before, you can see what changes will be needed for analyzers-common (and core).
2020年9月1日(火) 22:00 Michael Sokolov <msoko...@gmail.com>: > I'm in favor - there may be some difficult choices though. As I recall > one issue was around where to put analysis packages? I forget the > details, but there was some pretty strong feeling that you should have > a functioning system with core only. However some basic analysis tools > are required for that, while most of our analyzers and so on are in a > separate analysis module. Perhaps we will need to move some basic > analyzers out of com.amazon.lucene.analysis? Or the reverse - move all > the analysis code into the analysis module and acknowledge that it is > a fundamental dependency (more essential than core, really). > > On Tue, Sep 1, 2020 at 8:26 AM Tomoko Uchida > <tomoko.uchida.1...@gmail.com> wrote: > > > > yes, Jigsaw was on my mind too... > > > > > why not go ahead and try to clean it up right away? > > > > > So a strong +1 to clean this up! > > > > OK, maybe I should open two issues, one for Lucene and one for Solr, and > link existing wip issues to them. > > Once we start it, these will be blockers for 9.0.0 release I believe > (for now I have no idea about the volume of the changes or technical > obstacles). Are there any objections or comments? > > > > > > 2020年9月1日(火) 19:34 Uwe Schindler <u...@thetaphi.de>: > >> > >> Hi, > >> > >> The biggest issue is that split packages make migrating to the Java 9 > module system impossible. It's not allowed to have same package name (with > classes) in different JAR files. > >> > >> Some of those require to open up visibility of classes. Some split > packages issues were done because of package private access, which is very > bad between JAR files. This also affects the test framework, although this > is not such a big deal (I would exclude that for now), because you would > never run UNIT tests inside a module system, only integration tests. > >> > >> So a strong +1 to clean this up! > >> Uwe > >> > >> ----- > >> Uwe Schindler > >> Achterdiek 19, D-28357 Bremen > >> https://www.thetaphi.de > >> eMail: u...@thetaphi.de > >> > >> > -----Original Message----- > >> > From: Dawid Weiss <dawid.we...@gmail.com> > >> > Sent: Tuesday, September 1, 2020 9:22 AM > >> > To: Lucene Dev <dev@lucene.apache.org> > >> > Subject: Re: Approach towards solving split package issues? > >> > > >> > This is a big headache for many things. I wouldn't mind doing this > >> > even for 9x. This is a major release, why not go ahead and try to > >> > clean it up right away? > >> > > >> > Dawid > >> > > >> > On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida > >> > <tomoko.uchida.1...@gmail.com> wrote: > >> > > > >> > > Hello devs, > >> > > > >> > > we have lots of package name conflicts (shared package names) > between > >> > modules in the Lucene/Solr source tree. It is not only annoying for > devs/users > >> > but also indeed bad practice since Java 9 (according to my > understanding), and > >> > we already have some problems with Javadocs due to these splitted > packages > >> > as some of us would know. I'm curious about the issue from a while > ago. My > >> > questions are, Q1: How can we solve the issue in an organized way? > Q2: How > >> > many of us really have interests about that? > >> > > > >> > > To break down Q1, > >> > > - A JIRA for building a grand design and organizing sub tasks is > needed? We > >> > have a couple of issues (e.g. LUCENE-9317 and LUCENE-9319) about it > and I > >> > had been playing around them before; but I feel like an umbrella > ticket would > >> > be needed. > >> > > - When to start and what's the target version to be out? My feeling > is that > >> > after cutting branch_9x is the right moment to start and 10.0.0 is > suitable for > >> > the target, does this make sense? > >> > > - Are there any other tasks/concerns to be considered except for > just > >> > renaming packages? > >> > > > >> > > Regarding Q2, > >> > > I know some of us have deep knowledge and thoughts in this topic, > but for > >> > now I am not sure how many of you have the will to give help or take > time for > >> > that. > >> > > It can't be a one-man effort. The more people understand and can > contribute > >> > to the build, the more healthy it will be. (I borrowed this phrase > from Gradle > >> > build issue LUCENE-9077). > >> > > > >> > > I don't intend to rush into making a decision, my purpose here is > to collect > >> > information to see if I can handle it before opening a JIRA. > >> > > > >> > > Thanks, > >> > > Tomoko > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> > For additional commands, e-mail: dev-h...@lucene.apache.org > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
