Thanks Tomoko! The check could be implemented (crudely) by looking at java sourceSets, scanning which folders *.java files live in (packages) and then checking for conflicts at the top-level project?
The test framework needs to be package-split to see core internals? Dawid On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida <[email protected]> wrote: > > 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) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
