I opened LUCENE-9499 as the umbrella. I set "Fix version" to 9.0 - means once we make a commit on it, this will be a blocker for release 9.0.0. (I don't think the changes should be delivered across two major releases; all changes have to be out at once in a major release.) If there are any objections or concerns, please leave comments. For now I have no idea about the total volume of changes or technical obstacles that have to be handled.
About Solr - do we really need to fix split packages? Solr is a server app, the benefits seem to be smaller than Lucene (a library) for me. I'd like to hear opinions/thoughts from others. Tomoko 2020年9月2日(水) 9:05 Gus Heck <gus.h...@gmail.com>: > +1 to fixing and +1 to doing it in a major release. > > On Tue, Sep 1, 2020 at 4:32 PM Adrien Grand <jpou...@gmail.com> wrote: > >> +1 Changing packages of many classes should be done in a major. >> >> On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida < >> tomoko.uchida.1...@gmail.com> wrote: >> >>> Just to make sure, could I confirm "when the changes will be out"... >>> Resolving split package issues should break backward compatibility >>> (changing package names and moving classes from one module to another >>> modules). So we have just two options, we can have these changes only on >>> major releases - 9.0.0 or 10.0.0; we cannot release such changes at minor >>> versions. Is that correct? >>> >>> Tomoko >>> >>> >>> 2020年9月1日(火) 22:08 Tomoko Uchida <tomoko.uchida.1...@gmail.com>: >>> >>>> > 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 >>>>> >>>>> >> >> -- >> Adrien >> > > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) >
