+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
