I think this sounds good! D. On Wed, Nov 25, 2020 at 2:20 PM Tomoko Uchida <[email protected]> wrote: > > > 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? > > I opened LUCENE-9604 some days ago, I've done nothing yet for it. > > Maybe we can add a precommit check to find split packages using Gradle APIs, > but - how about having module-info.java now instead of an ad-hoc temporary > solution (though I don't know if there is another issue to be considered)? > As a starter, we could open up (export) all existing packages... > > > 2020年11月12日(木) 0:51 Dawid Weiss <[email protected]>: >> >> 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] >>
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
