Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-7318

Graduate StandardAnalyzer out of analyzers module into core

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.2, 6.2.1, 7.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Spinoff from LUCENE-7314:

      StandardAnalyzer has progressed substantially since we broke out the analyzers module ... it now follows a real Unicode standard (UAX #29 Unicode Text Segmentation). It's also much faster than it used to be, since it switched to JFlex a while back. Many bug fixes, etc.

      I think it would make a good default for most Lucene users, and we should graduate it from the analyzers module into core, and make it the default for IndexWriter.

      It's really quite crazy that users must go digging in the analyzers module to get started with Lucene ... we don't make them dig through the codecs module to find a good default codec ...

      1. LUCENE-7318.patch
        1.34 MB
        Michael McCandless
      2. LUCENE-7318-backwards.patch
        38 kB
        Uwe Schindler
      3. LUCENE-7318-backwards.patch
        37 kB
        Uwe Schindler
      4. LUCENE-7318-backwards.patch
        35 kB
        Uwe Schindler
      5. LUCENE-7318-backwards.patch
        28 kB
        Uwe Schindler

        Issue Links

          Activity

          Hide
          rcmuir Robert Muir added a comment -

          +1

          Show
          rcmuir Robert Muir added a comment - +1
          Hide
          mikemccand Michael McCandless added a comment -

          Rote patch, moving StandardAnalyzer/Tokenizer, and the utility
          classes it uses, to core's oal.analysis module.

          I left ClassicAnalyzer and UAX29URLEmailTokenizer in the
          analysis module.

          "ant test" passes but precommit is still angry about some javadocs
          ... I'll iterate.

          The one non-rote change I did was to move the
          ENGLISH_STOP_WORDS_SET from StopAnalyzer (still in analyzers
          module) to StandardAnalyzer.

          I also added "jflex" target to core's build.xml, to regenerate the
          tokenizer.

          I left ClassicAnalyzer, and the factories, in the analysis/common
          module.

          Show
          mikemccand Michael McCandless added a comment - Rote patch, moving StandardAnalyzer/Tokenizer , and the utility classes it uses, to core's oal.analysis module. I left ClassicAnalyzer and UAX29URLEmailTokenizer in the analysis module. "ant test" passes but precommit is still angry about some javadocs ... I'll iterate. The one non-rote change I did was to move the ENGLISH_STOP_WORDS_SET from StopAnalyzer (still in analyzers module) to StandardAnalyzer . I also added "jflex" target to core's build.xml, to regenerate the tokenizer. I left ClassicAnalyzer , and the factories, in the analysis/common module.
          Hide
          steve_rowe Steve Rowe added a comment -

          Mike, you marked this as fixed in 6.2, but AFAICT you didn't commit to branch_6x?

          Show
          steve_rowe Steve Rowe added a comment - Mike, you marked this as fixed in 6.2, but AFAICT you didn't commit to branch_6x?
          Hide
          mikemccand Michael McCandless added a comment -

          Woops, thanks for catching Steve Rowe!

          Show
          mikemccand Michael McCandless added a comment - Woops, thanks for catching Steve Rowe !
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit ba922148307248893bf70d02b28efdec9882f348 in lucene-solr's branch refs/heads/branch_6x from Mike McCandless
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ba92214 ]

          LUCENE-7318: graduate StandardAnalyzer and make it the default for IndexWriterConfig

          Show
          jira-bot ASF subversion and git services added a comment - Commit ba922148307248893bf70d02b28efdec9882f348 in lucene-solr's branch refs/heads/branch_6x from Mike McCandless [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ba92214 ] LUCENE-7318 : graduate StandardAnalyzer and make it the default for IndexWriterConfig
          Hide
          mikemccand Michael McCandless added a comment -

          Bulk close resolved issues after 6.2.0 release.

          Show
          mikemccand Michael McCandless added a comment - Bulk close resolved issues after 6.2.0 release.
          Hide
          dsmiley David Smiley added a comment -

          After upgrading an app to 6.2, I noticed that CharArraySet has moved both to a different module and to a different different package. That happened in this issue. CharArraySet is not marked lucene.experimental/internal. I think the CHANGES.txt upgrade nodes could be modified, even though 6.2 is already released? Also... I think it was worth mentioning in the summary/dialog here.

          Show
          dsmiley David Smiley added a comment - After upgrading an app to 6.2, I noticed that CharArraySet has moved both to a different module and to a different different package. That happened in this issue. CharArraySet is not marked lucene.experimental/internal. I think the CHANGES.txt upgrade nodes could be modified, even though 6.2 is already released? Also... I think it was worth mentioning in the summary/dialog here.
          Hide
          thetaphi Uwe Schindler added a comment - - edited

          Same issue here: it also affects some of the most important tokenfilters like StopFilter, LowerCaseFilter and their superclasses. This is a really hard and unexpected change, because in a minor update we moved some of the most important classes to other packages.

          At least we should have kept a "deprecated" subclass at the old place. This caused lots of trouble for my clients There was also a question on java-user a minute ago.

          I'd suggest to add a 6.2.1 release with the classes moved back at their old package, or alternatively a deprecated subclass without additional functionality. This change breaks binary compatibility of any analysis plugin (and there are tons out there).

          Show
          thetaphi Uwe Schindler added a comment - - edited Same issue here: it also affects some of the most important tokenfilters like StopFilter, LowerCaseFilter and their superclasses. This is a really hard and unexpected change, because in a minor update we moved some of the most important classes to other packages. At least we should have kept a "deprecated" subclass at the old place. This caused lots of trouble for my clients There was also a question on java-user a minute ago. I'd suggest to add a 6.2.1 release with the classes moved back at their old package, or alternatively a deprecated subclass without additional functionality. This change breaks binary compatibility of any analysis plugin (and there are tons out there).
          Hide
          thetaphi Uwe Schindler added a comment -

          I reopen this for discussion and maybe a fix in next release (rename classes back to their original name).

          Show
          thetaphi Uwe Schindler added a comment - I reopen this for discussion and maybe a fix in next release (rename classes back to their original name).
          Hide
          markus17 Markus Jelsma added a comment -

          Yes, i get some cannot fine symbol messages too when compiling:

          • LowerCaseFilter
          • StopFilter
          • CharArraySet
          • StopwordAnalyzerBase
          • CharacterUtils
          • TokenStreamComponents
          • WordListLoader

          And probably more since compiling just stops after a few errors.

          Show
          markus17 Markus Jelsma added a comment - Yes, i get some cannot fine symbol messages too when compiling: LowerCaseFilter StopFilter CharArraySet StopwordAnalyzerBase CharacterUtils TokenStreamComponents WordListLoader And probably more since compiling just stops after a few errors.
          Hide
          markus17 Markus Jelsma added a comment -

          By the way, i'm actually fine with this change but now i just have no idea what's happening when upgrading, and this isn't mentioned as API change in CHANGES.txt. Also, this issue description also doesn't clearly state how to deal with this API change

          Show
          markus17 Markus Jelsma added a comment - By the way, i'm actually fine with this change but now i just have no idea what's happening when upgrading, and this isn't mentioned as API change in CHANGES.txt. Also, this issue description also doesn't clearly state how to deal with this API change
          Hide
          janhoy Jan Høydahl added a comment -

          There are changes to Solr classes also in this commit, and the need for Solr changes in a LUCENE issue should probably ring an alarm bell that there may be breaking API changes...
          +1 to adding back deprecated versions of the removed classes in 6.2.1 for 6.x

          Show
          janhoy Jan Høydahl added a comment - There are changes to Solr classes also in this commit, and the need for Solr changes in a LUCENE issue should probably ring an alarm bell that there may be breaking API changes... +1 to adding back deprecated versions of the removed classes in 6.2.1 for 6.x
          Hide
          mikemccand Michael McCandless added a comment -

          Sorry everyone, I am +1 to put back deprecated subclasses in the original package.

          Show
          mikemccand Michael McCandless added a comment - Sorry everyone, I am +1 to put back deprecated subclasses in the original package.
          Hide
          thetaphi Uwe Schindler added a comment - - edited

          I can look into this later this evening!

          If you want to do it: you need to remove the final modifier from the TokenFilter and add it to incrementToken() to make the assert happy. Then you can subclass. The alternative is to add a wrapper filter.

          Show
          thetaphi Uwe Schindler added a comment - - edited I can look into this later this evening! If you want to do it: you need to remove the final modifier from the TokenFilter and add it to incrementToken() to make the assert happy. Then you can subclass. The alternative is to add a wrapper filter.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          I think it would make a good default for most Lucene users, and we should graduate it from the analyzers module into core, and make it the default for IndexWriter.

          This "StandardAnalyzer" is specific to English, as it removes English stopwords.
          That seems to be an odd choice now for a few reasons:

          • It was argued in the past (rather vehemently) that Solr should not prefer english in it's default "text" field
          • AFAIK, removing stopwords is no longer considered best practice.

          Given that removal of english stopwords is the only thing that really makes this analyzer english-centric (and given the negative impact that can have on other languages), it seems like the stopword filter should be removed from StandardAnalyzer.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - I think it would make a good default for most Lucene users, and we should graduate it from the analyzers module into core, and make it the default for IndexWriter. This "StandardAnalyzer" is specific to English, as it removes English stopwords. That seems to be an odd choice now for a few reasons: It was argued in the past (rather vehemently) that Solr should not prefer english in it's default "text" field AFAIK, removing stopwords is no longer considered best practice. Given that removal of english stopwords is the only thing that really makes this analyzer english-centric (and given the negative impact that can have on other languages), it seems like the stopword filter should be removed from StandardAnalyzer.
          Hide
          thetaphi Uwe Schindler added a comment -

          Yonik: good idea. This would at least allow to move back StopFilter and all its super classes back from where they came from!

          Show
          thetaphi Uwe Schindler added a comment - Yonik: good idea. This would at least allow to move back StopFilter and all its super classes back from where they came from!
          Hide
          arafalov Alexandre Rafalovitch added a comment -

          For Filters specifically, they are now in a different package/module from their own Factories. That's kind of unusual as well.

          Show
          arafalov Alexandre Rafalovitch added a comment - For Filters specifically, they are now in a different package/module from their own Factories. That's kind of unusual as well.
          Hide
          thetaphi Uwe Schindler added a comment -

          As we plan to release 6.2.1 quite soon, I will for now add back the "deprecated" subclasses in the analyzers/common module. The decision if the StopFilter should stay in StandardAnalyzer and the whole base classes in core is a different decision and should be discussed in a separate issue.

          Show
          thetaphi Uwe Schindler added a comment - As we plan to release 6.2.1 quite soon, I will for now add back the "deprecated" subclasses in the analyzers/common module. The decision if the StopFilter should stay in StandardAnalyzer and the whole base classes in core is a different decision and should be discussed in a separate issue.
          Hide
          thetaphi Uwe Schindler added a comment -

          I opened LUCENE-7444 for a general discussion. I looked into the code. I only see the choice of first reverting everything in this issue and start from scratch in LUCENE-7444. Unfortunately this wouldn't solve the problem for analysis plugins shipped with Solr or Elasticsearch that are affected by classname changes of some of the most important analysis components used in almost any custom analysis plugin out there.

          Show
          thetaphi Uwe Schindler added a comment - I opened LUCENE-7444 for a general discussion. I looked into the code. I only see the choice of first reverting everything in this issue and start from scratch in LUCENE-7444 . Unfortunately this wouldn't solve the problem for analysis plugins shipped with Solr or Elasticsearch that are affected by classname changes of some of the most important analysis components used in almost any custom analysis plugin out there.
          Hide
          mikemccand Michael McCandless added a comment -

          Hmm, why not leave StopFilter, etc., in core, and put (deprecated) subclasses in the old package names?

          Show
          mikemccand Michael McCandless added a comment - Hmm, why not leave StopFilter , etc., in core, and put (deprecated) subclasses in the old package names?
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          Or deprecate what was done in this issue instead. Having just one or two analysis components separated out form all the others doesn't make a lot of sense.
          Example: LowerCaseFilter and UpperCaseFilter are now in different packages and different jars?!
          Steering people toward using StopFilter by default isn't necessarily a good idea either.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - Or deprecate what was done in this issue instead. Having just one or two analysis components separated out form all the others doesn't make a lot of sense. Example: LowerCaseFilter and UpperCaseFilter are now in different packages and different jars?! Steering people toward using StopFilter by default isn't necessarily a good idea either.
          Hide
          mikemccand Michael McCandless added a comment -

          Or deprecate what was done in this issue instead

          I don't think we should do that: StandardAnalyzer makes a great default, now, finally. It's based on a Unicode standard (UAX 29).

          Example: LowerCaseFilter and UpperCaseFilter are now in different packages and different jars?!

          But I think this reflects typical usage? UpperCaseFilter is rarely used.

          Steering people toward using StopFilter by default isn't necessarily a good idea either.

          Yes, there are difficult tradeoffs if you filter stop words or not, but for better or worse, many apps do in fact need to filter stop words, and I think it's important we make it easy for apps to use the default analyzer (StandardAnalyzer) with stop words, and we should not remove it from core.

          Show
          mikemccand Michael McCandless added a comment - Or deprecate what was done in this issue instead I don't think we should do that: StandardAnalyzer makes a great default, now, finally. It's based on a Unicode standard (UAX 29). Example: LowerCaseFilter and UpperCaseFilter are now in different packages and different jars?! But I think this reflects typical usage? UpperCaseFilter is rarely used. Steering people toward using StopFilter by default isn't necessarily a good idea either. Yes, there are difficult tradeoffs if you filter stop words or not, but for better or worse, many apps do in fact need to filter stop words, and I think it's important we make it easy for apps to use the default analyzer ( StandardAnalyzer ) with stop words, and we should not remove it from core.
          Hide
          thetaphi Uwe Schindler added a comment - - edited

          Hmm, why not leave StopFilter, etc., in core, and put (deprecated) subclasses in the old package names?

          I plan to do this for 6.x and 6.2.1, but I won't deprecate the duplicates for now. So I will just subclass in analyzers/common, although this is still a lot of code duplication (most classes only have ctors that need to be cloned). This would also make it consistent with the Factory classes. Those factory classes should use/instantiate the common variants.

          All other discussion should be placed in LUCENE-7444. Once this is discussed and finalized, we can decide in 6.3, which classes to deprecate (if we do this at all). My personal opinion is:

          • Move StandardTokenizer to core (no package name change, so no backwards layer needed)
          • Move no-op StandardFilter to core, too, but deprecate from beginning (no package name change, so no backwards layer needed)
          • Add all "original" classes back in analyzers/common by subclassing, but don't deprecate

          Later-on (LUCENE-7444):

          • Remove StopFilter. For first time users, the decision of Stop words or not should be simple and our recommendation: no stop words please for something thats called "Standard"
          • StopFilter and all its superclasses and utility classes move back into analysis/common. I'd also suggest this for LowercaseFilter and just clone it in core as a package-private class inside oal/analysis/standard.
          • The CharacterUtils can stay in core (its @lucene.internal anyways), but moved completely to utils package (I have no strong opinion there)

          People that want to have stopwords can always define their own Analyzer using CustomAnalyzer.

          Show
          thetaphi Uwe Schindler added a comment - - edited Hmm, why not leave StopFilter, etc., in core, and put (deprecated) subclasses in the old package names? I plan to do this for 6.x and 6.2.1, but I won't deprecate the duplicates for now. So I will just subclass in analyzers/common, although this is still a lot of code duplication (most classes only have ctors that need to be cloned). This would also make it consistent with the Factory classes. Those factory classes should use/instantiate the common variants. All other discussion should be placed in LUCENE-7444 . Once this is discussed and finalized, we can decide in 6.3, which classes to deprecate (if we do this at all). My personal opinion is: Move StandardTokenizer to core (no package name change, so no backwards layer needed) Move no-op StandardFilter to core, too, but deprecate from beginning (no package name change, so no backwards layer needed) Add all "original" classes back in analyzers/common by subclassing, but don't deprecate Later-on ( LUCENE-7444 ): Remove StopFilter. For first time users, the decision of Stop words or not should be simple and our recommendation: no stop words please for something thats called "Standard" StopFilter and all its superclasses and utility classes move back into analysis/common. I'd also suggest this for LowercaseFilter and just clone it in core as a package-private class inside oal/analysis/standard. The CharacterUtils can stay in core (its @lucene.internal anyways), but moved completely to utils package (I have no strong opinion there) People that want to have stopwords can always define their own Analyzer using CustomAnalyzer.
          Hide
          thetaphi Uwe Schindler added a comment -

          Example: LowerCaseFilter and UpperCaseFilter are now in different packages and different jars?!

          I agree thats not how it should look like. The package structure of Lucene 4 was so great and now we are back at Lucene 1.0! Sorry, no-go for me.

          Steering people toward using StopFilter by default isn't necessarily a good idea either.

          I fully agree. As said in previous comment. Somebody who want to use a StopFilter can do this very easy using CustomAnalyzer. And thats all part of analysis/common. No need to do this in core.

          People that have no idea about "stop words or not" should not need to deal with it. At least, do not provide English stop words by default for something that is advertised as language neutral.

          P.S.: Stop words are empty by default in ES, too! (https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-standard-analyzer.html)

          Show
          thetaphi Uwe Schindler added a comment - Example: LowerCaseFilter and UpperCaseFilter are now in different packages and different jars?! I agree thats not how it should look like. The package structure of Lucene 4 was so great and now we are back at Lucene 1.0! Sorry, no-go for me. Steering people toward using StopFilter by default isn't necessarily a good idea either. I fully agree. As said in previous comment. Somebody who want to use a StopFilter can do this very easy using CustomAnalyzer. And thats all part of analysis/common. No need to do this in core. People that have no idea about "stop words or not" should not need to deal with it. At least, do not provide English stop words by default for something that is advertised as language neutral. P.S.: Stop words are empty by default in ES, too! ( https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-standard-analyzer.html )
          Hide
          mikemccand Michael McCandless added a comment -

          +1 to subclass deprecated classes back in analyzers common with the original (6.1) package names for this issue for 6.2.1, and defer stop words discussion for LUCENE-7444. I'll reply to your stop words comments over there.

          The minor code dup is fine as long as the version in analyzers/common is deprecated (gone in 7.0).

          Show
          mikemccand Michael McCandless added a comment - +1 to subclass deprecated classes back in analyzers common with the original (6.1) package names for this issue for 6.2.1, and defer stop words discussion for LUCENE-7444 . I'll reply to your stop words comments over there. The minor code dup is fine as long as the version in analyzers/common is deprecated (gone in 7.0).
          Hide
          thetaphi Uwe Schindler added a comment - - edited

          Here is a patch, restoring the classes in the analysis/common module! I did not deprecate anything for now (for 6.2.1) and also not for branch_6x until LUCENE-7444 is solved.

          I did not clone CharacterUtils. WordlistLoader was cloned completely, because you cannot subclass static classes.

          The factories now create the analysis/common's variant, so they are consistent and the tests don't fail (with Mike's change, the factory tests for LowerCase and StopFilter did not even work at all!!!)

          Show
          thetaphi Uwe Schindler added a comment - - edited Here is a patch, restoring the classes in the analysis/common module! I did not deprecate anything for now (for 6.2.1) and also not for branch_6x until LUCENE-7444 is solved. I did not clone CharacterUtils. WordlistLoader was cloned completely, because you cannot subclass static classes. The factories now create the analysis/common's variant, so they are consistent and the tests don't fail (with Mike's change, the factory tests for LowerCase and StopFilter did not even work at all!!!)
          Hide
          mikemccand Michael McCandless added a comment -

          Thanks Uwe, I'll review the patch. But quickly on:

          with Mike's change, the factory tests for LowerCase and StopFilter did not even work at all!!!

          I'm confused, why are tests not failing here?

          Show
          mikemccand Michael McCandless added a comment - Thanks Uwe, I'll review the patch. But quickly on: with Mike's change, the factory tests for LowerCase and StopFilter did not even work at all!!! I'm confused, why are tests not failing here?
          Hide
          thetaphi Uwe Schindler added a comment - - edited

          Because the test did not check what it should! It checked that all tokenstream components have corresponding factories. As you moved them to core, the test no longer checked for factory existence, as it was not seeing the classes. Once I added it back in common, it complains because the packages of returned implementation classes mismatched. This is why the factory returns the subclass, which is also more consistent (oal.analysis.core.LowerCaseFilterFactory returns oal.analysis.core.LowerCaseFilter, not oal.analysis.LowerCaseFilter).

          I will post a new patch fixing 2 Solr tests soon. Running tests.

          Show
          thetaphi Uwe Schindler added a comment - - edited Because the test did not check what it should! It checked that all tokenstream components have corresponding factories. As you moved them to core, the test no longer checked for factory existence, as it was not seeing the classes. Once I added it back in common, it complains because the packages of returned implementation classes mismatched. This is why the factory returns the subclass, which is also more consistent (oal.analysis.core.LowerCaseFilterFactory returns oal.analysis.core.LowerCaseFilter, not oal.analysis.LowerCaseFilter). I will post a new patch fixing 2 Solr tests soon. Running tests.
          Hide
          thetaphi Uwe Schindler added a comment -

          Patch fixing Solr tests (it actually reverts them).

          Show
          thetaphi Uwe Schindler added a comment - Patch fixing Solr tests (it actually reverts them).
          Hide
          mikemccand Michael McCandless added a comment -

          Thanks Uwe Schindler, the patch looks good. I don't really like that the back compat classes are not deprecated, but I guess it's OK while we discuss LUCENE-7444.

          There's a missing w in this comment: // class from core, but LoerCaseFilterFactory creates one from this module.

          Show
          mikemccand Michael McCandless added a comment - Thanks Uwe Schindler , the patch looks good. I don't really like that the back compat classes are not deprecated, but I guess it's OK while we discuss LUCENE-7444 . There's a missing w in this comment: // class from core, but LoerCaseFilterFactory creates one from this module .
          Hide
          thetaphi Uwe Schindler added a comment - - edited

          My plan for 6.2.1 and 6.x is to deprecate all backwards classes except StopFilter and LowercaseFilter. Those are actually used by the factory classes and don't really hurt. It also makes the javadocs easier to understand.

          In master I'd like to just add the StopFilter and LowercaseFilter classes for consistency with the factory. The other (deprecated) ones will be left out in master. This is a good way to fix the package naming consistency problems and give users a good overview on all available filters when displaying the analysis/common javadocs.

          What do you think?

          Show
          thetaphi Uwe Schindler added a comment - - edited My plan for 6.2.1 and 6.x is to deprecate all backwards classes except StopFilter and LowercaseFilter. Those are actually used by the factory classes and don't really hurt. It also makes the javadocs easier to understand. In master I'd like to just add the StopFilter and LowercaseFilter classes for consistency with the factory. The other (deprecated) ones will be left out in master. This is a good way to fix the package naming consistency problems and give users a good overview on all available filters when displaying the analysis/common javadocs. What do you think?
          Hide
          mikemccand Michael McCandless added a comment -

          +1, thanks Uwe Schindler.

          Show
          mikemccand Michael McCandless added a comment - +1, thanks Uwe Schindler .
          Hide
          thetaphi Uwe Schindler added a comment -

          New patch with all classes deprecated, except StopFilter and LowercaseFilter that stay at their original location for better documentation and consistency with Filter factory. Documentation for this was added.

          I will commit this later to 6.x and 6.2 branch, and forward-port the 2 filters to master, so we also get good documentation in master.

          The remaining stuff can be discussed in the other issue, which is now unrelated.

          Show
          thetaphi Uwe Schindler added a comment - New patch with all classes deprecated, except StopFilter and LowercaseFilter that stay at their original location for better documentation and consistency with Filter factory. Documentation for this was added. I will commit this later to 6.x and 6.2 branch, and forward-port the 2 filters to master, so we also get good documentation in master. The remaining stuff can be discussed in the other issue, which is now unrelated.
          Hide
          thetaphi Uwe Schindler added a comment -

          I fixed the test comment locally, won't upload new patch!

          Show
          thetaphi Uwe Schindler added a comment - I fixed the test comment locally, won't upload new patch!
          Hide
          mikemccand Michael McCandless added a comment -

          +1, thanks Uwe Schindler.

          Show
          mikemccand Michael McCandless added a comment - +1, thanks Uwe Schindler .
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 89f03655e3822226097142b59126e75c89a946f4 in lucene-solr's branch refs/heads/branch_6x from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=89f0365 ]

          LUCENE-7318: Fix backwards compatibility issues around StandardAnalyzer and its components, introduced with Lucene 6.2.0. The moved classes were restored in their original packages: LowercaseFilter and StopFilter, as well as several utility classes

          Show
          jira-bot ASF subversion and git services added a comment - Commit 89f03655e3822226097142b59126e75c89a946f4 in lucene-solr's branch refs/heads/branch_6x from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=89f0365 ] LUCENE-7318 : Fix backwards compatibility issues around StandardAnalyzer and its components, introduced with Lucene 6.2.0. The moved classes were restored in their original packages: LowercaseFilter and StopFilter, as well as several utility classes
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 5b3e6deb2f19e917792c1b8f4909b9c28b2e7508 in lucene-solr's branch refs/heads/branch_6_2 from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5b3e6de ]

          LUCENE-7318: Fix backwards compatibility issues around StandardAnalyzer and its components, introduced with Lucene 6.2.0. The moved classes were restored in their original packages: LowercaseFilter and StopFilter, as well as several utility classes

          1. Conflicts:
          2. lucene/CHANGES.txt
          Show
          jira-bot ASF subversion and git services added a comment - Commit 5b3e6deb2f19e917792c1b8f4909b9c28b2e7508 in lucene-solr's branch refs/heads/branch_6_2 from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5b3e6de ] LUCENE-7318 : Fix backwards compatibility issues around StandardAnalyzer and its components, introduced with Lucene 6.2.0. The moved classes were restored in their original packages: LowercaseFilter and StopFilter, as well as several utility classes Conflicts: lucene/CHANGES.txt
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit b39fcc12023b978c2d93a9446596729ca0e0e464 in lucene-solr's branch refs/heads/master from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b39fcc1 ]

          LUCENE-7318: Forward port some changes (add StopFilter and LowercaseFilter at their original location)

          Show
          jira-bot ASF subversion and git services added a comment - Commit b39fcc12023b978c2d93a9446596729ca0e0e464 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b39fcc1 ] LUCENE-7318 : Forward port some changes (add StopFilter and LowercaseFilter at their original location)
          Hide
          thetaphi Uwe Schindler added a comment -

          Committed patch.

          Show
          thetaphi Uwe Schindler added a comment - Committed patch.
          Hide
          thetaphi Uwe Schindler added a comment -

          I committed to 6.x and 6.2 (including addition of deprecated classes). I also forward-ported the LowercaseFilter and StopFilter changes to master, so Javadocs of analysis/common module are consistent.

          Show
          thetaphi Uwe Schindler added a comment - I committed to 6.x and 6.2 (including addition of deprecated classes). I also forward-ported the LowercaseFilter and StopFilter changes to master, so Javadocs of analysis/common module are consistent.
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          Closing after 6.2.1 release

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - Closing after 6.2.1 release

            People

            • Assignee:
              mikemccand Michael McCandless
              Reporter:
              mikemccand Michael McCandless
            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development