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 <tomoko.uchida.1...@gmail.com>: > 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 <tomoko.uchida.1...@gmail.com>: > >> 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) >>> >>
