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
