I think it'd be fun to switch to the module system at some point. Perhaps offer dual release, initially (modules + JARs).
Dawid On Mon, Nov 30, 2020 at 10:37 AM Uwe Schindler <[email protected]> wrote: > > Hi, > > I wanted to just add: > We also need some testing of the artifacts! Our standard test environment > can't do testing of module system. This needs some "integration" tests: A > project using the JAR files on module path - no classpath. And here it must > be JAR files, the non-packaged class files won't work as far as I remember. > > When doing this, you will figure out that the SPI classes (codecs, analyzers) > won't work on module path. Because we do not only need to open the packages > in our modules, the contents on META-INF/servisices need to be added as > "native services" to the module info. Every module-info file must list all > class names that are services explicit. The META-INF/service files are not > read in module mode: > > See this blog post: > https://blog.frankel.ch/migrating-serviceloader-java-9-module-system/ > > I am not sure if JDEPS figures this out automatically! > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: [email protected] > > > -----Original Message----- > > From: Dawid Weiss <[email protected]> > > Sent: Saturday, November 28, 2020 9:52 PM > > To: Lucene Dev <[email protected]> > > Subject: Re: Approach towards solving split package issues? > > > > 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: dev- > > [email protected] > > >> >> >>>>>>>>>>> >> > For additional commands, e-mail: dev- > > [email protected] > > >> >> >>>>>>>>>>> >> > > >> >> >>>>>>>>>>> >> > > >> >> >>>>>>>>>>> >> --------------------------------------------------------------------- > > >> >> >>>>>>>>>>> >> To unsubscribe, e-mail: dev- > > [email protected] > > >> >> >>>>>>>>>>> >> For additional commands, e-mail: dev- > > [email protected] > > >> >> >>>>>>>>>>> >> > > >> >> >>>>>>>>>>> > > >> >> >>>>>>>>>>> --------------------------------------------------------------------- > > >> >> >>>>>>>>>>> To unsubscribe, e-mail: dev- > > [email protected] > > >> >> >>>>>>>>>>> For additional commands, e-mail: dev- > > [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] > > > --------------------------------------------------------------------- > 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]
