> 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] > >
