Hi, please review LUCENE-9319. This tries to resolve package name conflicts between "sandbox" and "core" modules. Looks like many eyeballs are needed for cleaning up our sandbox.
Tomoko 2020年10月18日(日) 0:36 Tomoko Uchida <[email protected]>: > Hi, > please review LUCENE-9318, this refactors backward-codecs module (packages > are renamed). > I'm going to merge it into the master after waiting a week or so if there > is no objection/feedback. > > Tomoko > > > 2020年9月3日(木) 22:35 Tomoko Uchida <[email protected]>: > >> I also opened SOLR-14826 as the placeholder. I'm not fully sure of its >> priority but at least Alexandre expressed an interest in fixing it for >> Solr, thanks. >> If there is someone who wants to take the ownership, please feel free to >> join. I will leave it there until LUCENE-9499 is done anyway. >> >> >> >> 2020年9月3日(木) 0:12 Tomoko Uchida <[email protected]>: >> >>> 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 <[email protected]>: >>> >>>> +1 to fixing and +1 to doing it in a major release. >>>> >>>> On Tue, Sep 1, 2020 at 4:32 PM Adrien Grand <[email protected]> wrote: >>>> >>>>> +1 Changing packages of many classes should be done in a major. >>>>> >>>>> On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida < >>>>> [email protected]> 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 <[email protected]>: >>>>>> >>>>>>> > 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 <[email protected]>: >>>>>>> >>>>>>>> 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 >>>>>>>> <[email protected]> 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 <[email protected]>: >>>>>>>> >> >>>>>>>> >> 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: [email protected] >>>>>>>> >> >>>>>>>> >> > -----Original Message----- >>>>>>>> >> > From: Dawid Weiss <[email protected]> >>>>>>>> >> > Sent: Tuesday, September 1, 2020 9:22 AM >>>>>>>> >> > To: Lucene Dev <[email protected]> >>>>>>>> >> > 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 >>>>>>>> >> > <[email protected]> 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: [email protected] >>>>>>>> >> > For additional commands, e-mail: [email protected] >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >> To unsubscribe, e-mail: [email protected] >>>>>>>> >> For additional commands, e-mail: [email protected] >>>>>>>> >> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>> >>>>> -- >>>>> Adrien >>>>> >>>> >>>> >>>> -- >>>> http://www.needhamsoftware.com (work) >>>> http://www.the111shift.com (play) >>>> >>>
