I closed LUCENE-9499, which means we now have no split packages in lucene (except for test-framework). Please keep in mind we still don't have any static analysis/validations to prevent someone from adding another package name conflicts between modules.
2020年11月5日(木) 19:38 Tomoko Uchida <[email protected]>: > Hi, > please review LUCENE-9600, this cleans up split packages in "misc" module > and makes some refactoring on classes in lucene/misc to keep lucene/core > unchanged. > > Tomoko > > > 2020年10月24日(土) 19:25 Tomoko Uchida <[email protected]>: > >> 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) >>>>>> >>>>>
