Re: Welcome Joel Bernstein
Welcome Joel! On Thu, Oct 3, 2013 at 1:24 PM, Grant Ingersoll wrote: > Hi, > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on > the project and we look forward to his continued contributions going > forward. > > Welcome aboard, Joel! > > -Grant > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Han Jiang Team of Search Engine and Web Mining, School of Electronic Engineering and Computer Science, Peking University, China
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13784869#comment-13784869 ] rashi gandhi commented on LUCENE-2899: -- Hi, I designed an analyzer using OpenNLP filters and indexed some data on it. My problem is:While searching, SOLR sometimes return result and sometimes not ( but documents are there). for example: if i search for Detail_Nvf:brett ,it returns a document and after sometime again if i fire the same query, it returns Zero document Iam not getting why SOLR results are unstable. Please help me on this. Thanks in Advance > Add OpenNLP Analysis capabilities as a module > - > > Key: LUCENE-2899 > URL: https://issues.apache.org/jira/browse/LUCENE-2899 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 5.0, 4.5 > > Attachments: LUCENE-2899-current.patch, LUCENE-2899.patch, > LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, > LUCENE-2899.patch, LUCENE-2899-RJN.patch, LUCENE-2899-x.patch, > LUCENE-2899-x.patch, LUCENE-2899-x.patch, OpenNLPFilter.java, > OpenNLPFilter.java, OpenNLPTokenizer.java, opennlp_trunk.patch > > > Now that OpenNLP is an ASF project and has a nice license, it would be nice > to have a submodule (under analysis) that exposed capabilities for it. Drew > Farris, Tom Morton and I have code that does: > * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it > would have to change slightly to buffer tokens) > * NamedEntity recognition as a TokenFilter > We are also planning a Tokenizer/TokenFilter that can put parts of speech as > either payloads (PartOfSpeechAttribute?) on a token or at the same position. > I'd propose it go under: > modules/analysis/opennlp -- 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
[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13784876#comment-13784876 ] Per Steffensen commented on SOLR-4470: -- We are currently upgrading our version of Solr to be 4.4.0 based instead of 4.0.0 based. Basically merging the changes between 4.0.0 and 4.4.0 into our version of Solr. We have a lot of changes, including my solution of SOLR-4470. After we finish the upgrade we will basically have "information" in out SVN about how a patch on top of 4.4.0 would look. It would be a little hard to extract because I have to filter all of our other changes from the patch, but it can be done. Maybe I will be able to convince my boss once again to spend time creating a patch fitting Apache Solr, even though he kinda lost interest in that, because patches (almost) never get into Apache Solr anyway. Will you be able to use a 4.4.0 based patch for anything? Regarding working in small steps: It is too hard for me as a non-committer. It will be too hard feeding in small patches, discussing forever to get it in, then the next patch. We create a new full features (fully working and covered by tests), because we want it, and offer it to Apache. It is not that I do not see that argument for small patches, it is just not prioritized at our side. > Support for basic http auth in internal solr requests > - > > Key: SOLR-4470 > URL: https://issues.apache.org/jira/browse/SOLR-4470 > Project: Solr > Issue Type: New Feature > Components: clients - java, multicore, replication (java), SolrCloud >Affects Versions: 4.0 >Reporter: Per Steffensen >Assignee: Jan Høydahl > Labels: authentication, https, solrclient, solrcloud, ssl > Fix For: 4.5, 5.0 > > Attachments: SOLR-4470_branch_4x_r1452629.patch, > SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, > SOLR-4470.patch, SOLR-4470.patch > > > We want to protect any HTTP-resource (url). We want to require credentials no > matter what kind of HTTP-request you make to a Solr-node. > It can faily easy be acheived as described on > http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes > also make "internal" request to other Solr-nodes, and for it to work > credentials need to be provided here also. > Ideally we would like to "forward" credentials from a particular request to > all the "internal" sub-requests it triggers. E.g. for search and update > request. > But there are also "internal" requests > * that only indirectly/asynchronously triggered from "outside" requests (e.g. > shard creation/deletion/etc based on calls to the "Collection API") > * that do not in any way have relation to an "outside" "super"-request (e.g. > replica synching stuff) > We would like to aim at a solution where "original" credentials are > "forwarded" when a request directly/synchronously trigger a subrequest, and > fallback to a configured "internal credentials" for the > asynchronous/non-rooted requests. > In our solution we would aim at only supporting basic http auth, but we would > like to make a "framework" around it, so that not to much refactoring is > needed if you later want to make support for other kinds of auth (e.g. digest) > We will work at a solution but create this JIRA issue early in order to get > input/comments from the community as early as possible. -- 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
[jira] [Updated] (LUCENE-5252) add NGramSynonymTokenizer
[ https://issues.apache.org/jira/browse/LUCENE-5252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated LUCENE-5252: --- Attachment: LUCENE-5252_4x.patch New patch that has tests. Because the original test was developed in RONDHUIT and it includes test codes for not only NGramSynonymTokenizer but also synonym dictionary, the attached tests may be redundant in terms of SynonymMap. > add NGramSynonymTokenizer > - > > Key: LUCENE-5252 > URL: https://issues.apache.org/jira/browse/LUCENE-5252 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Koji Sekiguchi >Priority: Minor > Attachments: LUCENE-5252_4x.patch, LUCENE-5252_4x.patch > > > I'd like to propose that we have another n-gram tokenizer which can process > synonyms. That is NGramSynonymTokenizer. Note that in this ticket, the gram > size is fixed, i.e. minGramSize = maxGramSize. > Today, I think we have the following problems when using SynonymFilter with > NGramTokenizer. > For purpose of illustration, we have a synonym setting "ABC, DEFG" w/ > expand=true and N = 2 (2-gram). > # There is no consensus (I think :-) how we assign offsets to generated > synonym tokens DE, EF and FG when expanding source token AB and BC. > # If the query pattern looks like XABC or ABCY, it cannot be matched even if > there is a document "…XABCY…" in index when autoGeneratePhraseQueries set to > true, because there is no "XA" or "CY" tokens in the index. > NGramSynonymTokenizer can solve these problems by providing the following > methods. > * NGramSynonymTokenizer reads synonym settings (synonyms.txt) and it doesn't > tokenize registered words. e.g. > ||source text||NGramTokenizer+SynonymFilter||NGramSynonymTokenizer|| > |ABC|AB/DE/BC/EF/FG|ABC/DEFG| > * The back and forth of the registered words, NGramSynonymTokenizer generates > *extra* tokens w/ posInc=0. e.g. > ||source text||NGramTokenizer+SynonymFilter||NGramSynonymTokenizer|| > |XYZABC123|XY/YZ/ZA/AB/DE/BC/EF/C1/FG/12/23|XY/YZ/Z/ABC/DEFG/1/12/23| > In the above sample, "Z" and "1" are the extra tokens. -- 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
Re: Welcome Joel Bernstein
Welcome, Joel! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Joel Bernstein
Congratulations and welcome Joel! On Thu, Oct 3, 2013 at 10:54 AM, Grant Ingersoll wrote: > Hi, > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on > the project and we look forward to his continued contributions going > forward. > > Welcome aboard, Joel! > > -Grant > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Regards, Shalin Shekhar Mangar.
RE: Welcome Joel Bernstein
Welcome Joel! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Grant Ingersoll [mailto:gsing...@apache.org] > Sent: Thursday, October 03, 2013 7:25 AM > To: dev@lucene.apache.org > Subject: Welcome Joel Bernstein > > Hi, > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on the > project and we look forward to his continued contributions going forward. > > Welcome aboard, Joel! > > -Grant > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5189) Numeric DocValues Updates
[ https://issues.apache.org/jira/browse/LUCENE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-5189: --- Attachment: LUCENE-5189-updates-order.patch As I continued to work on LUCENE-5248, I realized that the code in ReaderAndLiveDocs does not work well for documents without field (i.e. the segment has the field, but some docs don't, and they aren't updated). It falsely read their value from the existing ndv (reading 0L), which means that before the update, docsWithField(i) returned false and after the updated it returned true. I consider this a bug as well, and incorporated a fix and a test in this patch. > Numeric DocValues Updates > - > > Key: LUCENE-5189 > URL: https://issues.apache.org/jira/browse/LUCENE-5189 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index >Reporter: Shai Erera >Assignee: Shai Erera > Attachments: LUCENE-5189-4x.patch, LUCENE-5189.patch, > LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, > LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, > LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189_process_events.patch, > LUCENE-5189_process_events.patch, LUCENE-5189-updates-order.patch, > LUCENE-5189-updates-order.patch > > > In LUCENE-4258 we started to work on incremental field updates, however the > amount of changes are immense and hard to follow/consume. The reason is that > we targeted postings, stored fields, DV etc., all from the get go. > I'd like to start afresh here, with numeric-dv-field updates only. There are > a couple of reasons to that: > * NumericDV fields should be easier to update, if e.g. we write all the > values of all the documents in a segment for the updated field (similar to > how livedocs work, and previously norms). > * It's a fairly contained issue, attempting to handle just one data type to > update, yet requires many changes to core code which will also be useful for > updating other data types. > * It has value in and on itself, and we don't need to allow updating all the > data types in Lucene at once ... we can do that gradually. > I have some working patch already which I'll upload next, explaining the > changes. -- 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
Re: Welcome Joel Bernstein
Welcome Joel ! Tommaso 2013/10/3 Grant Ingersoll > Hi, > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on > the project and we look forward to his continued contributions going > forward. > > Welcome aboard, Joel! > > -Grant > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: [VOTE] Release Lucene/Solr 4.5.0 RC5
For your information, I'm having trouble uploading the Solr artifacts to dist.apache.org[1] so there might be some delay before I announce the release. I'll keep you informed. [1] https://issues.apache.org/jira/browse/INFRA-6827 -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5251) New Dictionary Implementation for Suggester consumption
[
https://issues.apache.org/jira/browse/LUCENE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13784977#comment-13784977
]
Michael McCandless commented on LUCENE-5251:
bq. The patch does not duplicate the files but shows two git commits on the new
files.
OK, got it. That's cool; it's nice to see the separate revisions
spelled out. I just wish "patch" or "svn patch" did the right thing
here...
Thank you for merging commits on the new patch :)
{quote}
I am aware of that problem and was thinking along the same lines, have ONLY
TermFreqPayloadIterator (maybe should be named something like EntryIterator? as
there will be no TermFreqIterator and co) and have it accepted for all the
suggester and let the suggester throw exceptions if it does not support
payload/weight. I would be happy to open up an issue and work on it!
{quote}
That would be awesome! I agree we should do this separately... for
this issue I think we just document that it works only with the
"newer" suggesters?
New patch looks great, thanks Areek! Some comments:
* For the "field", I think we should use .stringValue() not
.binaryValue()? Ie, an app would typically have stored a
StringField? (But for payloadField, I think it should be
.binaryValue()).
* If the payload field exists, but its .binaryValue() is null, I
think we should throw an IAE too?
* Maybe use RandomIndexWriter in the tests? (It's more evil.) The
only issue is, you should then also set a .newLogMergePolicy()
onto those IndexWriterConfigs, else eventually you'll get the
AlcoholicMergePolicy and the docIDs will be in a different order
than how you indexed and the test will [falsely] fail.
> New Dictionary Implementation for Suggester consumption
> ---
>
> Key: LUCENE-5251
> URL: https://issues.apache.org/jira/browse/LUCENE-5251
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/search
>Reporter: Areek Zillur
> Attachments: LUCENE-5251.patch, LUCENE-5251.patch
>
>
> With the vast array of new suggester, It would be nice to have a dictionary
> implementation that could feed the suggesters terms, weights and (optionally)
> payloads from the lucene index.
> The idea of this dictionary implementation is to grab stored documents from
> the index and use user-configured fields for terms, weights and payloads.
> use-case: If you have a document with three fields
>- product_id
>- product_name
>- product_popularity_score
> then using this implementation would enable you to have a suggester for
> product_name using the weight of product_popularity_score and return you the
> payload of product_id, with which you can do further processing on (example:
> construct a url etc).
--
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
Re: Welcome Joel Bernstein
Welcome Joel. Happy hacking, Mike McCandless http://blog.mikemccandless.com On Thu, Oct 3, 2013 at 1:24 AM, Grant Ingersoll wrote: > Hi, > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on the > project and we look forward to his continued contributions going forward. > > Welcome aboard, Joel! > > -Grant > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Joel Bernstein
Welcome, Joel! -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 3. okt. 2013 kl. 07:24 skrev Grant Ingersoll : > Hi, > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on the > project and we look forward to his continued contributions going forward. > > Welcome aboard, Joel! > > -Grant > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Joel Bernstein
Congrats Joel! -Yonik http://lucidworks.com On Thu, Oct 3, 2013 at 6:56 AM, Jan Høydahl wrote: > Welcome, Joel! > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 3. okt. 2013 kl. 07:24 skrev Grant Ingersoll : > >> Hi, >> >> The Lucene PMC is happy to welcome Joel Bernstein as a committer on the >> Lucene and Solr project. Joel has been working on a number of issues on the >> project and we look forward to his continued contributions going forward. >> >> Welcome aboard, Joel! >> >> -Grant >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5257:
---
Attachment: LUCENE-5257.patch
Patch implementing the idea as a custom Ant task: {{LibVersionCheckTask}}.
I had originally planned a scripted implementation, but I figured that could
fail for valid {{ivy-version.properties}} syntax, or valid {{ivy.xml}} syntax,
since a script would likely make assumptions about the format, so I went with
full parsing for both, though I had to write the Properties file parser, since
{{java.util.Properties}} doesn't provide file-order access to the parsed
contents.
The new task checks the {{/org/name}} keys in the centralized versions file for
lexical sort order and for duplicates, then verifies that the {{rev}}
attributes for all {{}}-s in all {{ivy.xml}} files in the current
directory ({{lucene/}} and {{solr/}}) and below are formatted in
{{$\{/org/name}}} format, where {{org}} matches the value of the "org"
attribute, and {{name}} matches the value of the "name" attribute.
I modeled it on (and stole a lot of it from) the custom {{LicenseCheckTask}}.
The patch includes a fix to the {{ivy-versions.properties}} file that the new
task found: there are currently duplicate property keys for two of the
httpcomponents jars.
Like {{LicenseCheckTask}}, I made it run with the {{validate}} target, so it'll
be included with {{ant precommit}}.
Run alone, it took less than a tenth of second in each of {{lucene/}} and
{{solr/}} on my machine.
I think it's ready to go.
> Lock down centralized versioning of ivy dependencies
>
>
> Key: LUCENE-5257
> URL: https://issues.apache.org/jira/browse/LUCENE-5257
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-5257.patch
>
>
> LUCENE-5249 introduced centralized versioning of 3rd party dependencies and
> converted all ivy.xml files across Lucene/Solr to use this scheme. But there
> is nothing preventing people from ignoring this setup and (intentionally or
> not) introducing non-centralized dependency versions.
> SOLR-3664 discusses the problem of out-of-sync 3rd party dependencies between
> Lucene/Solr modules. Centralized versioning makes synchronization problems
> less likely but not impossible.
> One fairly simple way to ensure that all modules use the same version of 3rd
> party deps would be to require that all deps in ivy.xml would have to use the
> {{rev="$\{/org/name}"}} syntax, via a validation script.
> The problem remains that there may eventually be a *requirement* to use
> different 3rd party libs in different modules. Any form of lockdown here
> should allow for this possibility. Hoss's suggestion from a conversation on
> #lucene IRC earlier today:
> {noformat}
>perhaps exceptions could be by naming convetion
> can you give an example?
>ie: variables must match either ${group}/${artifact} or they must
> match
> /VERSION_MISTMATCH_EXCEPTION/${group}/${artifact}
> nice idea
> no external config required
>right
> and it has to be real obvious when you are bucking convention
>or better yet: ${group}/${artifact}/VERSION_MISTMATCH_EXCEPTION
> ... and there is another check that the version file is in ascii
> order
> so you are garuntted that it has to be right there in the versions
> file
> one line after ${group}/${artifact}
> i like it
>no change someone updating ${group}/${artifact} won't notice it
> i suppose really it should be
> ${group}/${artifact}/VERSION_MISTMATCH_EXCEPTION/${reason}
> ... since you might have more then one exception per
> ${group}/${artifact}
> but now i'm just making things up w/o evn really understanding
> the conventions you've alreay put in place
> :)
>you get the idea
> yes
> {noformat}
--
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
[jira] [Commented] (LUCENE-5250) Provide API to open IR on a specific IndexCommit with ReaderManager
[
https://issues.apache.org/jira/browse/LUCENE-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785008#comment-13785008
]
Michael McCandless commented on LUCENE-5250:
I think the use case here is to restrict the ReaderManager to certain
commits, right?
So not only on initial open, but also on subsequent reopens, you want
to only allow certain IndexCommits to be reopened?
Maybe we could make a new class, e.g. FilteredReaderManager, which is
just like ReaderManager except it adds a protected {code}boolean
allowCommit(IndexCommit){code}
method, which a subclass would implement to filter the allowed IndexCommits.
refreshIfNeeded would then .listCommits in the index, move backwards
through that list checking for the first accepted one, and then reopen
to that one (if the current reader isn't already on that commit).
Though this is a fairly specialized use case, so maybe just subclassing
ReferenceManager directly (outside of Lucene) is the way to go ...
> Provide API to open IR on a specific IndexCommit with ReaderManager
> ---
>
> Key: LUCENE-5250
> URL: https://issues.apache.org/jira/browse/LUCENE-5250
> Project: Lucene - Core
> Issue Type: Wish
> Components: core/index
>Affects Versions: 4.4
>Reporter: Akos Kitta
>Priority: Trivial
>
> Currently it is not possible to create a ReaderManager instance on a given
> IndexCommit. Since the ReaderManager is final class, one has to extend
> ReferenceManager instead when IR has to be opened on a specified IndexCommit.
--
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
Re: Welcome Joel Bernstein
Welcome, Joel! I have to say, Joel is one of my all-time favorite people in the world. We are very fortunate to have him here. Erik On Oct 3, 2013, at 1:24 AM, Grant Ingersoll wrote: > Hi, > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on the > project and we look forward to his continued contributions going forward. > > Welcome aboard, Joel! > > -Grant > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785043#comment-13785043 ] Zack Zullick commented on LUCENE-2899: -- I have seen this behavior before (look up to previous comments, especially from user Em and his previous fix) and I am experiencing similar results with the latest patch uploaded (Jun-16-2013) on 4.4/branch_4x. In my case, the OpenNLP system is only working when indexing the first document then no longer working thereafter. It seems you are having a similar issue, with the exception that yours is happening on the query end rather than the indexing. I sent out an email to Lance to see if he has any advice for us. > Add OpenNLP Analysis capabilities as a module > - > > Key: LUCENE-2899 > URL: https://issues.apache.org/jira/browse/LUCENE-2899 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 5.0, 4.5 > > Attachments: LUCENE-2899-current.patch, LUCENE-2899.patch, > LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, > LUCENE-2899.patch, LUCENE-2899-RJN.patch, LUCENE-2899-x.patch, > LUCENE-2899-x.patch, LUCENE-2899-x.patch, OpenNLPFilter.java, > OpenNLPFilter.java, OpenNLPTokenizer.java, opennlp_trunk.patch > > > Now that OpenNLP is an ASF project and has a nice license, it would be nice > to have a submodule (under analysis) that exposed capabilities for it. Drew > Farris, Tom Morton and I have code that does: > * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it > would have to change slightly to buffer tokens) > * NamedEntity recognition as a TokenFilter > We are also planning a Tokenizer/TokenFilter that can put parts of speech as > either payloads (PartOfSpeechAttribute?) on a token or at the same position. > I'd propose it go under: > modules/analysis/opennlp -- 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
Re: Welcome Joel Bernstein
Thanks everyone for the warm welcome. I'm very excited and honored to join the Lucene / Solr committer team. I'm a software engineer living in downtown New York City. Lucene first caught my attention in 2001 while working for a scientific publisher that was evaluating search engines. Even in those early days Lucene was beating the commercial engines in our performance and relevance tests. I lobbied hard for Lucene, but in the end was overruled. So I snuck Lucene into my work whenever I could, often using it as a key/ value store. It's amazing now to see how far Lucene / Solr have come and I'm looking forward to contributing to the project. Aside from programming, I'm a science fiction fan and enjoy learning about eastern philosophy. I'm currently engaged to my girlfriend Lauren who lives with me in Battery Park City. Joel On Thu, Oct 3, 2013 at 8:30 AM, Erik Hatcher wrote: > Welcome, Joel! I have to say, Joel is one of my all-time favorite people > in the world. We are very fortunate to have him here. > > Erik > > On Oct 3, 2013, at 1:24 AM, Grant Ingersoll wrote: > > > Hi, > > > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on > the project and we look forward to his continued contributions going > forward. > > > > Welcome aboard, Joel! > > > > -Grant > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Joel Bernstein Professional Services LucidWorks
[jira] [Commented] (LUCENE-5189) Numeric DocValues Updates
[ https://issues.apache.org/jira/browse/LUCENE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785059#comment-13785059 ] ASF subversion and git services commented on LUCENE-5189: - Commit 1528837 from [~shaie] in branch 'dev/trunk' [ https://svn.apache.org/r1528837 ] LUCENE-5189: fix updates-order and docsWithField bugs > Numeric DocValues Updates > - > > Key: LUCENE-5189 > URL: https://issues.apache.org/jira/browse/LUCENE-5189 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index >Reporter: Shai Erera >Assignee: Shai Erera > Attachments: LUCENE-5189-4x.patch, LUCENE-5189.patch, > LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, > LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, > LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189_process_events.patch, > LUCENE-5189_process_events.patch, LUCENE-5189-updates-order.patch, > LUCENE-5189-updates-order.patch > > > In LUCENE-4258 we started to work on incremental field updates, however the > amount of changes are immense and hard to follow/consume. The reason is that > we targeted postings, stored fields, DV etc., all from the get go. > I'd like to start afresh here, with numeric-dv-field updates only. There are > a couple of reasons to that: > * NumericDV fields should be easier to update, if e.g. we write all the > values of all the documents in a segment for the updated field (similar to > how livedocs work, and previously norms). > * It's a fairly contained issue, attempting to handle just one data type to > update, yet requires many changes to core code which will also be useful for > updating other data types. > * It has value in and on itself, and we don't need to allow updating all the > data types in Lucene at once ... we can do that gradually. > I have some working patch already which I'll upload next, explaining the > changes. -- 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
Re: Welcome Joel Bernstein
On 10/2/2013 11:24 PM, Grant Ingersoll wrote: > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on the > project and we look forward to his continued contributions going forward. Welcome to the project! Best of luck to you! - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5299) Add splash page root context to example Jetty configuration
Erik Hatcher created SOLR-5299:
--
Summary: Add splash page root context to example Jetty
configuration
Key: SOLR-5299
URL: https://issues.apache.org/jira/browse/SOLR-5299
Project: Solr
Issue Type: Improvement
Reporter: Erik Hatcher
Priority: Minor
Fix For: 5.0, 4.6
Right now, when you "java -jar start.jar" Solr's example Jetty, going to
http://localhost:8983/ serves this error:
{code}
Error 404 - Not Found.
No context on this server matched or handled this request.
Contexts known to this server are:
/solr
{code}
We can do better by providing a nice Solr-centric splash page here.
--
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
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785216#comment-13785216 ] rashi gandhi commented on LUCENE-2899: -- Thanks Zack Waiting for a reply from Lance :) > Add OpenNLP Analysis capabilities as a module > - > > Key: LUCENE-2899 > URL: https://issues.apache.org/jira/browse/LUCENE-2899 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 5.0, 4.5 > > Attachments: LUCENE-2899-current.patch, LUCENE-2899.patch, > LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, > LUCENE-2899.patch, LUCENE-2899-RJN.patch, LUCENE-2899-x.patch, > LUCENE-2899-x.patch, LUCENE-2899-x.patch, OpenNLPFilter.java, > OpenNLPFilter.java, OpenNLPTokenizer.java, opennlp_trunk.patch > > > Now that OpenNLP is an ASF project and has a nice license, it would be nice > to have a submodule (under analysis) that exposed capabilities for it. Drew > Farris, Tom Morton and I have code that does: > * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it > would have to change slightly to buffer tokens) > * NamedEntity recognition as a TokenFilter > We are also planning a Tokenizer/TokenFilter that can put parts of speech as > either payloads (PartOfSpeechAttribute?) on a token or at the same position. > I'd propose it go under: > modules/analysis/opennlp -- 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
[jira] [Commented] (SOLR-5299) Add splash page root context to example Jetty configuration
[
https://issues.apache.org/jira/browse/SOLR-5299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785298#comment-13785298
]
Shawn Heisey commented on SOLR-5299:
+1 from me, especially if it can detect what context URL Solr is running on and
not hardcode to /solr. There are sometimes people that want to put Solr on the
root context. If there would be any manual steps required for that, the
documentation should explain how it's done.
> Add splash page root context to example Jetty configuration
> ---
>
> Key: SOLR-5299
> URL: https://issues.apache.org/jira/browse/SOLR-5299
> Project: Solr
> Issue Type: Improvement
>Reporter: Erik Hatcher
>Priority: Minor
> Fix For: 5.0, 4.6
>
>
> Right now, when you "java -jar start.jar" Solr's example Jetty, going to
> http://localhost:8983/ serves this error:
> {code}
> Error 404 - Not Found.
> No context on this server matched or handled this request.
> Contexts known to this server are:
> /solr
> {code}
> We can do better by providing a nice Solr-centric splash page here.
--
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
Re: Welcome Joel Bernstein
Welcome Joel! On 3 October 2013 15:45, Shawn Heisey wrote: > On 10/2/2013 11:24 PM, Grant Ingersoll wrote: > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on > the project and we look forward to his continued contributions going > forward. > > Welcome to the project! Best of luck to you! > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Met vriendelijke groet, Martijn van Groningen
Re: Welcome Joel Bernstein
Welcome Joel! On Thu, Oct 3, 2013 at 9:33 AM, Martijn v Groningen wrote: > Welcome Joel! > > > On 3 October 2013 15:45, Shawn Heisey wrote: >> >> On 10/2/2013 11:24 PM, Grant Ingersoll wrote: >> > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the >> > Lucene and Solr project. Joel has been working on a number of issues on >> > the >> > project and we look forward to his continued contributions going forward. >> >> Welcome to the project! Best of luck to you! >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > > -- > Met vriendelijke groet, > > Martijn van Groningen - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: RC1 Release apache-solr-ref-guide-4.5.pdf
: Date: Mon, 30 Sep 2013 10:25:08 -0700 (MST) : Subject: VOTE: RC1 Release apache-solr-ref-guide-4.5.pdf I count 4 +1 votes (3 binding) and no -1 votes, so the VOTE passes. Thanks to everyone who helped out with editing/reviewing the doc. --- A few notes about the next steps... 1) I'll move forward with publishing the RC to the distribution network, per the next step in the release process... https://cwiki.apache.org/confluence/display/solr/Internal+-+How+To+Publish+This+Documentation#Internal-HowToPublishThisDocumentation-PublishtoSvnSubPub%26Mirrors 2) i'll be traveling the next few days, so i've asked sarowe to fill in and handle a few of the post-publish actions for me once the mirrors are updated... https://cwiki.apache.org/confluence/display/solr/Internal+-+How+To+Publish+This+Documentation#Internal-HowToPublishThisDocumentation-UpdateLinks%26VersionNumbers - update version numbers in cwiki, and doc links on the website https://cwiki.apache.org/confluence/display/solr/Internal+-+How+To+Publish+This+Documentation#Internal-HowToPublishThisDocumentation-Announce - send announcement email (given the delays Adrien mentioned publishing the 4.5 code artifacts, it will probably make sense to hold off on the doc release announcement -- and possible just send a single release announcement, mentioning both solr 4.5 the ref guide 4.5 in the same email -- i'll leave that up to sarowe & jpountz) 3) once i'm back online next tues/wed I'll take care of the remaining "clean up" steps. I want to do these myself to help vet the process (and svn command) as it is still new (SOLR-5085) ... https://cwiki.apache.org/confluence/display/solr/Internal+-+How+To+Publish+This+Documentation#Internal-HowToPublishThisDocumentation-RemoveArchivedVersionsFromtheMirrors - archive the old versions off the mirrors https://cwiki.apache.org/confluence/display/solr/Internal+-+How+To+Publish+This+Documentation#Internal-HowToPublishThisDocumentation-RemoveResidualRCFiles%2FDirectories - clean up the old RCs : https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.5-RC1/ : : $ cat apache-solr-ref-guide-4.5.pdf.sha1 : 823859d10a794fc399afd12981c40b167c076b13 apache-solr-ref-guide-4.5.pdf -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.5.0 RC5
Adrien, I don't see any motion yet on INFRA-6827 - any progress yet? Infra seems perpetually backed up, but I think they think that release-blocking stuff takes higher priority, so we should be able to get them to act quickly, I hope. I'd be happy to nudge on #asfinfra if you think it would help. Steve On Oct 3, 2013, at 5:39 AM, Adrien Grand wrote: > For your information, I'm having trouble uploading the Solr artifacts > to dist.apache.org[1] so there might be some delay before I announce > the release. I'll keep you informed. > > [1] https://issues.apache.org/jira/browse/INFRA-6827 > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5264) New method on NamedList to return one or many config arguments as collection
[ https://issues.apache.org/jira/browse/SOLR-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785451#comment-13785451 ] ASF subversion and git services commented on SOLR-5264: --- Commit 1528976 from [~elyograg] in branch 'dev/trunk' [ https://svn.apache.org/r1528976 ] SOLR-5264: move getBooleanArg to NamedList#removeBooleanArg > New method on NamedList to return one or many config arguments as collection > > > Key: SOLR-5264 > URL: https://issues.apache.org/jira/browse/SOLR-5264 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 4.5 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Fix For: 5.0, 4.6 > > Attachments: SOLR-5264-boolean.patch, SOLR-5264.patch, > SOLR-5264.patch, SOLR-5264.patch, SOLR-5264.patch, SOLR-5264.patch > > > In the FieldMutatingUpdateProcessorFactory is a method called "oneOrMany" > that takes all of the entries in a NamedList and pulls them out into a > Collection. I'd like to use that in a custom update processor I'm building. > It seems as though this functionality would be right at home as part of > NamedList itself. Here's a patch that moves the method. -- 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
Re: Welcome Joel Bernstein
Welcome Joel! On Thursday, October 3, 2013 at 6:56 PM, Erick Erickson wrote: > Welcome Joel! > > On Thu, Oct 3, 2013 at 9:33 AM, Martijn v Groningen > mailto:martijn.v.gronin...@gmail.com)> wrote: > > Welcome Joel! > > > > > > On 3 October 2013 15:45, Shawn Heisey > (mailto:s...@elyograg.org)> wrote: > > > > > > On 10/2/2013 11:24 PM, Grant Ingersoll wrote: > > > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > > > > Lucene and Solr project. Joel has been working on a number of issues on > > > > the > > > > project and we look forward to his continued contributions going > > > > forward. > > > > > > > > > > > > > Welcome to the project! Best of luck to you! > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > (mailto:dev-unsubscr...@lucene.apache.org) > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > (mailto:dev-h...@lucene.apache.org) > > > > > > > > > > > > > -- > > Met vriendelijke groet, > > > > Martijn van Groningen > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > (mailto:dev-unsubscr...@lucene.apache.org) > For additional commands, e-mail: dev-h...@lucene.apache.org > (mailto:dev-h...@lucene.apache.org) > >
[jira] [Resolved] (SOLR-4511) Repeater doesn't return correct index version to slaves
[ https://issues.apache.org/jira/browse/SOLR-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe resolved SOLR-4511. -- Resolution: Fixed Fix Version/s: (was: 4.5) 4.2 > Repeater doesn't return correct index version to slaves > --- > > Key: SOLR-4511 > URL: https://issues.apache.org/jira/browse/SOLR-4511 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 4.1 >Reporter: Raúl Grande >Assignee: Mark Miller > Fix For: 5.0, 4.2 > > Attachments: o8uzad.jpg, SOLR-4511.patch > > > Related to SOLR-4471. I have a master-repeater-2slaves architecture. The > replication between master and repeater is working fine but slaves aren't > able to replicate because their master (repeater node) is returning an old > index version, but in admin UI the version that repeater have is correct. > When I do http://localhost:17045/solr/replication?command=indexversion > response is: 29037 when the version should be > 29042 > If I restart the repeater node this URL returns the correct index version, > but after a while it fails again. -- 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
Re: Welcome Joel Bernstein
Welcome, Joel! Alan Woodward www.flax.co.uk On 3 Oct 2013, at 06:24, Grant Ingersoll wrote: > Hi, > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on the > project and we look forward to his continued contributions going forward. > > Welcome aboard, Joel! > > -Grant > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
[jira] [Commented] (SOLR-5264) New method on NamedList to return one or many config arguments as collection
[ https://issues.apache.org/jira/browse/SOLR-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785578#comment-13785578 ] ASF subversion and git services commented on SOLR-5264: --- Commit 1529016 from [~elyograg] in branch 'dev/trunk' [ https://svn.apache.org/r1529016 ] SOLR-5264: Removing deprecated getBooleanArg from trunk. > New method on NamedList to return one or many config arguments as collection > > > Key: SOLR-5264 > URL: https://issues.apache.org/jira/browse/SOLR-5264 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 4.5 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Fix For: 5.0, 4.6 > > Attachments: SOLR-5264-boolean.patch, SOLR-5264.patch, > SOLR-5264.patch, SOLR-5264.patch, SOLR-5264.patch, SOLR-5264.patch > > > In the FieldMutatingUpdateProcessorFactory is a method called "oneOrMany" > that takes all of the entries in a NamedList and pulls them out into a > Collection. I'd like to use that in a custom update processor I'm building. > It seems as though this functionality would be right at home as part of > NamedList itself. Here's a patch that moves the method. -- 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
[jira] [Commented] (SOLR-5264) New method on NamedList to return one or many config arguments as collection
[ https://issues.apache.org/jira/browse/SOLR-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785586#comment-13785586 ] ASF subversion and git services commented on SOLR-5264: --- Commit 1529020 from [~elyograg] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1529020 ] SOLR-5264: merge trunk r1528976, move getBooleanArg to NamedList#removeBooleanArg > New method on NamedList to return one or many config arguments as collection > > > Key: SOLR-5264 > URL: https://issues.apache.org/jira/browse/SOLR-5264 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 4.5 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Fix For: 5.0, 4.6 > > Attachments: SOLR-5264-boolean.patch, SOLR-5264.patch, > SOLR-5264.patch, SOLR-5264.patch, SOLR-5264.patch, SOLR-5264.patch > > > In the FieldMutatingUpdateProcessorFactory is a method called "oneOrMany" > that takes all of the entries in a NamedList and pulls them out into a > Collection. I'd like to use that in a custom update processor I'm building. > It seems as though this functionality would be right at home as part of > NamedList itself. Here's a patch that moves the method. -- 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
[jira] [Resolved] (SOLR-5264) New method on NamedList to return one or many config arguments as collection
[ https://issues.apache.org/jira/browse/SOLR-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey resolved SOLR-5264. Resolution: Fixed Before each individual commit, tests and precommit passed. > New method on NamedList to return one or many config arguments as collection > > > Key: SOLR-5264 > URL: https://issues.apache.org/jira/browse/SOLR-5264 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 4.5 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Fix For: 5.0, 4.6 > > Attachments: SOLR-5264-boolean.patch, SOLR-5264.patch, > SOLR-5264.patch, SOLR-5264.patch, SOLR-5264.patch, SOLR-5264.patch > > > In the FieldMutatingUpdateProcessorFactory is a method called "oneOrMany" > that takes all of the entries in a NamedList and pulls them out into a > Collection. I'd like to use that in a custom update processor I'm building. > It seems as though this functionality would be right at home as part of > NamedList itself. Here's a patch that moves the method. -- 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
Re: [VOTE] Release Lucene/Solr 4.5.0 RC5
Gavin McDonald just closed INFRA-6827 as fixed, and on #asfinfra he told me that the per-file limit has been raised to 200MB. He also said that if we need it raised further, we should ask again. Steve On Oct 3, 2013, at 3:06 PM, Steve Rowe wrote: > Adrien, > > I don't see any motion yet on INFRA-6827 - any progress yet? Infra seems > perpetually backed up, but I think they think that release-blocking stuff > takes higher priority, so we should be able to get them to act quickly, I > hope. > > I'd be happy to nudge on #asfinfra if you think it would help. > > Steve > > On Oct 3, 2013, at 5:39 AM, Adrien Grand wrote: > >> For your information, I'm having trouble uploading the Solr artifacts >> to dist.apache.org[1] so there might be some delay before I announce >> the release. I'll keep you informed. >> >> [1] https://issues.apache.org/jira/browse/INFRA-6827 >> >> -- >> Adrien >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Joel Bernstein
Welcome Joel! Looking forward to your commit avalanche :) Otis, from a couch in Brooklyn Solr & ElasticSearch Support http://sematext.com/ On Oct 3, 2013 1:27 AM, "Grant Ingersoll" wrote: > Hi, > > The Lucene PMC is happy to welcome Joel Bernstein as a committer on the > Lucene and Solr project. Joel has been working on a number of issues on > the project and we look forward to his continued contributions going > forward. > > Welcome aboard, Joel! > > -Grant > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Welcome Joel Bernstein
Welcome to the team Joel! - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/Welcome-Joel-Bernstein-tp4093247p4093417.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5042) MoreLikeThis doesn't return a score when mlt.count is set to 10
[ https://issues.apache.org/jira/browse/SOLR-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785902#comment-13785902 ] Anshum Gupta commented on SOLR-5042: The mlt.count was being treated as the value for flags, tripping the EarlyTerminatingCollectorException depending on the value of mlt.count. > MoreLikeThis doesn't return a score when mlt.count is set to 10 > --- > > Key: SOLR-5042 > URL: https://issues.apache.org/jira/browse/SOLR-5042 > Project: Solr > Issue Type: Bug > Components: MoreLikeThis >Affects Versions: 4.3 >Reporter: Josh Curran >Priority: Minor > > The problem appears to be around the mlt.count with in the solrconfig.xml. > When this value is set to 10, the 10 values that have been identified as > 'most like this' are returned with the original query, however the 'score' > field is missing. > Changing the mlt.count to say 11 and issuing the same query then the 'score' > field is returned with the same query. This appears to be the workaround. 11 > was just an arbitrary value, 12 or 15 also work > The same problem was raised on stackoverflow > http://stackoverflow.com/questions/16513719/solr-more-like-this-dont-return-score-while-specify-mlt-count -- 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
[jira] [Updated] (SOLR-5042) MoreLikeThis doesn't return a score when mlt.count is set to 10
[ https://issues.apache.org/jira/browse/SOLR-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5042: --- Attachment: SOLR-5042.patch This fixes both EarlyTerminatingCollectorException and the score issue. > MoreLikeThis doesn't return a score when mlt.count is set to 10 > --- > > Key: SOLR-5042 > URL: https://issues.apache.org/jira/browse/SOLR-5042 > Project: Solr > Issue Type: Bug > Components: MoreLikeThis >Affects Versions: 4.3 >Reporter: Josh Curran >Priority: Minor > Attachments: SOLR-5042.patch > > > The problem appears to be around the mlt.count with in the solrconfig.xml. > When this value is set to 10, the 10 values that have been identified as > 'most like this' are returned with the original query, however the 'score' > field is missing. > Changing the mlt.count to say 11 and issuing the same query then the 'score' > field is returned with the same query. This appears to be the workaround. 11 > was just an arbitrary value, 12 or 15 also work > The same problem was raised on stackoverflow > http://stackoverflow.com/questions/16513719/solr-more-like-this-dont-return-score-while-specify-mlt-count -- 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
[jira] [Commented] (SOLR-5125) Distributed MoreLikeThis fails with NullPointerException, shard query gives EarlyTerminatingCollectorException
[ https://issues.apache.org/jira/browse/SOLR-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785906#comment-13785906 ] Anshum Gupta commented on SOLR-5125: I've just put up a patch for SOLR-5042 that should fix this issue. mlt.count was basically being used up as the flag value and SolrIndexSearcher.TERMINATE_EARLY = 0x04 perhaps explains why a value of 10 screwed up score, 100 screwed up with EarlyTerminatingCollectorException. > Distributed MoreLikeThis fails with NullPointerException, shard query gives > EarlyTerminatingCollectorException > -- > > Key: SOLR-5125 > URL: https://issues.apache.org/jira/browse/SOLR-5125 > Project: Solr > Issue Type: Bug > Components: MoreLikeThis >Affects Versions: 4.4 >Reporter: Shawn Heisey > Fix For: 4.5, 5.0 > > Attachments: SOLR-5125.patch > > > A distributed MoreLikeThis query that works perfectly on 4.2.1 is failing on > 4.4.0. The original query returns a NullPointerException. The Solr log > shows that the shard queries are throwing EarlyTerminatingCollectorException. > Full details to follow in the comments. -- 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
[jira] [Created] (SOLR-5300) Split shards with custom hash ranges
Shalin Shekhar Mangar created SOLR-5300: --- Summary: Split shards with custom hash ranges Key: SOLR-5300 URL: https://issues.apache.org/jira/browse/SOLR-5300 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 5.0, 4.6 Currently, shards can only be split at the mid point of their hash range. This makes it difficult to control the distribution of data in the sub shards. We should make it possible to specify ranges to be used for splitting. A ranges parameter can be added which can accept hash ranges in decimal or hexadecimal e.g. ranges=0-0x1f4,0x1f5-0x3e8,0x3e9-0x5dc will split a shard with range 0-1500 into three shards with ranges [0,500], [501-1000] and [1001-1500] respectively. -- 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
[jira] [Updated] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5257:
---
Attachment: LUCENE-5257.patch
New patch with a few changes:
* Added orphan checking for {{/org/name}} coordinate keys in
{{ivy-versions.properties}} file that are not referred to in any {{ivy.xml}}
file.
* In order to add orphan checking, I had to make the task run only at the top
level, so that it sees all the {{ivy.xml}} files across the whole project. The
simplest way to do that with the current build was to place the
{{check-lib-versions}} target in {{lucene/build.xml}}, and then invoke it from
the top-level {{validate}} target, recursively checking the {{ivy.xml}} files
in the parent of the {{lucene/}} directory. (This is a little clunky - really
it should live at the top level - but I can live with it.)
* Cleaned up the {{ivy-versions.properties}} file, so that versions shared by
two or more libs are represented as a property named for their org/groupId (and
sometimes part of their name/artifactId if the org/groupId didn't seem to be
sufficiently differentiating).
I'll commit later today if there are no objections.
> Lock down centralized versioning of ivy dependencies
>
>
> Key: LUCENE-5257
> URL: https://issues.apache.org/jira/browse/LUCENE-5257
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-5257.patch, LUCENE-5257.patch
>
>
> LUCENE-5249 introduced centralized versioning of 3rd party dependencies and
> converted all ivy.xml files across Lucene/Solr to use this scheme. But there
> is nothing preventing people from ignoring this setup and (intentionally or
> not) introducing non-centralized dependency versions.
> SOLR-3664 discusses the problem of out-of-sync 3rd party dependencies between
> Lucene/Solr modules. Centralized versioning makes synchronization problems
> less likely but not impossible.
> One fairly simple way to ensure that all modules use the same version of 3rd
> party deps would be to require that all deps in ivy.xml would have to use the
> {{rev="$\{/org/name}"}} syntax, via a validation script.
> The problem remains that there may eventually be a *requirement* to use
> different 3rd party libs in different modules. Any form of lockdown here
> should allow for this possibility. Hoss's suggestion from a conversation on
> #lucene IRC earlier today:
> {noformat}
>perhaps exceptions could be by naming convetion
> can you give an example?
>ie: variables must match either ${group}/${artifact} or they must
> match
> /VERSION_MISTMATCH_EXCEPTION/${group}/${artifact}
> nice idea
> no external config required
>right
> and it has to be real obvious when you are bucking convention
>or better yet: ${group}/${artifact}/VERSION_MISTMATCH_EXCEPTION
> ... and there is another check that the version file is in ascii
> order
> so you are garuntted that it has to be right there in the versions
> file
> one line after ${group}/${artifact}
> i like it
>no change someone updating ${group}/${artifact} won't notice it
> i suppose really it should be
> ${group}/${artifact}/VERSION_MISTMATCH_EXCEPTION/${reason}
> ... since you might have more then one exception per
> ${group}/${artifact}
> but now i'm just making things up w/o evn really understanding
> the conventions you've alreay put in place
> :)
>you get the idea
> yes
> {noformat}
--
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
