您可能还记得我的第一篇博客文章，其中描述了Lucene开发人员如何使用Lucene搜索应用程序查找我们的Jira问题来食用我们自己的狗食。

该应用程序已成为许多Lucene现代功能的强大展示，例如侧向钻取和动态范围刻面， 基于中缀匹配的新建议 ， 发布荧光笔 ，块联接查询，因此您可以跳转到与您的匹配的特定问题注释搜索，近实时索引和搜索等。每当新用户向我询问Lucene的功能时，我都会将他们指向该应用程序，以便他们可以自己查看。

最近，我取得了一些进一步的进展，因此我想进行更新。

简单的基于Netty的Lucene服务器的源代码现在可以在此subversion分支上使用 （有关详细信息，请参阅LUCENE-5376 ）。 我一直在逐步增加其他Lucene模块的覆盖范围，包括构面，建议程序，分析，queryparsers，突出显示，分组，联接和表达式。 当然还有正常的索引和搜索！ 还有许多工作要做（有很多未提交的内容），此处的目标不是构建功能丰富的搜索服务器，而是演示如何在服务器上下文中使用最少的“瘦服务器”附加源代码使用Lucene当前的模块。

另外，为了测试此基于Lucene的新服务器并完成“狗食”，我构建了一个简单的Jira搜索应用程序插件，以帮助我们在此处找到Jira问题。 该应用程序具有各种Python工具，可以使用Jira的REST API和作为Python WSGI应用程序运行的用户界面层提取和索引Jira问题，以将请求发送到服务器并将响应呈现回用户。 该Jira搜索应用程序的目标是使它易于指向任何Jira实例/项目，并能够对所有问题进行全面搜索。

我只是对生产站点进行了进一步的更改：

• 我将Jira搜索应用程序升级到当前服务器分支（以前它在我的私有fork上运行）。
• 我将所有分析组件都切换到了Lucene的分析工厂。 这些工厂使用Java的SPI（服务提供商接口），以便服务器可以访问类路径中的任何字符过滤器，令牌化器和令牌过滤器。 这在构建服务器时非常有帮助，因为这意味着您不需要任何特殊的代码即可处理Lucene如今提供的大量分析组件。 一切都简单地通过了工厂（工厂知道如何解析自己的论点）。
• 我已经添加了Tika项目，所以现在您也可以找到Tika问题。 添加起来非常简单，并且似乎可以正常工作！
• 我插入了WordDelimiterFilter以便拆分CamelCaseTokens。 例如，尝试搜索中缀并记下高亮。 正如Rober Muir提醒我的那样， WordDelimiterFilter会破坏偏移量，在某些情况下，偏移量会使突出显示混乱，因此我将尝试设置ICUTokenizer （我已经在使用它）来进行拆分。
• 在您进行文本搜索时，默认情况下，我切换到Lucene的新表达式模块来进行相关性+新近度排序，这很有用，因为大多数时候我们都在寻找最近接触的问题。 以前，我使用自定义FieldComparator来实现相同的功能，但是表达式更加紧凑和强大，可以删除该自定义FieldComparator 。
• 我切换到的建议近乎实时的建设，使用AnalyzingInfixSuggester 。 以前，我每隔五分钟就完全重建一次建议程序，所以这节省了很多CPU，因为现在我只是在问题出现时添加新的Jira问题并刷新建议程序。 这也意味着从添加索引到建议索引之间的延迟要短得多。 有关详细信息，请参见LUCENE-5477 。
• 我现在每天commit一次。 以前，我从不承诺，只是依靠近实时搜索。 这工作得很好，除非当我需要关闭服务器时（例如，推出新更改），它需要完全重新索引，这是非常快的，但是对于那些在搜索过程中偶然进行搜索的用户来说，体验很差。 现在，当我启动服务器时，它又回到了最后一次提交，然后近实时索引Swift赶上了自最后一次提交以来发生的任何已更改问题。
• 各种小问题，例如重命名Jira问题时的正确处理（Jira REST API很难发现这一点！）； 更好的生产推动自动化； 升级到引导 UI库的更新版本。

此Jira搜索应用程序仍需进行大量改进。 对于具有许多可能的向下钻取值的字段，我想使用一个简单的建议程序，以便用户可以快速向下钻取。 我想修复建议程序，以根据项目过滤建议。 例如，如果您深入研究了提卡问题，那么当您输入新搜索时，您应该只会看到建议的提卡问题。 为此，我们需要使AnalzyingInfixSuggester上下文感知 。 我还想为所有方面字段提供更紧凑的UI； 也许我需要在“更多”下隐藏不常用的构面字段...

翻译自: https://www.javacodegeeks.com/2014/03/using-lucenes-search-server-to-search-jira-issues.html