[
https://issues.apache.org/jira/browse/SOLR-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831061#comment-13831061
]
Steve Rowe commented on SOLR-5378:
----------------------------------
The failures yesterday of the Maven Jenkins build on trunk
([https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1033/]) and branch_4x
([https://builds.apache.org/job/Lucene-Solr-Maven-4.x/514/]) are caused by
missing license files for newly introduced indirect compile-time Solr
dependencies on the expression modules' dependencies in
{{lucene/expressions/lib/\*}}: {{antlr-runtime-3.5.jar}}, {{asm-4.1.jar}}, and
{{asm-commons-4.1.jar}}.
Here's where the indirect deps were introduced on trunk:
[https://svn.apache.org/viewvc/lucene/dev/trunk/solr/common-build.xml?r1=1544793&r2=1544792&pathrev=1544793&diff_format=f#l78].
Here's the failure message from the Jenkins Maven trunk build log:
{noformat}
[licenses] MISSING sha1 checksum file for:
/home/hudson/.m2/repository/org/antlr/antlr-runtime/3.5/antlr-runtime-3.5.jar
[licenses] EXPECTED sha1 checksum file :
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/solr/licenses/antlr-runtime-3.5.jar.sha1
[licenses] MISSING sha1 checksum file for:
/home/hudson/.m2/repository/org/ow2/asm/asm-commons/4.1/asm-commons-4.1.jar
[licenses] EXPECTED sha1 checksum file :
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/solr/licenses/asm-commons-4.1.jar.sha1
[licenses] MISSING sha1 checksum file for:
/home/hudson/.m2/repository/org/ow2/asm/asm/4.1/asm-4.1.jar
[licenses] EXPECTED sha1 checksum file :
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/solr/licenses/asm-4.1.jar.sha1
[licenses] Scanned 46 JAR file(s) for licenses (in 0.55s.), 3 error(s).
{noformat}
The Maven build problem is the assumption that compile-time dependencies in the
Ant build will be Maven runtime dependencies. When I run {{ant
prepare-release-no-sign}} under {{solr/}}, though, only
{{lucene-expressions-<version>.jar}} is included in the distribution - none of
its dependencies are.
So, assuming that usage of the expressions module requires inclusion of its
dependencies, I think there are three problems here:
# The expression module dependencies should be included in the Solr distribution
# The expression module dependencies' license, notice and checksum files should
be included under {{solr/licenses/}}
# The {{check-licenses}} task under {{solr/}}, as currently written, assumes
that all dependencies are located under {{solr/}}, so using {{lib/}}
directories' contents under {{lucene/}} from the {{solr/}} build blocks this
check from functioning properly. I think these indirect dependencies should be
made direct via inclusion in an {{ivy.xml}} file under {{solr/}}, not sure
which one is appropriate.
> Suggester Version 2
> -------------------
>
> Key: SOLR-5378
> URL: https://issues.apache.org/jira/browse/SOLR-5378
> Project: Solr
> Issue Type: New Feature
> Components: search
> Reporter: Areek Zillur
> Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch,
> SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch,
> SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch,
> SOLR-5378.patch, SOLR-5378.patch
>
>
> The idea is to add a new Suggester Component that will eventually replace the
> Suggester support through the SpellCheck Component.
> This will enable Solr to fully utilize the Lucene suggester module (along
> with supporting most of the existing features) in the following ways:
> - Dictionary pluggability (give users the option to choose the dictionary
> implementation to use for their suggesters to consume)
> - Map the suggester options/ suggester result format (e.g. support for
> payload)
> - The new Component will also allow us to have "beefier" Lookup support
> instead of resorting to collation and such. (Move computation from query time
> to index time) with more freedom
> In addition to this, this suggester version should also have support for
> distributed support, which was awkward at best with the previous
> implementation due to SpellCheck requirements.
> Config (index time) options:
> - name - name of suggester
> - sourceLocation - external file location (for file-based suggesters)
> - lookupImpl - type of lookup to use [default JaspellLookupFactory]
> - dictionaryImpl - type of dictionary to use (lookup input) [default
> (sourceLocation == null ? HighFrequencyDictionaryFactory :
> FileDictionaryFactory)]
> - storeDir - location to store in-memory data structure in disk
> - buildOnCommit - command to build suggester for every commit
> - buildOnOptimize - command to build suggester for every optimize
> Query time options:
> - suggest.dictionary - name of suggester to use
> - suggest.count - number of suggestions to return
> - suggest.q - query to use for lookup
> - suggest.build - command to build the suggester
> - suggest.reload - command to reload the suggester
> Example query:
> {code}
> http://localhost:8983/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec
> {code}
> Distributed query:
> {code}
> http://localhost:7574/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec&shards=localhost:8983/solr,localhost:7574/solr&shards.qt=/suggest
> {code}
> Example Response:
> {code}
> <response>
> <lst name="responseHeader">
> <int name="status">0</int>
> <int name="QTime">28</int>
> </lst>
> <str name="command">build</str>
> <result name="response" numFound="0" start="0" maxScore="0.0"/>
> <lst name="suggest">
> <lst name="suggestions">
> <lst name="e">
> <int name="numFound">2</int>
> <lst name="suggestion">
> <str name="term">electronics and computer1</str>
> <long name="weight">2199</long>
> <str name="payload"/>
> </lst>
> <lst name="suggestion">
> <str name="term">electronics</str>
> <long name="weight">649</long>
> <str name="payload"/>
> </lst>
> </lst>
> </lst>
> </lst>
> </response>
> {code}
> Example config file:
> - Using DocumentDictionary and FuzzySuggester
> -- Suggestion on product_name sorted by popularity with the additional
> product_id in the payload
> {code}
> <searchComponent class="solr.SuggestComponent" name="suggest">
> <lst name="suggester">
> <str name="name">suggest_fuzzy_doc_dict</str>
> <str name="lookupImpl">FuzzyLookupFactory</str>
> <str name="dictionaryImpl">DocumentDictionaryFactory</str>
> <str name="field">product_name</str>
> <str name="weightField">popularity</str>
> <str name="payloadField">product_id</str>
> <str name="storeDir">suggest_fuzzy_doc_dict_payload</str>
> <str name="suggestAnalyzerFieldType">text</str>
> </lst>
> </searchComponent>
> {code}
> - Using DocumentExpressionDictionary and FuzzySuggester
> -- Suggestion on product_name sorted by the expression "((price * 2) +
> ln(popularity))" (where both price and popularity are fields in the document)
> {code}
> <searchComponent class="solr.SuggestComponent" name="suggest">
> <lst name="suggester">
> <str name="name">suggest_fuzzy_doc_expr_dict</str>
> <str name="dictionaryImpl">DocumentExpressionDictionaryFactory</str>
> <str name="lookupImpl">FuzzyLookupFactory</str>
> <str name="field">product_name</str>
> <str name="weightExpression">((price * 2) + ln(popularity))</str>
> <str name="sortField">weight</str>
> <str name="sortField">price</str>
> <str name="strtoreDir">suggest_fuzzy_doc_expr_dict</str>
> <str name="suggestAnalyzerFieldType">text</str>
> </lst>
> </searchComponent>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
