I agree with Adrien about assumptions on core and other modules ("core may
not depend on anything (either libraries or other modules) and modules may
not depend on other modules"). Now that we're at it we should probably
check modules that contain "exceptions" and check them on a case by case
basis and see whether we can drop unwanted dependencies without breaking
contracts or features.For the specific case of LUCENE-7838 the classification module currently consumes/uses Lucene APIs *and* implementations so I think it falls more into an exceptional case (e.g. it uses MLT for KNN classifier); but adding a dependency on sandbox is bad anyway (hence I'll drop it). Implementation related dependencies could be removed too, I'll look into them and see if the classification module can come back to a cleaner state. Regards, Tommaso Il giorno mar 30 mag 2017 alle ore 23:43 Robert Muir <rcm...@gmail.com> ha scritto: > On Tue, May 30, 2017 at 4:44 PM, Adrien Grand <jpou...@gmail.com> wrote: > > The dependency convention, as I understand it, is that core may not > depend > > on anything (either libraries or other modules) and modules may not > depend > > on other modules. Then obviously we have exceptions for practical > reasons, > > such as highlighting depending on the queries module, otherwise we could > > only highlight core queries. But we should keep treating them as > exceptions > > and discuss introducing new dependencies on a case-by-case basis? > > > > Going with your example, I think the exception is really an undesired > "practical reason" though. Its obviously an abstraction violation, > even if its hard to fix. Ideally the right abstractions (such as > abstract class Query) would have the correct stuff (such as > extractTerms) so that this dependency wasn't necessary... this > separation would ensure that custom queries can be highlighted too. I > realize its more complex than this, but I think its a good example. > > I think the analyzers is another good one to think about, its in a > better state than highlighting (for the most part, I am sure there are > bad exceptions here too!!!): the abstractions > (Tokenizer/TokenFilter/Analyzer) are in core. test-framework has stuff > like MockAnalyzer that, tests should really be using since its geared > at preventing bugs (versus concrete analyzers). So other modules dont > need to depend on lucene-analyzers-XYZ to work with the analysis > chain. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
