I'm not an expert on modules either - haven't had the need to use them. But then: it's part of the fun to discover new things. I don't see the reason why we shouldn't do it (on master).
Dawid On Sat, Nov 28, 2020 at 4:04 PM Tomoko Uchida <[email protected]> wrote: > > On second thought... > Adding module-info.java to all sub-modules seems to be a relatively simple > task (though it might involve laborious work), however, properly maintaining > them would not be so trivial I suspect. I'm not sure developers (including > me) are ready for the module system. Introducing it right now could put > another burden on us? > > I'm not an expert in this area. What do you think? > > Tomoko > > > 2020年11月26日(木) 19:48 Dawid Weiss <[email protected]>: >> >> 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] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
