+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)
