[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Robert Muir (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241031#comment-13241031
 ] 

Robert Muir commented on LUCENE-3930:
-

{quote}
as far as the PermGen OOM goes, the -verbose logs show repeated instances of 
"Trying to override old definition of task antlib:org.apache.ivy.ant:..." 
suggesting that rmuir's unless="ivy.uptodate" isn't working the way we think it 
should (possibly because of the way the various build files are included in one 
another?)
{quote}

Thats right... I don't have a good solution here yet. 

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, ant_-verbose_clean_test.out.txt, patch-jetty-build.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-435) QParser must validate existence/absence of "q" parameter

[David Smiley (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240991#comment-13240991
 ] 

David Smiley commented on SOLR-435:
---

(This patch didn't break the build.)

Since this is a back-port, what do I do with the SOLR-2001 entry in the 
CHANGES.txt in trunk?  I suspect I should move the issue to the 3.6 section of 
the file, and commit that to the CHANGES.txt on both branches.

For reference:
{noformat}
* SOLR-2001: The query component will substitute an empty query that matches
  no documents if the query parser returns null.  This also prevents an
  exception from being thrown by the default parser if "q" is missing. (yonik)
  SOLR-435: if q is "" then it's also acceptable. (dsmiley, hoss)
{noformat}

> QParser must validate existence/absence of "q" parameter
> 
>
> Key: SOLR-435
> URL: https://issues.apache.org/jira/browse/SOLR-435
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 1.3
>Reporter: Ryan McKinley
>Assignee: David Smiley
> Fix For: 3.6, 4.0
>
> Attachments: 
> SOLR-2001_3x_backport_with_empty_string_check_and_test.patch, SOLR-435.patch, 
> SOLR-435_3x_consistent_errors.patch, SOLR-435_q_defaults_to_all-docs.patch
>
>
> Each QParser should check if "q" exists or not.  For some it will be required 
> others not.
> currently it throws a null pointer:
> {code}
> java.lang.NullPointerException
>   at org.apache.solr.common.util.StrUtils.splitSmart(StrUtils.java:36)
>   at 
> org.apache.solr.search.OldLuceneQParser.parse(LuceneQParserPlugin.java:104)
>   at org.apache.solr.search.QParser.getQuery(QParser.java:80)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:67)
>   at 
> org.apache.solr.handler.SearchHandler.handleRequestBody(SearchHandler.java:150)
> ...
> {code}
> see:
> http://www.nabble.com/query-parsing-error-to14124285.html#a14140108

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3930) nuke jars from source tree and use ivy

[Chris Male (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Male updated LUCENE-3930:
---

Attachment: patch-jetty-build.patch

Proof of concept patch to show how we can download jetty, patch it, build it 
and copy the jars of interest into lib.

I've made this against the 3930 branch but its targeting 3x of course.

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, ant_-verbose_clean_test.out.txt, patch-jetty-build.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

[David Smiley (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240963#comment-13240963
 ] 

David Smiley commented on SOLR-3161:


As an aside, this default request handler patch should probably have been 
another JIRA issue instead of this JIRA issue including several different 
things including clarifying the default config.

I stupidly committed the patch without testing and it broke the build because 
solr/core/src/test-files/solr/conf/solrconfig.xml (and possibly other test 
configs) has a  (with no default="true").  
Either the config(s) should be updated to be "/select" based (which I don't 
mind doing) or I could add back "standard" as eligible for default request 
handler nomination.  I committed the latter now because it's the safest.  
/select should takes precedence.  I also committed a warning message if there 
is none registered:
{code}
if(get("") == null)
  log.warn("no default request handler is registered (either '/select' or 
'standard')");
{code}

> Use of 'qt' should be restricted to searching and should not start with a '/'
> -
>
> Key: SOLR-3161
> URL: https://issues.apache.org/jira/browse/SOLR-3161
> Project: Solr
>  Issue Type: Improvement
>  Components: search, web gui
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 4.0
>
> Attachments: SOLR-3161-disable-qt-by-default.patch, 
> SOLR-3161-dispatching-request-handler.patch, 
> SOLR-3161-dispatching-request-handler.patch, 
> SOLR-3161_limit_qt=_to_refer_to_SearchHandlers,_and_shards_qt_likewise.patch,
>  SOLR-3161_make_the_slash-select_request_handler_the_default.patch
>
>
> I haven't yet looked at the code involved for suggestions here; I'm speaking 
> based on how I think things should work and not work, based on intuitiveness 
> and security. In general I feel it is best practice to use '/' leading 
> request handler names and not use "qt", but I don't hate it enough when used 
> in limited (search-only) circumstances to propose its demise. But if someone 
> proposes its deprecation that then I am +1 for that.
> Here is my proposal:
> Solr should error if the parameter "qt" is supplied with a leading '/'. 
> (trunk only)
> Solr should only honor "qt" if the target request handler extends 
> solr.SearchHandler.
> The new admin UI should only use 'qt' when it has to. For the query screen, 
> it could present a little pop-up menu of handlers to choose from, including 
> "/select?qt=mycustom" for handlers that aren't named with a leading '/'. This 
> choice should be positioned at the top.
> And before I forget, me or someone should investigate if there are any 
> similar security problems with the shards.qt parameter. Perhaps shards.qt can 
> abide by the same rules outlined above.
> Does anyone foresee any problems with this proposal?
> On a related subject, I think the notion of a default request handler is bad 
> - the default="true" thing. Honestly I'm not sure what it does, since I 
> noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. 
> Assuming it doesn't do anything useful anymore, I think it would be clearer 
> to use  instead of 
> what's there now. The delta is to put the leading '/' on this request handler 
> name, and remove the "default" attribute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3293) Request Handler inheritance

[David Smiley (Created) (JIRA)]

Request Handler inheritance
---

 Key: SOLR-3293
 URL: https://issues.apache.org/jira/browse/SOLR-3293
 Project: Solr
  Issue Type: New Feature
Reporter: David Smiley


It would be useful if one Solr request handler could inherit from another.  Or 
perhaps a mixin style so multiple could be merged in.  I've wanted to do this 
to reduce repeating myself in solrconfig.xml RH configurations.  Maybe all 
that's needed is one RH which provides the defaults to all the other search 
handlers.  This feature could also be useful for establishing some defaults 
like for "df" and "q.op" and "f.myfieldname.facet.method".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2724) Deprecate defaultSearchField and defaultOperator defined in schema.xml

[David Smiley (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240946#comment-13240946
 ] 

David Smiley commented on SOLR-2724:


I take issue with the Yonik's comment "we're not really gaining anything with 
this change".  I don't know about you, but I'm always pondering how Solr can 
work better and be easier to understand / configure.  I don't think 
defaultSearchField & defaultOperator have a need to exist, let alone exist in 
schema.xml, thereby creating unnecessary complexity in understanding the 
product -- albeit in a small way.  My work with Erik on simplifying the 
solrconfig.xml is along the same lines with my eventual hope to simply 
eliminate default="true" on a RH and the handleSelect thing.

I do agree that defaultSearchField is more useful than defaultOperator, but 
when it is depended on for some search or another (like the /browse fq=ipod 
example in SOLR-3292) , IMO it would been better/clearer for the query to be 
explicit.

> Deprecate defaultSearchField and defaultOperator defined in schema.xml
> --
>
> Key: SOLR-2724
> URL: https://issues.apache.org/jira/browse/SOLR-2724
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis, search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 3.6, 4.0
>
> Attachments: 
> SOLR-2724_deprecateDefaultSearchField_and_defaultOperator.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I've always been surprised to see the  element and 
>  defined in the schema.xml file since 
> the first time I saw them.  They just seem out of place to me since they are 
> more query parser related than schema related. But not only are they 
> misplaced, I feel they shouldn't exist. For query parsers, we already have a 
> "df" parameter that works just fine, and explicit field references. And the 
> default lucene query operator should stay at OR -- if a particular query 
> wants different behavior then use q.op or simply use "OR".
>  Seems like something better placed in solrconfig.xml than in the 
> schema. 
> In my opinion, defaultSearchField and defaultOperator configuration elements 
> should be deprecated in Solr 3.x and removed in Solr 4.  And  
> should move to solrconfig.xml. I am willing to do it, provided there is 
> consensus on it of course.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Hoss Man (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240943#comment-13240943
 ] 

Hoss Man commented on LUCENE-3930:
--

as far as the PermGen OOM goes, the -verbose logs show repeated instances of 
"Trying to override old definition of task antlib:org.apache.ivy.ant:..." 
suggesting that rmuir's {{unless="ivy.uptodate"}} isn't working the way we 
think it should (possibly because of the way the various build files are 
included in one another?)

If we can't keep the {{https://ant.apache.org/manual/Tasks/typedef.html
{quote}
If you are defining tasks or types that share the same classpath with multiple 
taskdef or typedef tasks, the corresponding classes will be loaded by different 
Java ClassLoaders. Two classes with the same name loaded via different 
ClassLoaders are not the same class from the point of view of the Java VM, they 
don't share static variables and instances of these classes can't access 
private methods or attributes of instances defined by "the other class" of the 
same name. They don't even belong to the same Java package and can't access 
package private code, either.

The best way to load several tasks/types that are supposed to cooperate with 
each other via shared Java code is to use the resource attribute and an antlib 
descriptor. If this is not possible, the second best option is to use the 
loaderref attribute and specify the same name for each and every 
typedef/taskdef - this way the classes will share the same ClassLoader. Note 
that the typedef/taskdef tasks must use identical classpath defintions (this 
includes the order of path components) for the loaderref attribute to work.
{quote}
...it appears it's just some unique string key to name the classloader? (no 
idea if it whatever is causing hte current problem will still plague by 
creating multiple loaders with the same name)...
https://svn.apache.org/viewvc/ant/core/tags/ANT_171/src/etc/testcases/core/loaderref/

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, ant_-verbose_clean_test.out.txt
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Chris Male (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240938#comment-13240938
 ] 

Chris Male commented on LUCENE-3930:


bq. Now we have the problematic patched jars and the renamed unreleased jars.

For the unreleased jars, can we just include their source in our source? This 
would work for commons-csv and noggit which are the only two in solr/lib.  
They're both very small jars with only a handful of java files.

I'm running into bigger problems with the libs in the solr contrib langid.  The 
langdect jar is from a revision I cannot find in its googlecode project (due to 
a switch from svn to git) and the jsonic jar it depends on isn't available in 
ivy accessible repos, only version 1.2.8 is.

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, ant_-verbose_clean_test.out.txt
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3930) nuke jars from source tree and use ivy

[Hoss Man (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated LUCENE-3930:
-

Attachment: ant_-verbose_clean_test.out.txt

Attaching full stderr/stdout of a (differnet "ant -verbose clean test" run that 
ended with another PermGen OOM...

{noformat}
hossman@bester:~/lucene/branch_lucene3930$ ant -verbose clean test 2>&1 > 
ant_-verbose_clean_test.out.txt
java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClassOrNull(ClassLoader.java:927)
at java.lang.ClassLoader.loadClass(ClassLoader.java:298)
at java.lang.ClassLoader.loadClass(ClassLoader.java:296)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:296)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.apache.tools.ant.DefaultLogger.formatTime(DefaultLogger.java:323)
at 
org.apache.tools.ant.DefaultLogger.buildFinished(DefaultLogger.java:170)
at org.apache.tools.ant.Project.fireBuildFinished(Project.java:2037)
at org.apache.tools.ant.Main.runBuild(Main.java:778)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
PermGen space
{noformat}

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, ant_-verbose_clean_test.out.txt
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3029) Poor json formatting of spelling collation info

[Yonik Seeley (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240923#comment-13240923
 ] 

Yonik Seeley commented on SOLR-3029:


OK, this may be too much for 3.6.
I tried an example and it looks like there are a couple of places with this 
problem.

I edited solr.xml so the name field looked like
{code}
  Solr, the Enterprise Search Server solra solrb abcdefgx 
abcdefgy
{code}

Then I tried the following spellcheck command:

http://localhost:8983/solr/spell?q=abcdefgq%20solrz&spellcheck=true&spellcheck.collate=true&spellcheck.build=true&spellcheck.collateExtendedResults=true&spellcheck.count=3&spellcheck.maxCollations=3&wt=json&indent=true

{code}
  "spellcheck":{
"suggestions":[
  "abcdefgq",{
"numFound":2,
"startOffset":0,
"endOffset":8,
"suggestion":["abcdefgx",
  "abcdefgy"]},
  "solrz",{
"numFound":3,
"startOffset":9,
"endOffset":14,
"suggestion":["solra",
  "solrb",
  "solr"]},
  "collation",[
"collationQuery","abcdefgx solra",
"hits",0,
"misspellingsAndCorrections",[
  "abcdefgq","abcdefgx",
  "solrz","solra"]]]}}
{code}

Apologies if I'm misinterpreting some things - I don't have much experience 
with the spellchecker stuff (other than trying to clean up the tests in the 
past).
Observations:
- Unless order is really important, "suggestions" should be a map
- same for "collation" and "misspellingsAndCorrections"
- why is "collation" inside "suggestions" along with other words?  should this 
be one level higher?
- why isn't this giving me multiple collations... am I misunderstanding the 
spellcheck.maxCollations parameter
- why aren't multiple suggestions returned in misspellingsAndCorrections?  (and 
what's the purpose of this seemingly redundant info anyway?)
- I briefly tried distributed search by adding 
&shards=localhost:8983/solr&shards.qt=/spell and I get
{code}
  "error":{
"msg":"isShard is only acceptable with search handlers",
"code":400}}
{code}


> Poor json formatting of spelling collation info
> ---
>
> Key: SOLR-3029
> URL: https://issues.apache.org/jira/browse/SOLR-3029
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.0
>Reporter: Antony Stubbs
>Priority: Blocker
> Attachments: SOLR-3029.patch
>
>
> {noformat}
> "spellcheck": {
> "suggestions": [
> "dalllas",
> {
> 
> {
> "word": "canallas",
> "freq": 1
> }
> ]
> },
> "correctlySpelled",
> false,
> "collation",
> "dallas"
> ]
> }
> {noformat}
> The correctlySpelled and collation key/values are stored as consecutive 
> elements in an array - quite odd. Is there a reason isn't not a key/value map 
> like most things?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Hoss Man (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240918#comment-13240918
 ] 

Hoss Man commented on LUCENE-3930:
--

here's the tail end of "ant -verbose clean test"...

{noformat}
hossman@bester:~/lucene/branch_lucene3930$ ant -verbose clean test

...

compile-test-framework:
Skipped because property 'lucene.test.framework.compiled' set.

common.compile-test:
[mkdir] Skipping 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/demo/classes/test 
because it already exists.
Property "run.clover" has not been set
[javac] org/apache/lucene/demo/TestDemo.java omitted as 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/demo/classes/test/org/apache/lucene/demo/TestDemo.class
 is up to date.
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/apache1.0.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/apache1.1.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/apache2.0.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/cpl1.0.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/epl1.0.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/freebsd.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/gpl1.0.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/gpl2.0.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/gpl3.0.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/lgpl2.1.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/lgpl3.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/lpgl2.0.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/mit.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/mozilla1.1.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/mozilla_eula_firefox3.txt
 skipped - don't know how to handle it
[javac] 
/home/hossman/lucene/branch_lucene3930/lucene/contrib/demo/src/test/org/apache/lucene/demo/test-files/docs/mozilla_eula_thunderbird2.txt
 skipped - don't know how to handle it
 [copy] org/apache/lucene/demo/test-files/docs/apache1.0.txt omitted as 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/demo/classes/test/org/apache/lucene/demo/test-files/docs/apache1.0.txt
 is up to date.
 [copy] org/apache/lucene/demo/test-files/docs/apache1.1.txt omitted as 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/demo/classes/test/org/apache/lucene/demo/test-files/docs/apache1.1.txt
 is up to date.
 [copy] org/apache/lucene/demo/test-files/docs/apache2.0.txt omitted as 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/demo/classes/test/org/apache/lucene/demo/test-files/docs/apache2.0.txt
 is up to date.
 [copy] org/apache/lucene/demo/test-files/docs/cpl1.0.txt omitted as 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/demo/classes/test/org/apache/lucene/demo/test-files/docs/cpl1.0.txt
 is up to date.
 [copy] org/apache/lucene/demo/test-files/docs/epl1.0.txt omitted as 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/demo/classes/test/org/apache/lucene/demo/test-files/docs/epl1.0.txt
 is up to date.
 [copy] org/apache/lucene/demo/test-files/docs/freebsd.txt omitted as 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/demo/classes/test/org/apache/lucene/demo/test-files/docs/freebsd.txt
 is up to date.
 [copy] org/apache/lucene/demo/test-files/docs/g

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Hoss Man (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240912#comment-13240912
 ] 

Hoss Man commented on LUCENE-3930:
--

I did a {{touch 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-FAKE.txt}} to 
work around the license checker and this time i wound up with an OOM...

{noformat}
hossman@bester:~/lucene/branch_lucene3930$ ant clean test

common.compile-test:
[mkdir] Created dir: 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/sandbox/classes/test
[javac] Compiling 6 source files to 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/sandbox/classes/test
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
 [copy] Copied 1 empty directory to 1 empty directory under 
/home/hossman/lucene/branch_lucene3930/lucene/build/contrib/sandbox/classes/test

test-contrib:
 [echo] Building demo...

download-ivy:

install-ivy:

resolve:
[ivy:retrieve] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ ::
[ivy:retrieve] :: loading settings :: url = 
jar:file:/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
java.lang.OutOfMemoryError: PermGen space
java.lang.OutOfMemoryError: PermGen space
at java.lang.Throwable.getStackTraceElement(Native Method)
at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
at java.lang.Throwable.printStackTrace(Throwable.java:462)
at java.lang.Throwable.printStackTrace(Throwable.java:451)
at org.apache.tools.ant.Main.startAnt(Main.java:230)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
{noformat}

running with "-verbose" to see if i can get more details on exactly where/why 
the OOM is happening


> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Chris Male (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240877#comment-13240877
 ] 

Chris Male commented on LUCENE-3930:


Thanks hoss, I will add in a LICENSE and NOTICE for ivy.

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Hoss Man (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240864#comment-13240864
 ] 

Hoss Man commented on LUCENE-3930:
--

FWIW i did a completley clean checkout of the lucene3930 (r1306662) and got 
the following build failure trying to run "ant clean test" from the top level.

the ivy bootstraping doesn't seem to play nicely with the license checker...

{noformat}
hossman@bester:~/lucene/branch_lucene3930$ ant clean test
Buildfile: build.xml

clean:

clean:

clean:

clean:
 [echo] Building analyzers-common...

clean:
 [echo] Building analyzers-icu...

clean:
 [echo] Building analyzers-kuromoji...

clean:
 [echo] Building analyzers-morfologik...

clean:
 [echo] Building analyzers-phonetic...

clean:
 [echo] Building analyzers-smartcn...

clean:
 [echo] Building analyzers-stempel...

clean:
 [echo] Building analyzers-uima...

clean:
 [echo] Building benchmark...

clean:
 [echo] Building facet...

clean:
 [echo] Building grouping...

clean:
 [echo] Building join...

clean:
 [echo] Building queries...

clean:
 [echo] Building queryparser...

clean:
 [echo] Building spatial...

clean:
 [echo] Building suggest...

clean:
 [echo] Building solr...

clean:

validate:

compile-tools:

download-ivy:
[mkdir] Created dir: /home/hossman/lucene/branch_lucene3930/lucene/ivy
 [echo] 
 [echo]   NOTE: You do not have ivy installed, so downloading it...
 [echo]   If you make lots of checkouts, download ivy-2.2.0.jar 
yourself 
 [echo]   and set ivy.jar.file to this in your ~/build.properties
 [echo]   
  [get] Getting: 
http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.2.0/ivy-2.2.0.jar
  [get] To: /home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-2.2.0.jar

install-ivy:

resolve:
[ivy:retrieve] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ ::
[ivy:retrieve] :: loading settings :: url = 
jar:file:/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml

init:

compile-core:
[mkdir] Created dir: 
/home/hossman/lucene/branch_lucene3930/lucene/build/tools/classes/java
[javac] Compiling 2 source files to 
/home/hossman/lucene/branch_lucene3930/lucene/build/tools/classes/java
 [copy] Copying 1 file to 
/home/hossman/lucene/branch_lucene3930/lucene/build/tools/classes/java

validate:
 [echo] License check under: /home/hossman/lucene/branch_lucene3930/lucene
 [licenses] MISSING LICENSE for the following file:
 [licenses]   /home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-2.2.0.jar
 [licenses]   Expected locations below:
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-ASL.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-BSD.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-BSD_LIKE.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-CDDL.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-CPL.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-EPL.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-MIT.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-MPL.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-PD.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-SUN.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-COMPOUND.txt
 [licenses]   => 
/home/hossman/lucene/branch_lucene3930/lucene/ivy/ivy-LICENSE-FAKE.txt
 [licenses] Scanned 1 JAR file(s) for licenses (in 0.31s.), 1 error(s).

BUILD FAILED
/home/hossman/lucene/branch_lucene3930/build.xml:42: The following error 
occurred while executing this line:
/home/hossman/lucene/branch_lucene3930/lucene/build.xml:178: The following 
error occurred while executing this line:
/home/hossman/lucene/branch_lucene3930/lucene/tools/custom-tasks.xml:22: 
License check failed. Check the logs.

Total time: 5 seconds
{noformat}

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically ge

[jira] [Updated] (SOLR-3029) Poor json formatting of spelling collation info

[Yonik Seeley (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley updated SOLR-3029:
---

Priority: Blocker  (was: Major)

> Poor json formatting of spelling collation info
> ---
>
> Key: SOLR-3029
> URL: https://issues.apache.org/jira/browse/SOLR-3029
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.0
>Reporter: Antony Stubbs
>Priority: Blocker
> Attachments: SOLR-3029.patch
>
>
> {noformat}
> "spellcheck": {
> "suggestions": [
> "dalllas",
> {
> 
> {
> "word": "canallas",
> "freq": 1
> }
> ]
> },
> "correctlySpelled",
> false,
> "collation",
> "dallas"
> ]
> }
> {noformat}
> The correctlySpelled and collation key/values are stored as consecutive 
> elements in an array - quite odd. Is there a reason isn't not a key/value map 
> like most things?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-3292) /browse example fails to load on 3x: "no field name specified in query and no default specified via 'df' param"

[Hoss Man (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man resolved SOLR-3292.


Resolution: Fixed
  Assignee: Hoss Man

> /browse example fails to load on 3x: "no field name specified in query and no 
> default specified via 'df' param"
> ---
>
> Key: SOLR-3292
> URL: https://issues.apache.org/jira/browse/SOLR-3292
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 3.6
>
>
> 1) java -jar start.jar using solr example on 3x branch circa r1306629
> 2) load http://localhost:8983/solr/browse
> 3) browser error: 400 "no field name specified in query and no default 
> specified via 'df' param"
> 4) error in logs...
> {noformat}
> INFO: [] webapp=/solr path=/browse params={} hits=0 status=400 QTime=3 
> Mar 28, 2012 4:05:59 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: no field name specified in 
> query and no default specified via 'df' param
>   at 
> org.apache.solr.search.SolrQueryParser.checkNullField(SolrQueryParser.java:158)
>   at 
> org.apache.solr.search.SolrQueryParser.getFieldQuery(SolrQueryParser.java:174)
>   at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1429)
>   at 
> org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1317)
>   at 
> org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1245)
>   at 
> org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1234)
>   at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:206)
>   at 
> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:79)
>   at org.apache.solr.search.QParser.getQuery(QParser.java:143)
>   at 
> org.apache.solr.request.SimpleFacets.getFacetQueryCounts(SimpleFacets.java:233)
>   at 
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:194)
>   at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:72)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:186)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2724) Deprecate defaultSearchField and defaultOperator defined in schema.xml

[Hoss Man (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240847#comment-13240847
 ] 

Hoss Man commented on SOLR-2724:


Whatever happens with this issue, please note SOLR-3292 and commit r1306642 
that was needed on the 3x branch to keep all aspects of the example working.

(i didn't make changes on trunk for SOLR-3292 since miller had already reverted 
SOLR-2724 there, SOLR-3292's changes should be included if/when SOLR-2724 is 
re-applied)

> Deprecate defaultSearchField and defaultOperator defined in schema.xml
> --
>
> Key: SOLR-2724
> URL: https://issues.apache.org/jira/browse/SOLR-2724
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis, search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 3.6, 4.0
>
> Attachments: 
> SOLR-2724_deprecateDefaultSearchField_and_defaultOperator.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I've always been surprised to see the  element and 
>  defined in the schema.xml file since 
> the first time I saw them.  They just seem out of place to me since they are 
> more query parser related than schema related. But not only are they 
> misplaced, I feel they shouldn't exist. For query parsers, we already have a 
> "df" parameter that works just fine, and explicit field references. And the 
> default lucene query operator should stay at OR -- if a particular query 
> wants different behavior then use q.op or simply use "OR".
>  Seems like something better placed in solrconfig.xml than in the 
> schema. 
> In my opinion, defaultSearchField and defaultOperator configuration elements 
> should be deprecated in Solr 3.x and removed in Solr 4.  And  
> should move to solrconfig.xml. I am willing to do it, provided there is 
> consensus on it of course.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 2134 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/2134/

1 tests failed.
REGRESSION:  
org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest.testMultiThreaded

Error Message:
Uncaught exception by thread: Thread[DocThread-1,5,]

Stack Trace:
org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread:
 Uncaught exception by thread: Thread[DocThread-1,5,]
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:83)
at 
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:508)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:146)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:61)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:36)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:67)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
Caused by: java.lang.AssertionError: 
DocThread-1---org.apache.commons.httpclient.ConnectTimeoutException: The host 
did not accept the connection within timeout of 100 ms
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.client.solrj.LargeVolumeTestBase$DocThread.run(LargeVolumeTestBase.java:120)




Build Log (for compile errors):
[...truncated 17229 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3292) /browse example fails to load on 3x: "no field name specified in query and no default specified via 'df' param"

[Erik Hatcher (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240824#comment-13240824
 ] 

Erik Hatcher commented on SOLR-3292:


This comes from facet.query's in the /browse handler definition:

{code}
ipod
GB
{code}

I just added, locally, {code}text{code} and all is well.  
Is that the fix we want to commit?

> /browse example fails to load on 3x: "no field name specified in query and no 
> default specified via 'df' param"
> ---
>
> Key: SOLR-3292
> URL: https://issues.apache.org/jira/browse/SOLR-3292
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Priority: Blocker
> Fix For: 3.6
>
>
> 1) java -jar start.jar using solr example on 3x branch circa r1306629
> 2) load http://localhost:8983/solr/browse
> 3) browser error: 400 "no field name specified in query and no default 
> specified via 'df' param"
> 4) error in logs...
> {noformat}
> INFO: [] webapp=/solr path=/browse params={} hits=0 status=400 QTime=3 
> Mar 28, 2012 4:05:59 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: no field name specified in 
> query and no default specified via 'df' param
>   at 
> org.apache.solr.search.SolrQueryParser.checkNullField(SolrQueryParser.java:158)
>   at 
> org.apache.solr.search.SolrQueryParser.getFieldQuery(SolrQueryParser.java:174)
>   at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1429)
>   at 
> org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1317)
>   at 
> org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1245)
>   at 
> org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1234)
>   at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:206)
>   at 
> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:79)
>   at org.apache.solr.search.QParser.getQuery(QParser.java:143)
>   at 
> org.apache.solr.request.SimpleFacets.getFacetQueryCounts(SimpleFacets.java:233)
>   at 
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:194)
>   at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:72)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:186)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3292) /browse example fails to load on 3x: "no field name specified in query and no default specified via 'df' param"

[Hoss Man (Created) (JIRA)]

/browse example fails to load on 3x: "no field name specified in query and no 
default specified via 'df' param"
---

 Key: SOLR-3292
 URL: https://issues.apache.org/jira/browse/SOLR-3292
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Priority: Blocker
 Fix For: 3.6


1) java -jar start.jar using solr example on 3x branch circa r1306629
2) load http://localhost:8983/solr/browse
3) browser error: 400 "no field name specified in query and no default 
specified via 'df' param"
4) error in logs...

{noformat}
INFO: [] webapp=/solr path=/browse params={} hits=0 status=400 QTime=3 
Mar 28, 2012 4:05:59 PM org.apache.solr.common.SolrException log
SEVERE: org.apache.solr.common.SolrException: no field name specified in query 
and no default specified via 'df' param
at 
org.apache.solr.search.SolrQueryParser.checkNullField(SolrQueryParser.java:158)
at 
org.apache.solr.search.SolrQueryParser.getFieldQuery(SolrQueryParser.java:174)
at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1429)
at 
org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1317)
at 
org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1245)
at 
org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1234)
at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:206)
at 
org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:79)
at org.apache.solr.search.QParser.getQuery(QParser.java:143)
at 
org.apache.solr.request.SimpleFacets.getFacetQueryCounts(SimpleFacets.java:233)
at 
org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:194)
at 
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:72)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:186)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-2000) Use covariant clone() return types

[Ryan McKinley (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved LUCENE-2000.
---

   Resolution: Fixed
Fix Version/s: 4.0
 Assignee: Ryan McKinley
Lucene Fields:   (was: New)

added to trunk in #1306626

This won't be ported to 3.x

> Use covariant clone() return types
> --
>
> Key: LUCENE-2000
> URL: https://issues.apache.org/jira/browse/LUCENE-2000
> Project: Lucene - Java
>  Issue Type: Task
>  Components: core/other
>Affects Versions: 3.0
>Reporter: Uwe Schindler
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-2000-clone_covariance.patch, 
> LUCENE-2000-clone_covariance.patch
>
>
> *Paul Cowan wrote in LUCENE-1257:*
> OK, thought I'd jump in and help out here with one of my Java 5 favourites. 
> Haven't seen anyone discuss this, and don't believe any of the patches 
> address this, so thought I'd throw a patch out there (against SVN HEAD @ 
> revision 827821) which uses Java 5 covariant return types for (almost) all of 
> the Object#clone() implementations in core. 
> i.e. this:
> public Object clone() {
> changes to:
> public SpanNotQuery clone() {
> which lets us get rid of a whole bunch of now-unnecessary casts, so e.g.
> if (clone == null) clone = (SpanNotQuery) this.clone();
> becomes
> if (clone == null) clone = this.clone();
> Almost everything has been done and all downcasts removed, in core, with the 
> exception of
> Some SpanQuery stuff, where it's assumed that it's safe to cast the clone() 
> of a SpanQuery to a SpanQuery - this can't be made covariant without 
> declaring "abstract SpanQuery clone()" in SpanQuery itself, which breaks 
> those SpanQuerys that don't declare their own clone() 
> Some IndexReaders, e.g. DirectoryReader - we can't be more specific than 
> changing .clone() to return IndexReader, because it returns the result of 
> IndexReader.clone(boolean). We could use covariant types for THAT, which 
> would work fine, but that didn't follow the pattern of the others so that 
> could be a later commit. 
> Two changes were also made in contrib/, where not making the changes would 
> have broken code by trying to widen IndexInput#clone() back out to returning 
> Object, which is not permitted. contrib/ was otherwise left untouched.
> Let me know what you think, or if you have any other questions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-2000) Use covariant clone() return types

[Uwe Schindler (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240763#comment-13240763
 ] 

Uwe Schindler commented on LUCENE-2000:
---

In Lucene trunk we break backwards, be free to change it! I am fine with it.

(this is why I kept it open)

> Use covariant clone() return types
> --
>
> Key: LUCENE-2000
> URL: https://issues.apache.org/jira/browse/LUCENE-2000
> Project: Lucene - Java
>  Issue Type: Task
>  Components: core/other
>Affects Versions: 3.0
>Reporter: Uwe Schindler
>Priority: Minor
> Attachments: LUCENE-2000-clone_covariance.patch, 
> LUCENE-2000-clone_covariance.patch
>
>
> *Paul Cowan wrote in LUCENE-1257:*
> OK, thought I'd jump in and help out here with one of my Java 5 favourites. 
> Haven't seen anyone discuss this, and don't believe any of the patches 
> address this, so thought I'd throw a patch out there (against SVN HEAD @ 
> revision 827821) which uses Java 5 covariant return types for (almost) all of 
> the Object#clone() implementations in core. 
> i.e. this:
> public Object clone() {
> changes to:
> public SpanNotQuery clone() {
> which lets us get rid of a whole bunch of now-unnecessary casts, so e.g.
> if (clone == null) clone = (SpanNotQuery) this.clone();
> becomes
> if (clone == null) clone = this.clone();
> Almost everything has been done and all downcasts removed, in core, with the 
> exception of
> Some SpanQuery stuff, where it's assumed that it's safe to cast the clone() 
> of a SpanQuery to a SpanQuery - this can't be made covariant without 
> declaring "abstract SpanQuery clone()" in SpanQuery itself, which breaks 
> those SpanQuerys that don't declare their own clone() 
> Some IndexReaders, e.g. DirectoryReader - we can't be more specific than 
> changing .clone() to return IndexReader, because it returns the result of 
> IndexReader.clone(boolean). We could use covariant types for THAT, which 
> would work fine, but that didn't follow the pattern of the others so that 
> could be a later commit. 
> Two changes were also made in contrib/, where not making the changes would 
> have broken code by trying to widen IndexInput#clone() back out to returning 
> Object, which is not permitted. contrib/ was otherwise left untouched.
> Let me know what you think, or if you have any other questions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-2000) Use covariant clone() return types

[Ryan McKinley (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated LUCENE-2000:
--

Attachment: LUCENE-2000-clone_covariance.patch

updating to /trunk

But if Uwe thinks this is a bad idea... i can accept that :)

> Use covariant clone() return types
> --
>
> Key: LUCENE-2000
> URL: https://issues.apache.org/jira/browse/LUCENE-2000
> Project: Lucene - Java
>  Issue Type: Task
>  Components: core/other
>Affects Versions: 3.0
>Reporter: Uwe Schindler
>Priority: Minor
> Attachments: LUCENE-2000-clone_covariance.patch, 
> LUCENE-2000-clone_covariance.patch
>
>
> *Paul Cowan wrote in LUCENE-1257:*
> OK, thought I'd jump in and help out here with one of my Java 5 favourites. 
> Haven't seen anyone discuss this, and don't believe any of the patches 
> address this, so thought I'd throw a patch out there (against SVN HEAD @ 
> revision 827821) which uses Java 5 covariant return types for (almost) all of 
> the Object#clone() implementations in core. 
> i.e. this:
> public Object clone() {
> changes to:
> public SpanNotQuery clone() {
> which lets us get rid of a whole bunch of now-unnecessary casts, so e.g.
> if (clone == null) clone = (SpanNotQuery) this.clone();
> becomes
> if (clone == null) clone = this.clone();
> Almost everything has been done and all downcasts removed, in core, with the 
> exception of
> Some SpanQuery stuff, where it's assumed that it's safe to cast the clone() 
> of a SpanQuery to a SpanQuery - this can't be made covariant without 
> declaring "abstract SpanQuery clone()" in SpanQuery itself, which breaks 
> those SpanQuerys that don't declare their own clone() 
> Some IndexReaders, e.g. DirectoryReader - we can't be more specific than 
> changing .clone() to return IndexReader, because it returns the result of 
> IndexReader.clone(boolean). We could use covariant types for THAT, which 
> would work fine, but that didn't follow the pattern of the others so that 
> could be a later commit. 
> Two changes were also made in contrib/, where not making the changes would 
> have broken code by trying to widen IndexInput#clone() back out to returning 
> Object, which is not permitted. contrib/ was otherwise left untouched.
> Let me know what you think, or if you have any other questions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Compiling JCC as shared object

[Caleb Burns]

I guess that explains why the older patch worked for me. Thanks for the
help.

On Wed, Mar 28, 2012 at 4:17 PM, Andi Vajda  wrote:

>
> On Wed, 28 Mar 2012, Andi Vajda wrote:
>
>  On Mar 28, 2012, at 10:02, Caleb Burns  wrote:
>>
>>  My version of setuptools is 0.6.15-1ubuntu1
>>>
>>
>> Oh 0.6.c15, I haven't seen that before.
>> It looks like a new patch is going to be needed.
>>
>
> This is even more interesting.
> I just installed Ubuntu 11.10 (oneiric) and the latest setuptools.
>
> There seems to be some kind of new (?) setuptools fork called 0.6.15 (or
> 0.6.16) which claims compatibility with setuptools 0.6.c9 (!).
> This explains why the older patch applies.
>
> I'm going to 'enhance' the logic to pick the patch based on this new
> setuptools pedigree.
>
> Andi..
>
>
>
>> Thank you for reporting this !
>>
>> Andi..
>>
>>
>>> patch.43.0.6c11 fails on Hunk #1:
>>>
>>> sudo patch -d /usr/lib/python2.7/dist-**packages -Nup0 <
>>> /home/caleb/Exclude/Downloads/**pylucene-3.4.0-1/jcc/jcc/**
>>> patches/patch.43.0.6c11
>>> patching file setuptools/extension.py
>>> patching file setuptools/command/build_ext.**py
>>> Hunk #1 FAILED at 85.
>>> Hunk #2 succeeded at 177 (offset 7 lines).
>>> Hunk #3 succeeded at 259 (offset 7 lines).
>>> 1 out of 3 hunks FAILED -- saving rejects to file
>>> setuptools/command/build_ext.**py.rej
>>>
>>> patch.43.0.6c7 succeeds:
>>>
>>> sudo patch -d /usr/lib/python2.7/dist-**packages -Nup0 <
>>> /home/caleb/Exclude/Downloads/**pylucene-3.4.0-1/jcc/jcc/**
>>> patches/patch.43.0.6c7
>>> patching file setuptools/extension.py
>>> patching file setuptools/command/build_ext.**py
>>> Hunk #1 succeeded at 86 with fuzz 1 (offset 2 lines).
>>> Hunk #2 succeeded at 181 (offset 7 lines).
>>> Hunk #3 succeeded at 263 (offset 7 lines).
>>>
>>> NOTE: Each after reinstalls of setuptools.
>>>
>>> On Wed, Mar 28, 2012 at 12:57 PM, Andi Vajda  wrote:
>>>
>>>
 On Wed, 28 Mar 2012, Caleb Burns wrote:

 According to

> http://lucene.apache.org/pylucene/jcc/install#shared_**
> mode_support_for_the_code--sharedcode_flag apache.org/pylucene/jcc/**install#shared_mode_support_**
> for_the_code--sharedcode_flag
> >
> (or
> doc/jcc/documentation/install.html#shared from pylucene tarball),
> I
> can set
> the `--shared` flag in order to compile JCC as a shared object instead
> of
> a
> static one. There's also mention about applying a patch to setuptools
> on
> Linux (I'm running Ubuntu 11.04). I'm confused as to how exactly one is
> supposed to do this.
>
> If I run `python setup.py build` from "jcc/" I'm greeted with a message
> saying shared mode is disabled and setuptools patch.43.0.6c11 must be
> applied to enable it. So I apply the patch with the friendly help from
> the
> displayed message: `sudo patch -d /usr/lib/python2.7/dist-packages
> -Nup0 <
> /home/caleb/Exclude/Downloads/pylucene-3.4.0-1/jcc/jcc/**
> patches/patch.43.0.6c11`.
> Then if I try to build again with `python setup.py build`, it builds
> successfully but I get "libjcc.a" under "jcc/build/lib.linux-x86_64-2.
> 
> 7/"
> instead of "libjcc.so". If I pass `--shared` to `python setup.py
> build` I
> simply get "error: option --shared not recognized". If I apply
> "patch.43.0.6c7" instead of "patch.43.0.6c11" on a fresh reinstall of
> setuptools and then build with `python setup.py build`, the resulting
> build
> has "libjcc.so" instead of "libjcc.a". Is this supposed to work this
> way?
> Where is the `--shared` flag involved? And why does `setup.py` say to
> use "patch.43.0.6c11" to enabled shared mode when only "patch.43.0.6c7"
> seems to enable it?
>
>
 The suggested patch version is figured out from the version of
 setuptools
 you have. If you have a setuptools version < 0.6c11, it suggests you use
 patch.43.0.6c7, otherwise patch.43.0.6c11. If a new version of
 setuptools
 appeared that breaks this logic or were to need a new patch, all bets
 are
 off, of course.

 What version of setuptools do you have installed ?
 Did the patch patch.43.0.6c7 install cleanly ?

 Andi..

 The reason I'm asking is because I working on a Python C++ module for

> performing quick calculations that interacts with Lucene (specifically
> PyLucene).
>
>
> --
> Caleb Burns
> Developer | Riders Discount
> 866.931.6644 x851 | www.RidersDiscount.com  **
> com/ 
> >>
> [image: image.png] 
> 

[jira] [Resolved] (LUCENE-3933) Cloneable classes can use their class in the clone() function

[Ryan McKinley (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved LUCENE-3933.
---

   Resolution: Duplicate
Lucene Fields:   (was: Patch Available)

> Cloneable classes can use their class in the clone() function
> -
>
> Key: LUCENE-3933
> URL: https://issues.apache.org/jira/browse/LUCENE-3933
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Trivial
>
> Since Java5, we are allowed to use an explicit class when returning clone()
> It is nicer to use:
> {code:java}
> OpenBitSet copy = original.clone();
> {code}
> then
> {code:java}
> OpenBitSet copy = (OpenBitSet)original.clone();
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3933) Cloneable classes can use their class in the clone() function

[Robert Muir (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240698#comment-13240698
 ] 

Robert Muir commented on LUCENE-3933:
-

This is a duplicate of LUCENE-2000

> Cloneable classes can use their class in the clone() function
> -
>
> Key: LUCENE-3933
> URL: https://issues.apache.org/jira/browse/LUCENE-3933
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Trivial
>
> Since Java5, we are allowed to use an explicit class when returning clone()
> It is nicer to use:
> {code:java}
> OpenBitSet copy = original.clone();
> {code}
> then
> {code:java}
> OpenBitSet copy = (OpenBitSet)original.clone();
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-3933) Cloneable classes can use their class in the clone() function

[Ryan McKinley (Created) (JIRA)]

Cloneable classes can use their class in the clone() function
-

 Key: LUCENE-3933
 URL: https://issues.apache.org/jira/browse/LUCENE-3933
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Trivial


Since Java5, we are allowed to use an explicit class when returning clone()

It is nicer to use:
{code:java}
OpenBitSet copy = original.clone();
{code}
then
{code:java}
OpenBitSet copy = (OpenBitSet)original.clone();
{code}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-3932) Improve load time of .tii files

[Sean Bridges (Created) (JIRA)]

Improve load time of .tii files
---

 Key: LUCENE-3932
 URL: https://issues.apache.org/jira/browse/LUCENE-3932
 Project: Lucene - Java
  Issue Type: Improvement
Affects Versions: 3.5
 Environment: Linux
Reporter: Sean Bridges


We have a large 50 gig index which is optimized as one segment, with a 66 MEG 
.tii file.  This index has no norms, and no field cache.

It takes about 5 seconds to load this index, profiling reveals that 60% of the 
time is spent in GrowableWriter.set(index, value), and most of time in set(...) 
is spent resizing PackedInts.Mutatable current.

In the constructor for TermInfosReaderIndex, you initialize the writer with the 
line,

{quote}GrowableWriter indexToTerms = new GrowableWriter(4, indexSize, 
false);{quote}

For our index using four as the bit estimate results in 27 resizes.

The last value in indexToTerms is going to be ~ tiiFileLength, and if instead 
you use,

{quote}int bitEstimate = (int) Math.ceil(Math.log10(tiiFileLength) / 
Math.log10(2));
GrowableWriter indexToTerms = new GrowableWriter(bitEstimate, indexSize, 
false);{quote}

Load time improves to ~ 2 seconds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Issue Comment Edited] (SOLR-2724) Deprecate defaultSearchField and defaultOperator defined in schema.xml

[Yonik Seeley (Issue Comment Edited) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240633#comment-13240633
 ] 

Yonik Seeley edited comment on SOLR-2724 at 3/28/12 7:04 PM:
-

I think I agree with Hoss and Erick here... we're not really gaining anything 
with this change, and it does seem likely it will cause problems for people 
upgrading.

edit: I wouldn't treat q.op and defaultField the same way either... I agree w/ 
Hoss that defaultSearchField seems useful, and I don't even think it should be 
deprecated or declared bad practice.  I would remove q.op from the example 
schema (but perhaps retain the code for those who already use it).

  was (Author: ysee...@gmail.com):
I think I agree with Hoss and Erick here... we're not really gaining 
anything with this change, and it does seem likely it will cause problems for 
people upgrading.
  
> Deprecate defaultSearchField and defaultOperator defined in schema.xml
> --
>
> Key: SOLR-2724
> URL: https://issues.apache.org/jira/browse/SOLR-2724
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis, search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 3.6, 4.0
>
> Attachments: 
> SOLR-2724_deprecateDefaultSearchField_and_defaultOperator.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I've always been surprised to see the  element and 
>  defined in the schema.xml file since 
> the first time I saw them.  They just seem out of place to me since they are 
> more query parser related than schema related. But not only are they 
> misplaced, I feel they shouldn't exist. For query parsers, we already have a 
> "df" parameter that works just fine, and explicit field references. And the 
> default lucene query operator should stay at OR -- if a particular query 
> wants different behavior then use q.op or simply use "OR".
>  Seems like something better placed in solrconfig.xml than in the 
> schema. 
> In my opinion, defaultSearchField and defaultOperator configuration elements 
> should be deprecated in Solr 3.x and removed in Solr 4.  And  
> should move to solrconfig.xml. I am willing to do it, provided there is 
> consensus on it of course.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2724) Deprecate defaultSearchField and defaultOperator defined in schema.xml

[Yonik Seeley (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240633#comment-13240633
 ] 

Yonik Seeley commented on SOLR-2724:


I think I agree with Hoss and Erick here... we're not really gaining anything 
with this change, and it does seem likely it will cause problems for people 
upgrading.

> Deprecate defaultSearchField and defaultOperator defined in schema.xml
> --
>
> Key: SOLR-2724
> URL: https://issues.apache.org/jira/browse/SOLR-2724
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis, search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 3.6, 4.0
>
> Attachments: 
> SOLR-2724_deprecateDefaultSearchField_and_defaultOperator.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I've always been surprised to see the  element and 
>  defined in the schema.xml file since 
> the first time I saw them.  They just seem out of place to me since they are 
> more query parser related than schema related. But not only are they 
> misplaced, I feel they shouldn't exist. For query parsers, we already have a 
> "df" parameter that works just fine, and explicit field references. And the 
> default lucene query operator should stay at OR -- if a particular query 
> wants different behavior then use q.op or simply use "OR".
>  Seems like something better placed in solrconfig.xml than in the 
> schema. 
> In my opinion, defaultSearchField and defaultOperator configuration elements 
> should be deprecated in Solr 3.x and removed in Solr 4.  And  
> should move to solrconfig.xml. I am willing to do it, provided there is 
> consensus on it of course.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-2804) Logging error causes entire DIH process to fail

[James Dyer (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer resolved SOLR-2804.
--

Resolution: Won't Fix

The "threads" feature was removed from DIH in Trunk/4.x (see SOLR-3262). Some 
"threads" bugs were fixed in version 3.6, the last release in which "threads" 
is available. (see SOLR-3011).

To work around this issue with Solr 3.6, set the LogUpdateProcessorFactory 
level below "INFO".  (See comments on this issue for more information.)

> Logging error causes entire DIH process to fail
> ---
>
> Key: SOLR-2804
> URL: https://issues.apache.org/jira/browse/SOLR-2804
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.0
> Environment: java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
> Model Name:   MacBook Pro
>   Model Identifier:   MacBookPro8,2
>   Processor Name: Intel Core i7
>   Processor Speed:2.2 GHz
>   Number of Processors:   1
>   Total Number of Cores:  4
>   L2 Cache (per Core):256 KB
>   L3 Cache:   6 MB
>   Memory: 4 GB
> System Software Overview:
>   System Version: Mac OS X 10.6.8 (10K549)
>   Kernel Version: Darwin 10.8.0
>Reporter: Pulkit Singhal
>  Labels: dih
> Attachments: SOLR-2804-3x.patch, SOLR-2804.patch, SOLR-2804.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> SEVERE: Full Import failed:java.lang.ClassCastException:
> java.util.ArrayList cannot be cast to java.lang.String
>at org.apache.solr.common.util.NamedList.getName(NamedList.java:127)
>at org.apache.solr.common.util.NamedList.toString(NamedList.java:263)
>at java.lang.String.valueOf(String.java:2826)
>at java.lang.StringBuilder.append(StringBuilder.java:115)
>at 
> org.apache.solr.update.processor.LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:188)
>at 
> org.apache.solr.handler.dataimport.SolrWriter.close(SolrWriter.java:57)
>at 
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:265)
>at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:372)
>at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:440)
>at 
> org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:421)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-1226) XPathEntityProcessor should resolve xsl references within Solr's configuration

[James Dyer (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer resolved SOLR-1226.
--

   Resolution: Won't Fix
Fix Version/s: (was: 4.0)
 Assignee: (was: Noble Paul)

The "threads" feature was removed from DIH in Trunk/4.x (see SOLR-3262). Some 
"threads" bugs were fixed in version 3.6, the last release in which "threads" 
is available. (see SOLR-3011).

> XPathEntityProcessor should resolve xsl references within Solr's configuration
> --
>
> Key: SOLR-1226
> URL: https://issues.apache.org/jira/browse/SOLR-1226
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: David Smiley
>Priority: Minor
> Attachments: SOLR-1226.patch
>
>
> The XPathEntityProcessor forces me to use a URL to specify where my XSL file 
> is.  if it is not a URL, what it should do is attempt to resolve it from 
> Solr's configuration  via SolrCore.getREsourceLoader().  I have attached a 
> patch which does this.
> Note: it is not clear in the DIH what the concurrency model is and thus I was 
> not certain that XPathEntityProcessor needs to be thread-safe or not.  So 
> just in case I cached the XSLT Transformer in a thread-safe manner using a 
> ThreadLocal.  If DIH committers know that it doesn't have to be thread-safe 
> then some of this code can be simplified.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-2961) DIH with threads and TikaEntityProcessor JDBC ISsue

[James Dyer (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer resolved SOLR-2961.
--

Resolution: Won't Fix

The "threads" feature was removed from DIH in Trunk/4.x (see SOLR-3262). Some 
"threads" bugs were fixed in version 3.6, the last release in which "threads" 
is available. (see SOLR-3011).

> DIH with threads and TikaEntityProcessor JDBC ISsue
> ---
>
> Key: SOLR-2961
> URL: https://issues.apache.org/jira/browse/SOLR-2961
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 3.4, 3.5
> Environment: Windows Server 2008, Apache Tomcat 6, Oracle 11g, ojdbc 
> 11.2.0.1
>Reporter: David Webb
>  Labels: dih, tika
> Attachments: SOLR-2961.patch, data-config.xml
>
>
> I have a DIH Configuration that works great when I dont specify threads="X" 
> in the root entity.  As soon as I give a value for threads, I get the 
> following error messages in the stacktrace.  Please advise.  
> SEVERE: JdbcDataSource was not closed prior to finalize(), indicates a bug -- 
> POSSIBLE RESOURCE LEAK!!!
> Dec 10, 2011 1:18:33 PM org.apache.solr.handler.dataimport.JdbcDataSource 
> closeConnection
> SEVERE: Ignoring Error when closing connection
> java.sql.SQLRecoverableException: IO Error: Socket closed
>   at oracle.jdbc.driver.T4CConnection.logoff(T4CConnection.java:511)
>   at 
> oracle.jdbc.driver.PhysicalConnection.close(PhysicalConnection.java:3931)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.closeConnection(JdbcDataSource.java:401)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.close(JdbcDataSource.java:392)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.finalize(JdbcDataSource.java:380)
>   at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
>   at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
>   at java.lang.ref.Finalizer.access$100(Unknown Source)
>   at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
> Caused by: java.net.SocketException: Socket closed
>   at java.net.SocketOutputStream.socketWrite(Unknown Source)
>   at java.net.SocketOutputStream.write(Unknown Source)
>   at oracle.net.ns.DataPacket.send(DataPacket.java:199)
>   at oracle.net.ns.NetOutputStream.flush(NetOutputStream.java:211)
>   at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:227)
>   at oracle.net.ns.NetInputStream.read(NetInputStream.java:175)
>   at oracle.net.ns.NetInputStream.read(NetInputStream.java:100)
>   at oracle.net.ns.NetInputStream.read(NetInputStream.java:85)
>   at 
> oracle.jdbc.driver.T4CSocketInputStreamWrapper.readNextPacket(T4CSocketInputStreamWrapper.java:123)
>   at 
> oracle.jdbc.driver.T4CSocketInputStreamWrapper.read(T4CSocketInputStreamWrapper.java:79)
>   at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1122)
>   at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1099)
>   at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:288)
>   at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:191)
>   at oracle.jdbc.driver.T4C7Ocommoncall.doOLOGOFF(T4C7Ocommoncall.java:61)
>   at oracle.jdbc.driver.T4CConnection.logoff(T4CConnection.java:498)
>   ... 8 more
> Dec 10, 2011 1:18:34 PM 
> org.apache.solr.handler.dataimport.ThreadedEntityProcessorWrapper nextRow
> SEVERE: Exception in entity : null
> org.apache.solr.handler.dataimport.DataImportHandlerException: Failed to 
> initialize DataSource: f2
>   at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:72)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.getDataSourceInstance(DataImporter.java:333)
>   at 
> org.apache.solr.handler.dataimport.ContextImpl.getDataSource(ContextImpl.java:99)
>   at 
> org.apache.solr.handler.dataimport.ThreadedContext.getDataSource(ThreadedContext.java:66)
>   at 
> org.apache.solr.handler.dataimport.TikaEntityProcessor.nextRow(TikaEntityProcessor.java:101)
>   at 
> org.apache.solr.handler.dataimport.ThreadedEntityProcessorWrapper.nextRow(ThreadedEntityProcessorWrapper.java:84)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder$EntityRunner.runAThread(DocBuilder.java:446)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder$EntityRunner.run(DocBuilder.java:399)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder$EntityRunner.runAThread(DocBuilder.java:466)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder$EntityRunner.run(DocBuilder.java:399)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder$EntityRunner.runAThread(DocBuilder.java:466)
>   at 
> org.apache.solr.handle

[jira] [Resolved] (SOLR-2233) DataImportHandler - JdbcDataSource is not thread safe

[James Dyer (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer resolved SOLR-2233.
--

Resolution: Won't Fix

The "threads" feature was removed from DIH in Trunk/4.x (see SOLR-3262).  Some 
"threads" bugs were fixed in version 3.6, the last release in which "threads" 
is available. (see SOLR-3011).

> DataImportHandler - JdbcDataSource is not thread safe
> -
>
> Key: SOLR-2233
> URL: https://issues.apache.org/jira/browse/SOLR-2233
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4, 1.4.1, 1.5, 3.1, 3.2
>Reporter: Fuad Efendi
> Attachments: SOLR-2233-001.patch, SOLR-2233-JdbcDataSource.patch, 
> SOLR-2233.patch, SOLR-2233.patch
>
>
> Whenever Thread A spends more than 10 seconds on a Connection (by retrieving 
> records in a batch), Thread B will close connection.
> Related exceptions happen when we use "threads=" attribute for entity; 
> usually exception stack contains message "connection already closed"
> It shouldn't happen with some JNDI data source, where Connection.close() 
> simply returns Connection to a pool of available connections, but we might 
> get different errors.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3916) Consider different query and index segmentation for Japanese

[Christian Moen (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240610#comment-13240610
 ] 

Christian Moen commented on LUCENE-3916:


Thanks a lot, Robert.

I've added a comment about about this in {{schema.xml}} as part of SOLR-3276.  
I'm resolving this issue.



> Consider different query and index segmentation for Japanese
> 
>
> Key: LUCENE-3916
> URL: https://issues.apache.org/jira/browse/LUCENE-3916
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Priority: Minor
>
> Kuromoji today uses search mode segmentation both at query and index time.
> The benefit with search mode segmentation is that it segments compounds such 
> as 関西国際空港 (Kansai International Airport) into 関西 (Kansai), 国際 
> (international), 空港 (airport), and leaves the compound 関西国際空港 as a synonym to 
> 関西.
> This segmentation allows us to get a match for 空港 (airport), which is good 
> for recall and we'd get good precision when searching for the compound 関西国際空港 
> because of IDF.
> However, if we search for the compound 関西国際空港 (Kansai International Airport) 
> our query becomes (by default) an OR-query with terms 関西 (Kansai), 関西国際空港 
> (Kansai International Airport), 国際 (international) and 空港 (airport).
> This behaviour is by-design when using OR as the default operator, but this 
> also has the effect of returning generic hits like 空港 (airport) when the user 
> searches for something very specific like 関西国際空港 (Kansai International 
> Airport) -- and these hits are also highlighted.
> This doesn't necessarily mean that ranking is flawed per se, but a user or 
> application might prefer precision over recall.  In order to favour 
> precision, we can consider using normal mode segmentation for queries, but 
> retain search mode segmentation on the indexing side.
> Does anyone have any general opinion on this?  What would we do for other 
> language in the case of compound splitting?
> Perhaps this can be dealt with as a documentation issue with a comment in 
> {{schema.xml}} while keeping the current behaviour?
> Many thanks for any input.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-3916) Consider different query and index segmentation for Japanese

[Christian Moen (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Moen resolved LUCENE-3916.


Resolution: Fixed

> Consider different query and index segmentation for Japanese
> 
>
> Key: LUCENE-3916
> URL: https://issues.apache.org/jira/browse/LUCENE-3916
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Priority: Minor
>
> Kuromoji today uses search mode segmentation both at query and index time.
> The benefit with search mode segmentation is that it segments compounds such 
> as 関西国際空港 (Kansai International Airport) into 関西 (Kansai), 国際 
> (international), 空港 (airport), and leaves the compound 関西国際空港 as a synonym to 
> 関西.
> This segmentation allows us to get a match for 空港 (airport), which is good 
> for recall and we'd get good precision when searching for the compound 関西国際空港 
> because of IDF.
> However, if we search for the compound 関西国際空港 (Kansai International Airport) 
> our query becomes (by default) an OR-query with terms 関西 (Kansai), 関西国際空港 
> (Kansai International Airport), 国際 (international) and 空港 (airport).
> This behaviour is by-design when using OR as the default operator, but this 
> also has the effect of returning generic hits like 空港 (airport) when the user 
> searches for something very specific like 関西国際空港 (Kansai International 
> Airport) -- and these hits are also highlighted.
> This doesn't necessarily mean that ranking is flawed per se, but a user or 
> application might prefer precision over recall.  In order to favour 
> precision, we can consider using normal mode segmentation for queries, but 
> retain search mode segmentation on the indexing side.
> Does anyone have any general opinion on this?  What would we do for other 
> language in the case of compound splitting?
> Perhaps this can be dealt with as a documentation issue with a comment in 
> {{schema.xml}} while keeping the current behaviour?
> Many thanks for any input.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Christian Moen (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Moen resolved SOLR-3276.
--

Resolution: Fixed

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
> Attachments: SOLR-3276.patch, SOLR-3276.patch
>
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Christian Moen (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240602#comment-13240602
 ] 

Christian Moen commented on SOLR-3276:
--

Committed revision 1306524 to {{branch_3x}}.

Thanks again for reviewing, Robert and Uwe!

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
> Attachments: SOLR-3276.patch, SOLR-3276.patch
>
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Christian Moen (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240563#comment-13240563
 ] 

Christian Moen commented on SOLR-3276:
--

Committed revision 1306476 to {{trunk}}.  Backporting to {{branch_3x}}.

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
> Attachments: SOLR-3276.patch, SOLR-3276.patch
>
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [GSoC] About how flexible indexing works in lucene 4.0

[Michael McCandless]

On Mon, Mar 26, 2012 at 6:59 PM, Han Jiang  wrote:
> Hi all,
>
> I was trying to figure out the control flow of IndexWriter and
> IndexSearcher, in order to get a better understanding of the idea behind
> Codec implementation.
>
> However, there seem to be some questions related with codes, which I just
> find inconvenient to discuss here.
>
> Maybe it is better to expain how much I understand, and ask for your
> comments?
> Here is what I understand:
>
> Index time:
> --First of all, IndexWriter should get a Codec configuration from an
> IndexWriterConfig.
> --When IndexWriter.addDocument is called, an instance of
> DocumentsWriterPerThread will be created,
> --It then pass the codec information through the indexing chain, and make an
> instance of FreqProxTermsWriterPerField to call flush().
> --Then, based on the codec information, we create an instance of
> TermsConsumer, after this, we iterator each termID, get corresponding
> PostingConsumer, and save infomation of each document.
> --Here, by inheriting "TermsConsumer" and "PostingConsumer", we get
> IndexWriter create index with new posting formats.

That sounds about right!

But, it's best to think of FreqProxTErmsWriter/PerField as having its
own "private" in-memory postings format, and then, on flush, it
re-parses its in-memory postings and feeds them to the codec
(Fields/Terms/PostingsConsumer) for writing to the index.

> Query time:
> --Now, let's take Phrase Search as an example.
> --When IndexSearcher.search(phraseQuery,topN) is called, an instance of
> PhraseWeight will be created to wrap the query terms,
> --Then, IndexSearcher will create tasks to call method
> PhraseWeight.scorer(), inside which two instances: Terms and TermsEnum will
> be fetched from corresponding AtomicReader,
> --With the help of TermsEnum, for every phrase words, related docs and
> positions will be fetched through a DocsAndPositionsEnum, and result thus be
> generated.
> --Here, by inheriting "TermsEnum" and related "*Enum" classes, we get
> IndexSearcher(or IndexReader) understand our posting formats.

Sounds right!

> And, here I have some questions:
>
> 1. Will multiple AtomicReaders created if I operate a search on a index with
> several segments? If not, when will there be multi AtomicReaders? And to
> further the question,  what is the idea to introduce AtomicReader and
> CompositeReader into lucene 4?

Right, it's one atomic reader (SegmentReader) per segment.

We split composite/atomic readers in 4.0 so they'd be strongly typed
(they have different methods and before the split they'd throw
UnsupportedOperationExceptions from a number of methods, which was
messy).

> 2. I must have missed something during query time, since subtype of
> PostingsReaderBase is just absent from what I explained. Is it created when
> an instance of AtomicReader is fetch from context? Where can I find related
> codes?

PostingsWriter/ReaderBase is what our default terms dictionaries
(Block/TreeTermsWriter/Reader) interact with.

So, eg the Lucene40PostingsWriter/Reader subclass PostingsWriter/ReaderBase.

> 3. The wiki page here  says we should provide an arbitrary skipDocs bit set
> during enumeration. Then, is posting list itself remains unchanged, even if
> I call deleteDocuments() ? Will deleted documents still remain in the
> postings file, even segments get merged?

Deleted docs are simply marked in a bit set (the liveDocs bits), and
the postings files themselves are unchanged.

So when the postings reader enumerates the postings, it must checked
the provided live docs (if it's not null) to confirm the doc is not
deleted.

Mike

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Christian Moen (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240551#comment-13240551
 ] 

Christian Moen commented on SOLR-3276:
--

I'll commit this shortly.

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
> Attachments: SOLR-3276.patch, SOLR-3276.patch
>
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Compiling JCC as shared object

[Caleb Burns]

My version of setuptools is 0.6.15-1ubuntu1

patch.43.0.6c11 fails on Hunk #1:

sudo patch -d /usr/lib/python2.7/dist-packages -Nup0 <
/home/caleb/Exclude/Downloads/pylucene-3.4.0-1/jcc/jcc/patches/patch.43.0.6c11
patching file setuptools/extension.py
patching file setuptools/command/build_ext.py
Hunk #1 FAILED at 85.
Hunk #2 succeeded at 177 (offset 7 lines).
Hunk #3 succeeded at 259 (offset 7 lines).
1 out of 3 hunks FAILED -- saving rejects to file
setuptools/command/build_ext.py.rej

patch.43.0.6c7 succeeds:

sudo patch -d /usr/lib/python2.7/dist-packages -Nup0 <
/home/caleb/Exclude/Downloads/pylucene-3.4.0-1/jcc/jcc/patches/patch.43.0.6c7
patching file setuptools/extension.py
patching file setuptools/command/build_ext.py
Hunk #1 succeeded at 86 with fuzz 1 (offset 2 lines).
Hunk #2 succeeded at 181 (offset 7 lines).
Hunk #3 succeeded at 263 (offset 7 lines).

NOTE: Each after reinstalls of setuptools.

On Wed, Mar 28, 2012 at 12:57 PM, Andi Vajda  wrote:

>
> On Wed, 28 Mar 2012, Caleb Burns wrote:
>
>  According to
>> http://lucene.apache.org/**pylucene/jcc/install#shared_**
>> mode_support_for_the_code--**sharedcode_flag
>> (or
>> doc/jcc/documentation/install.**html#shared from pylucene tarball), I
>> can set
>> the `--shared` flag in order to compile JCC as a shared object instead of
>> a
>> static one. There's also mention about applying a patch to setuptools on
>> Linux (I'm running Ubuntu 11.04). I'm confused as to how exactly one is
>> supposed to do this.
>>
>> If I run `python setup.py build` from "jcc/" I'm greeted with a message
>> saying shared mode is disabled and setuptools patch.43.0.6c11 must be
>> applied to enable it. So I apply the patch with the friendly help from the
>> displayed message: `sudo patch -d /usr/lib/python2.7/dist-**packages
>> -Nup0 <
>> /home/caleb/Exclude/Downloads/**pylucene-3.4.0-1/jcc/jcc/**
>> patches/patch.43.0.6c11`.
>> Then if I try to build again with `python setup.py build`, it builds
>> successfully but I get "libjcc.a" under "jcc/build/lib.linux-x86_64-2.**
>> 7/"
>> instead of "libjcc.so". If I pass `--shared` to `python setup.py build` I
>> simply get "error: option --shared not recognized". If I apply
>> "patch.43.0.6c7" instead of "patch.43.0.6c11" on a fresh reinstall of
>> setuptools and then build with `python setup.py build`, the resulting
>> build
>> has "libjcc.so" instead of "libjcc.a". Is this supposed to work this way?
>> Where is the `--shared` flag involved? And why does `setup.py` say to
>> use "patch.43.0.6c11" to enabled shared mode when only "patch.43.0.6c7"
>> seems to enable it?
>>
>
> The suggested patch version is figured out from the version of setuptools
> you have. If you have a setuptools version < 0.6c11, it suggests you use
> patch.43.0.6c7, otherwise patch.43.0.6c11. If a new version of setuptools
> appeared that breaks this logic or were to need a new patch, all bets are
> off, of course.
>
> What version of setuptools do you have installed ?
> Did the patch patch.43.0.6c7 install cleanly ?
>
> Andi..
>
>  The reason I'm asking is because I working on a Python C++ module for
>> performing quick calculations that interacts with Lucene (specifically
>> PyLucene).
>>
>>
>> --
>> Caleb Burns
>> Developer | Riders Discount
>> 866.931.6644 x851 | www.RidersDiscount.com > com/ >
>> [image: image.png] 
>> >
>> [image:
>> image.png] 
>> 
>> >
>> Deal of the Day 
>> 
>> >
>>
>>

Re: Compiling JCC as shared object

[Andi Vajda]

On Wed, 28 Mar 2012, Caleb Burns wrote:


According to
http://lucene.apache.org/pylucene/jcc/install#shared_mode_support_for_the_code--sharedcode_flag
(or
doc/jcc/documentation/install.html#shared from pylucene tarball), I can set
the `--shared` flag in order to compile JCC as a shared object instead of a
static one. There's also mention about applying a patch to setuptools on
Linux (I'm running Ubuntu 11.04). I'm confused as to how exactly one is
supposed to do this.

If I run `python setup.py build` from "jcc/" I'm greeted with a message
saying shared mode is disabled and setuptools patch.43.0.6c11 must be
applied to enable it. So I apply the patch with the friendly help from the
displayed message: `sudo patch -d /usr/lib/python2.7/dist-packages -Nup0 <
/home/caleb/Exclude/Downloads/pylucene-3.4.0-1/jcc/jcc/patches/patch.43.0.6c11`.
Then if I try to build again with `python setup.py build`, it builds
successfully but I get "libjcc.a" under "jcc/build/lib.linux-x86_64-2.7/"
instead of "libjcc.so". If I pass `--shared` to `python setup.py build` I
simply get "error: option --shared not recognized". If I apply
"patch.43.0.6c7" instead of "patch.43.0.6c11" on a fresh reinstall of
setuptools and then build with `python setup.py build`, the resulting build
has "libjcc.so" instead of "libjcc.a". Is this supposed to work this way?
Where is the `--shared` flag involved? And why does `setup.py` say to
use "patch.43.0.6c11" to enabled shared mode when only "patch.43.0.6c7"
seems to enable it?


The suggested patch version is figured out from the version of setuptools 
you have. If you have a setuptools version < 0.6c11, it suggests you use
patch.43.0.6c7, otherwise patch.43.0.6c11. If a new version of setuptools 
appeared that breaks this logic or were to need a new patch, all bets are 
off, of course.


What version of setuptools do you have installed ?
Did the patch patch.43.0.6c7 install cleanly ?

Andi..


The reason I'm asking is because I working on a Python C++ module for
performing quick calculations that interacts with Lucene (specifically
PyLucene).


--
Caleb Burns
Developer | Riders Discount
866.931.6644 x851 | www.RidersDiscount.com 
[image: image.png]  [image:
image.png] 
Deal of the Day 

[jira] [Commented] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Christian Moen (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240534#comment-13240534
 ] 

Christian Moen commented on SOLR-3276:
--

Thanks a lot, Robert and Uwe!

This is a summary of the changes:

* Improvements to {{schema.xml}}
** Improved description of {{text_ja}} and {{JapaneseAnalyzer}} to explain 
synonym compounds
** Added a brief description of user dictionaries and a commented out sample 
tokenizer entry
** Added a mention on using different segmentation modes for index and query, 
but no elaborate config
** Added a wiki reference to the Japanese language support (currently a 
placeholder)
* Fixed user dictionary attribute naming conventions for 
{{JapaneseTokenizerFactory}}.  Attributes are now {{userDictionary}} and 
{{userDictionaryEncoding}} (was {{user-dictionary}} and 
{{user-ictionary-encoding}}
* Added a sample user dictionary file to 
{{solr/example/solr/conf/lang/userdict_ja.txt}} with format details, which is 
referenced from the commented out example in {{schema.xml}}.
* Changed Kuromoji to Japanese naming in {{stopwords.txt}} and 
{{stoptags.txt}}.  (Need a {{sync-analyzers}} in {{solr}} prior to commit)
* Replaced a one-liner of code, I've changed a {{System.out.println}} in 
{{UserDictionary}} to throw a {{RuntimeException}} with a proper error message 
in case user dictionary parsing fails, and tested this manually. 

If you claim that there's been some scope-creep in this patch, I can't argue 
with that. :)  

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
> Attachments: SOLR-3276.patch, SOLR-3276.patch
>
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Christian Moen (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240533#comment-13240533
 ] 

Christian Moen commented on SOLR-3276:
--

Fixed a typo.

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
> Attachments: SOLR-3276.patch, SOLR-3276.patch
>
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Christian Moen (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Moen updated SOLR-3276:
-

Attachment: SOLR-3276.patch

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
> Attachments: SOLR-3276.patch, SOLR-3276.patch
>
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3892) Add a useful intblock postings format (eg, FOR, PFOR, PFORDelta, Simple9/16/64, etc.)

[Michael McCandless (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240527#comment-13240527
 ] 

Michael McCandless commented on LUCENE-3892:


That's great Han, I'll have a look.

I can be a mentor for this...

> Add a useful intblock postings format (eg, FOR, PFOR, PFORDelta, 
> Simple9/16/64, etc.)
> -
>
> Key: LUCENE-3892
> URL: https://issues.apache.org/jira/browse/LUCENE-3892
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Michael McCandless
>  Labels: gsoc2012, lucene-gsoc-12
> Fix For: 4.0
>
>
> On the flex branch we explored a number of possible intblock
> encodings, but for whatever reason never brought them to completion.
> There are still a number of issues opened with patches in different
> states.
> Initial results (based on prototype) were excellent (see
> http://blog.mikemccandless.com/2010/08/lucene-performance-with-pfordelta-codec.html
> ).
> I think this would make a good GSoC project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3291) Update "ant run-example" JVM debugging command-line switches

[Erik Hatcher (Created) (JIRA)]

Update "ant run-example" JVM debugging command-line switches


 Key: SOLR-3291
 URL: https://issues.apache.org/jira/browse/SOLR-3291
 Project: Solr
  Issue Type: Improvement
Reporter: Erik Hatcher


Our current run-example target uses {code}-Xdebug 
-Xrunjdwp:transport=dt_socket,server=y,suspend=${example.debug.suspend},address=5005{code}

but I've heard that it can be done without -X arguments like this 

{code}-agentlib:jdwp=transport=dt_socket,address=localhost:9009,server=y,suspend=y{code}

What's the most up-to-date best way to enable JVM debugging?  Are changes 
warranted?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3291) Update "ant run-example" JVM debugging command-line switches

[Erik Hatcher (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erik Hatcher updated SOLR-3291:
---

Fix Version/s: 4.0

> Update "ant run-example" JVM debugging command-line switches
> 
>
> Key: SOLR-3291
> URL: https://issues.apache.org/jira/browse/SOLR-3291
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erik Hatcher
> Fix For: 4.0
>
>
> Our current run-example target uses {code}-Xdebug 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=${example.debug.suspend},address=5005{code}
> but I've heard that it can be done without -X arguments like this 
> {code}-agentlib:jdwp=transport=dt_socket,address=localhost:9009,server=y,suspend=y{code}
> What's the most up-to-date best way to enable JVM debugging?  Are changes 
> warranted?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Uwe Schindler (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240526#comment-13240526
 ] 

Uwe Schindler commented on SOLR-3276:
-

looks good! Die, System.out, die! The new attributes are more "xml-compatible".

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
> Attachments: SOLR-3276.patch
>
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Robert Muir (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240523#comment-13240523
 ] 

Robert Muir commented on SOLR-3276:
---

patch looks good. thanks for catching all this stuff.

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
> Attachments: SOLR-3276.patch
>
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Compiling JCC as shared object

[Caleb Burns]

According to
http://lucene.apache.org/pylucene/jcc/install#shared_mode_support_for_the_code--sharedcode_flag
(or
doc/jcc/documentation/install.html#shared from pylucene tarball), I can set
the `--shared` flag in order to compile JCC as a shared object instead of a
static one. There's also mention about applying a patch to setuptools on
Linux (I'm running Ubuntu 11.04). I'm confused as to how exactly one is
supposed to do this.

If I run `python setup.py build` from "jcc/" I'm greeted with a message
saying shared mode is disabled and setuptools patch.43.0.6c11 must be
applied to enable it. So I apply the patch with the friendly help from the
displayed message: `sudo patch -d /usr/lib/python2.7/dist-packages -Nup0 <
/home/caleb/Exclude/Downloads/pylucene-3.4.0-1/jcc/jcc/patches/patch.43.0.6c11`.
Then if I try to build again with `python setup.py build`, it builds
successfully but I get "libjcc.a" under "jcc/build/lib.linux-x86_64-2.7/"
instead of "libjcc.so". If I pass `--shared` to `python setup.py build` I
simply get "error: option --shared not recognized". If I apply
"patch.43.0.6c7" instead of "patch.43.0.6c11" on a fresh reinstall of
setuptools and then build with `python setup.py build`, the resulting build
has "libjcc.so" instead of "libjcc.a". Is this supposed to work this way?
Where is the `--shared` flag involved? And why does `setup.py` say to
use "patch.43.0.6c11" to enabled shared mode when only "patch.43.0.6c7"
seems to enable it?

The reason I'm asking is because I working on a Python C++ module for
performing quick calculations that interacts with Lucene (specifically
PyLucene).


-- 
Caleb Burns
Developer | Riders Discount
866.931.6644 x851 | www.RidersDiscount.com 
[image: image.png]  [image:
image.png] 
Deal of the Day 

[jira] [Commented] (SOLR-3283) PingRequestHandler should have qt be optional

[Mark Miller (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240518#comment-13240518
 ] 

Mark Miller commented on SOLR-3283:
---

bq. It didn't seem worth a CHANGES.txt entry.

I think even small improvements should probably have a CHANGES entry.

Didn't revert due to that though - the 3 other commits done around this one 
caused many test failures.

> PingRequestHandler should have qt be optional
> -
>
> Key: SOLR-3283
> URL: https://issues.apache.org/jira/browse/SOLR-3283
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 3.6, 4.0
>
> Attachments: SOLR-3283_PingRequestHandler_make_qt_optional.patch
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> PingRequestHandler insists that "qt" be specified for its query.  I think it 
> should be optional since the default request handler can be looked up via 
> null.  QuerySenderListener doesn't mandate qt for the same reason.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Christian Moen (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Moen updated SOLR-3276:
-

Attachment: SOLR-3276.patch

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
> Attachments: SOLR-3276.patch
>
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2698) Enhance CoreAdmin STATUS command to return index size

[Yury Kats (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240499#comment-13240499
 ] 

Yury Kats commented on SOLR-2698:
-

To clarify, this is already fixed in 4.0. The bug was re-opened for a potential 
backport to 3.x.

> Enhance CoreAdmin STATUS command to return index size
> -
>
> Key: SOLR-2698
> URL: https://issues.apache.org/jira/browse/SOLR-2698
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore
>Affects Versions: 4.0
>Reporter: Yury Kats
>Assignee: Mark Miller
> Fix For: 4.0
>
> Attachments: SOLR-2698.patch, SOLR-2698.patch
>
>
> CoreAdmin STATUS command returns all kinds of index info for all cores on the 
> server, except for the index size.
> However, indexSize can be retrieved for an individual core via a 
> /replication&command=details request.
> I have N Solrs servers, running M cores each. My application is monitoring 
> the status of all cores, including their index size.
> As it stands today, I need to issue N status requests plus N*M replication 
> requests to get all the information I need.
> If STATUS command returned indexSize, number of requests would be just N.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2698) Enhance CoreAdmin STATUS command to return index size

[Jason Rutherglen (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240498#comment-13240498
 ] 

Jason Rutherglen commented on SOLR-2698:


+1 This'd be useful.

> Enhance CoreAdmin STATUS command to return index size
> -
>
> Key: SOLR-2698
> URL: https://issues.apache.org/jira/browse/SOLR-2698
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore
>Affects Versions: 4.0
>Reporter: Yury Kats
>Assignee: Mark Miller
> Fix For: 4.0
>
> Attachments: SOLR-2698.patch, SOLR-2698.patch
>
>
> CoreAdmin STATUS command returns all kinds of index info for all cores on the 
> server, except for the index size.
> However, indexSize can be retrieved for an individual core via a 
> /replication&command=details request.
> I have N Solrs servers, running M cores each. My application is monitoring 
> the status of all cores, including their index size.
> As it stands today, I need to issue N status requests plus N*M replication 
> requests to get all the information I need.
> If STATUS command returned indexSize, number of requests would be just N.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3290) Geocoding lookup for spatial search

[Chris A. Mattmann (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240456#comment-13240456
 ] 

Chris A. Mattmann commented on SOLR-3290:
-

Take a look here: http://github.com/chrismattmann/solrcene for a list of 
patches that my student and I did to Lucene and Solr way back when (patches 
that are included and unapplied in JIRA here) to implement this.

> Geocoding lookup for spatial search
> ---
>
> Key: SOLR-3290
> URL: https://issues.apache.org/jira/browse/SOLR-3290
> Project: Solr
>  Issue Type: New Feature
>  Components: query parsers
>Reporter: D Roser
>
> Hi,
> for searching locations "nearby" a address it would be a great enhancement to 
> have a geocoding lookup through a webservice (like google geocoding,...) 
> which results (lat long) can be used for spatial search.
> e.g.
> ?q=party&nearby=street+123,+city

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2092 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2092/

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest

Error Message:
ERROR: SolrIndexSearcher opens=91 closes=90

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=91 
closes=90
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner$3.addError(JUnitTestRunner.java:974)
at junit.framework.TestResult.addError(TestResult.java:38)
at 
junit.framework.JUnit4TestAdapterCache$1.testFailure(JUnit4TestAdapterCache.java:51)
at 
org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100)
at 
org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41)
at 
org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97)
at 
org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:306)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
Caused by: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=91 closes=90
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:211)
at 
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
... 4 more




Build Log (for compile errors):
[...truncated 9946 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [jira] [Created] (SOLR-3290) Geocoding lookup for spatial search

[Bill Bell]

Most geocoders have very restricted licenses.

Bill Bell
Sent from mobile


On Mar 28, 2012, at 6:36 AM, "D Roser (Created) (JIRA)"  wrote:

> Geocoding lookup for spatial search
> ---
> 
> Key: SOLR-3290
> URL: https://issues.apache.org/jira/browse/SOLR-3290
> Project: Solr
>  Issue Type: New Feature
>  Components: query parsers
>Reporter: D Roser
> 
> 
> Hi,
> for searching locations "nearby" a address it would be a great enhancement to 
> have a geocoding lookup through a webservice (like google geocoding,...) 
> which results (lat long) can be used for spatial search.
> 
> e.g.
> 
> ?q=party&nearby=street+123,+city
> 
> 
> 
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA 
> administrators: 
> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> 
> 
> 
> -
> 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: 3.6 status update

[Steven A Rowe]

Thanks, Robert (and Uwe and Chris), for finding a way to make things work. - 
Steve

-Original Message-
From: Robert Muir [mailto:rcm...@gmail.com] 
Sent: Wednesday, March 28, 2012 10:01 AM
To: dev@lucene.apache.org
Subject: 3.6 status update

Hello,

as alluded to on the 'replace jars with ivy' thread, there is a discussion 
currently going on, in another list:
http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3CCAOFYJNY%3DEjVHrWVvAedR3OKwCv-BkTaCbEu0ufp7OZR_gpCTiA%40mail.gmail.com%3E

the situation looks grim: there is talk of deleting past releases and things 
like that, so because of that, I think its necessary to fix this for 3.6 even 
if it turns out not to be absolutely necessary for 3.6, i'd much rather spend 
my time with technicals than arguing over this crap on mailing lists anyway.

its a shame, since our packaging is stable and we have been doing a lot of 
testing the last few weeks, before this thread I was planning on creating the 
first release candidate today.
but I think either way this situation will delay the release, so let's just do 
it right.

I set https://issues.apache.org/jira/browse/LUCENE-3930 as blocker. I imagine 
it will take some time to sort this out and re-test everything, delaying the RC.
Thanks for your patience! If you want to help you can investigate the jira 
issue (https://issues.apache.org/jira/browse/LUCENE-3930), look at the branch 
(https://svn.apache.org/repos/asf/lucene/dev/branches/lucene3930)
and review things, or of course just do the usual inspections and tests on 
branch_3x, which we definitely still need even with this distraction.

Thanks,
Robert

--
lucidimagination.com

-
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

3.6 status update

[Robert Muir]

Hello,

as alluded to on the 'replace jars with ivy' thread, there is a
discussion currently going on, in another list:
http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3CCAOFYJNY%3DEjVHrWVvAedR3OKwCv-BkTaCbEu0ufp7OZR_gpCTiA%40mail.gmail.com%3E

the situation looks grim: there is talk of deleting past releases and
things like that, so because of that, I think its necessary to fix
this for 3.6
even if it turns out not to be absolutely necessary for 3.6, i'd much
rather spend my time with technicals than arguing over this crap on
mailing lists anyway.

its a shame, since our packaging is stable and we have been doing a
lot of testing the last few weeks, before this thread I was planning
on creating the first release candidate today.
but I think either way this situation will delay the release, so let's
just do it right.

I set https://issues.apache.org/jira/browse/LUCENE-3930 as blocker. I
imagine it will take some time to sort this out and re-test
everything, delaying the RC.
Thanks for your patience! If you want to help you can investigate the
jira issue (https://issues.apache.org/jira/browse/LUCENE-3930), look
at the branch (https://svn.apache.org/repos/asf/lucene/dev/branches/lucene3930)
and review things, or of course just do the usual inspections and
tests on branch_3x, which we definitely still need even with this
distraction.

Thanks,
Robert

-- 
lucidimagination.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

[Mark Miller (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240421#comment-13240421
 ] 

Mark Miller commented on SOLR-3161:
---

Reverted on 4x - tests fail.

> Use of 'qt' should be restricted to searching and should not start with a '/'
> -
>
> Key: SOLR-3161
> URL: https://issues.apache.org/jira/browse/SOLR-3161
> Project: Solr
>  Issue Type: Improvement
>  Components: search, web gui
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 4.0
>
> Attachments: SOLR-3161-disable-qt-by-default.patch, 
> SOLR-3161-dispatching-request-handler.patch, 
> SOLR-3161-dispatching-request-handler.patch, 
> SOLR-3161_limit_qt=_to_refer_to_SearchHandlers,_and_shards_qt_likewise.patch,
>  SOLR-3161_make_the_slash-select_request_handler_the_default.patch
>
>
> I haven't yet looked at the code involved for suggestions here; I'm speaking 
> based on how I think things should work and not work, based on intuitiveness 
> and security. In general I feel it is best practice to use '/' leading 
> request handler names and not use "qt", but I don't hate it enough when used 
> in limited (search-only) circumstances to propose its demise. But if someone 
> proposes its deprecation that then I am +1 for that.
> Here is my proposal:
> Solr should error if the parameter "qt" is supplied with a leading '/'. 
> (trunk only)
> Solr should only honor "qt" if the target request handler extends 
> solr.SearchHandler.
> The new admin UI should only use 'qt' when it has to. For the query screen, 
> it could present a little pop-up menu of handlers to choose from, including 
> "/select?qt=mycustom" for handlers that aren't named with a leading '/'. This 
> choice should be positioned at the top.
> And before I forget, me or someone should investigate if there are any 
> similar security problems with the shards.qt parameter. Perhaps shards.qt can 
> abide by the same rules outlined above.
> Does anyone foresee any problems with this proposal?
> On a related subject, I think the notion of a default request handler is bad 
> - the default="true" thing. Honestly I'm not sure what it does, since I 
> noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. 
> Assuming it doesn't do anything useful anymore, I think it would be clearer 
> to use  instead of 
> what's there now. The delta is to put the leading '/' on this request handler 
> name, and remove the "default" attribute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Reopened] (SOLR-3283) PingRequestHandler should have qt be optional

[Mark Miller (Reopened) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller reopened SOLR-3283:
---


Reverted on 4x

> PingRequestHandler should have qt be optional
> -
>
> Key: SOLR-3283
> URL: https://issues.apache.org/jira/browse/SOLR-3283
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 3.6, 4.0
>
> Attachments: SOLR-3283_PingRequestHandler_make_qt_optional.patch
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> PingRequestHandler insists that "qt" be specified for its query.  I think it 
> should be optional since the default request handler can be looked up via 
> null.  QuerySenderListener doesn't mandate qt for the same reason.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Reopened] (SOLR-435) QParser must validate existence/absence of "q" parameter

[Mark Miller (Reopened) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller reopened SOLR-435:
--


Reverted on 4x

> QParser must validate existence/absence of "q" parameter
> 
>
> Key: SOLR-435
> URL: https://issues.apache.org/jira/browse/SOLR-435
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 1.3
>Reporter: Ryan McKinley
>Assignee: David Smiley
> Fix For: 3.6, 4.0
>
> Attachments: 
> SOLR-2001_3x_backport_with_empty_string_check_and_test.patch, SOLR-435.patch, 
> SOLR-435_3x_consistent_errors.patch, SOLR-435_q_defaults_to_all-docs.patch
>
>
> Each QParser should check if "q" exists or not.  For some it will be required 
> others not.
> currently it throws a null pointer:
> {code}
> java.lang.NullPointerException
>   at org.apache.solr.common.util.StrUtils.splitSmart(StrUtils.java:36)
>   at 
> org.apache.solr.search.OldLuceneQParser.parse(LuceneQParserPlugin.java:104)
>   at org.apache.solr.search.QParser.getQuery(QParser.java:80)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:67)
>   at 
> org.apache.solr.handler.SearchHandler.handleRequestBody(SearchHandler.java:150)
> ...
> {code}
> see:
> http://www.nabble.com/query-parsing-error-to14124285.html#a14140108

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Reopened] (SOLR-2724) Deprecate defaultSearchField and defaultOperator defined in schema.xml

[Mark Miller (Reopened) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller reopened SOLR-2724:
---


Reverted on 4x

> Deprecate defaultSearchField and defaultOperator defined in schema.xml
> --
>
> Key: SOLR-2724
> URL: https://issues.apache.org/jira/browse/SOLR-2724
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis, search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 3.6, 4.0
>
> Attachments: 
> SOLR-2724_deprecateDefaultSearchField_and_defaultOperator.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I've always been surprised to see the  element and 
>  defined in the schema.xml file since 
> the first time I saw them.  They just seem out of place to me since they are 
> more query parser related than schema related. But not only are they 
> misplaced, I feel they shouldn't exist. For query parsers, we already have a 
> "df" parameter that works just fine, and explicit field references. And the 
> default lucene query operator should stay at OR -- if a particular query 
> wants different behavior then use q.op or simply use "OR".
>  Seems like something better placed in solrconfig.xml than in the 
> schema. 
> In my opinion, defaultSearchField and defaultOperator configuration elements 
> should be deprecated in Solr 3.x and removed in Solr 4.  And  
> should move to solrconfig.xml. I am willing to do it, provided there is 
> consensus on it of course.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Issue Comment Edited] (LUCENE-3892) Add a useful intblock postings format (eg, FOR, PFOR, PFORDelta, Simple9/16/64, etc.)

[Han Jiang (Issue Comment Edited) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240403#comment-13240403
 ] 

Han Jiang edited comment on LUCENE-3892 at 3/28/12 1:50 PM:


Hi, 
I have submitted my proposal. Comments are welcome!
Also, I made it public: 
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/billybob/1

  was (Author: billy):
Hi, I have submitted my proposal. Comments are welcome!
  
> Add a useful intblock postings format (eg, FOR, PFOR, PFORDelta, 
> Simple9/16/64, etc.)
> -
>
> Key: LUCENE-3892
> URL: https://issues.apache.org/jira/browse/LUCENE-3892
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Michael McCandless
>  Labels: gsoc2012, lucene-gsoc-12
> Fix For: 4.0
>
>
> On the flex branch we explored a number of possible intblock
> encodings, but for whatever reason never brought them to completion.
> There are still a number of issues opened with patches in different
> states.
> Initial results (based on prototype) were excellent (see
> http://blog.mikemccandless.com/2010/08/lucene-performance-with-pfordelta-codec.html
> ).
> I think this would make a good GSoC project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Issue Comment Edited] (SOLR-3272) Solr filter factory for MorfologikFilter

[Steven Rowe (Issue Comment Edited) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240032#comment-13240032
 ] 

Steven Rowe edited comment on SOLR-3272 at 3/28/12 1:45 PM:


bq. where is the code that copies these JARs to solr?

The {{dist}} target in {{solr/webapp/build.xml}} depends on 
{{lucene-jars-to-solr}} in {{solr/common-build.xml}}, which makes sure that 
lucene .jar dependencies are built (via {{prep-lucene-jars}}), and then copies 
them to {{solr/build/lucene-libs/}}, the contents of which are then packaged 
into the .war.  Dawid, I think this is where you want to make changes.

More packaging details:

The {{dist}} target in {{solr/webapp/build.xml}} also runs the 
{{contribs-add-to-war}} target from {{solr/common-build.xml}}, which invokes 
{{add-to-war}} in each Solr contrib that has a {{src/webapp/}} directory 
(currently only DIH) to copy the contents of {{src/webapp/}} to 
{{solr/build/web/}}, the contents of which are then packaged into the .war.

Lastly, the {{create-package}} target in {{solr/build.xml}} depends on the 
{{dist}} target, which depends on the {{dist-contrib}} target, which invokes 
{{dist}} in each Solr contrib.  Solr contribs that want to include lucene .jar 
dependencies in the Solr distribution (but not the .war) have their {{dist}} 
targets populate {{solr/build/contrib//lucene-libs/}} with those 
.jars.  The {{create-package}} target then invokes 
{{add-lucene-libs-to-package}} in each Solr contrib, which copies the contents 
of {{solr/build/contrib//lucene-libs/}} to 
{{solr/build/contrib-lucene-libs-to-package/contrib//}}.  
Finally, the distributions (tarball/zip) include the contents of 
{{solr/build/contrib-lucene-libs-to-package/}}.  

Wow, that last part is way more complex than it needs to be.  (And it's totally 
my fault :( )

Before Robert and I rewrote the Solr build, the top-level Solr build file was 
*huge*.  One of the guiding principles I used was "keep build configuration 
local".  Now individual modules handle the details that only concern them.  
Coordination among modules, as seen in the above packaging description, remains 
a challenge...


  was (Author: steve_rowe):
bq. where is the code that copies these JARs to solr?

The {{dist}} target in {{solr/webapp/build.xml}} depends on 
{{lucene-jars-to-solr}} in {{solr/common-build.xml}}, which makes sure that 
lucene .jar dependencies are built (via {{prep-lucene-jars}}), and then copies 
them to {{solr/build/lucene-libs/}}, the contents of which are then packaged 
into the .war.  Dawid, I think this is where you want to make changes.

More packaging details:

The {{dist}} target in {{solr/webapp/build.xml}} also runs the 
{{contribs-add-to-war}} target from {{solr/common-build.xml}}, which invokes 
{{add-to-war}} in each Solr contrib that has a {{src/webapp/}} directory 
(currently only DIH) to copy the contents of {{src/webapp/}} to 
{{solr/build/web/}}, the contents of which are then packaged into the .war.

Lastly, the {{create-package}} target in {{solr/build.xml}} depends on the 
{{dist}} target, which depends on the {{dist-contrib}} target, which invokes 
{{dist}} in each Solr contrib.  Solr contribs that want to include lucene .jar 
dependencies in the Solr distribution (but not the .war) have their {{dist}} 
targets populate {{solr/build/contrib//lucene-libs/}} with those 
.jars.  The {{create-package}} target then invokes 
{{add-lucene-libs-to-package}} in each Solr contrib, which copies the contents 
of {{solr/build/contrib//lucene-libs/}} to 
{{solr/build/contrib-lucene-libs-to-package/contrib//}}.  
Finally, the .war incorporates the contents of 
{{solr/build/contrib-lucene-libs-to-package/}}.  

Wow, that last part is way more complex than it needs to be.  (And it's totally 
my fault :( )

Before Robert and I rewrote the Solr build, the top-level Solr build file was 
*huge*.  One of the guiding principles I used was "keep build configuration 
local".  Now individual modules handle the details that only concern them.  
Coordination among modules, as seen in the above packaging description, remains 
a challenge...

  
> Solr filter factory for MorfologikFilter
> 
>
> Key: SOLR-3272
> URL: https://issues.apache.org/jira/browse/SOLR-3272
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Affects Versions: 4.0
>Reporter: Rafał Kuć
>Assignee: Dawid Weiss
> Fix For: 4.0
>
> Attachments: SOLR-3272-toupper-correction.patch, 
> SOLR-3272-with-javadoc-example-usage.patch, SOLR-3272.patch, SOLR-3272.patch, 
> SOLR-3272.patch, SOLR-3727-new.patch
>
>
> I didn't find MorfologikFilter factory in Solr, so here is a simple. Maybe 
> someone will have make use of it :)

--

[jira] [Commented] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Robert Muir (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240409#comment-13240409
 ] 

Robert Muir commented on SOLR-3276:
---

I'll review your patch when its ready, but conceptually I don't see any issue 
with this.

I don't have any issue at all with documentation, test, or bug fixes. We 
shouldn't be
adding any new features at this point though.

Just mark any issues you find like this as blocker and give extra time to 
review since we are in freeze.

Its definitely helpful to be finding and fixing this stuff *before* the release 
candidate
because it saves us all time.

Thanks!

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3276) Fix attribute conventions for JapaneseTokenizerFactory and add important information to schema.xml

[Christian Moen (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Moen updated SOLR-3276:
-

Description: 
The description of the {{ja_text}} field type in {{schema.xml}} is incomplete, 
doesn't describe user dictionaries and lacks a reference to the wiki page with 
extensive Japanese language support details 
([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
placeholder page).

The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
with the standards and used {{user-dictionary}} and 
{{user-dictionary-encoding}} instead of {{userDictionary}} and 
{{userDictionaryEncoding}}.

These changes are low risk and it would be a shame to not get this right in 3.6 
with all the work done on Japanese.

Patch coming up shortly.  I really hope it's okay to commit this.

  was:
Searching Japanese text is a big topic with many considerations that need to be 
made.  I think it's helpful to add a link to the wiki in a comment near 
{{text_ja}} in {{scheme.xml}} to guide users to detailed information on 
features available, how to use them, etc.

I've made a placeholder page on 
[http://wiki.apache.org/solr/JapaneseLanguageSupport] and I'll add details 
post-release.


   Priority: Blocker  (was: Major)
Summary: Fix attribute conventions for JapaneseTokenizerFactory and add 
important information to schema.xml  (was: Fix attribute conventions for 
ja_text in schema.xml and provide useful info)

> Fix attribute conventions for JapaneseTokenizerFactory and add important 
> information to schema.xml
> --
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>Priority: Blocker
>
> The description of the {{ja_text}} field type in {{schema.xml}} is 
> incomplete, doesn't describe user dictionaries and lacks a reference to the 
> wiki page with extensive Japanese language support details 
> ([http://wiki.apache.org/solr/JapaneseLanguageSupport] - currently a 
> placeholder page).
> The attribute convention used by {{JapaneseTokenizerFactory}} doesn't comply 
> with the standards and used {{user-dictionary}} and 
> {{user-dictionary-encoding}} instead of {{userDictionary}} and 
> {{userDictionaryEncoding}}.
> These changes are low risk and it would be a shame to not get this right in 
> 3.6 with all the work done on Japanese.
> Patch coming up shortly.  I really hope it's okay to commit this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3892) Add a useful intblock postings format (eg, FOR, PFOR, PFORDelta, Simple9/16/64, etc.)

[Han Jiang (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240403#comment-13240403
 ] 

Han Jiang commented on LUCENE-3892:
---

Hi, I have submitted my proposal. Comments are welcome!

> Add a useful intblock postings format (eg, FOR, PFOR, PFORDelta, 
> Simple9/16/64, etc.)
> -
>
> Key: LUCENE-3892
> URL: https://issues.apache.org/jira/browse/LUCENE-3892
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Michael McCandless
>  Labels: gsoc2012, lucene-gsoc-12
> Fix For: 4.0
>
>
> On the flex branch we explored a number of possible intblock
> encodings, but for whatever reason never brought them to completion.
> There are still a number of issues opened with patches in different
> states.
> Initial results (based on prototype) were excellent (see
> http://blog.mikemccandless.com/2010/08/lucene-performance-with-pfordelta-codec.html
> ).
> I think this would make a good GSoC project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3276) Fix attribute conventions for ja_text in schema.xml and provide useful info

[Christian Moen (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Moen updated SOLR-3276:
-

Summary: Fix attribute conventions for ja_text in schema.xml and provide 
useful info  (was: Update ja_text entry in schema.xml with useful info)

> Fix attribute conventions for ja_text in schema.xml and provide useful info
> ---
>
> Key: SOLR-3276
> URL: https://issues.apache.org/jira/browse/SOLR-3276
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.6, 4.0
>Reporter: Christian Moen
>Assignee: Christian Moen
>
> Searching Japanese text is a big topic with many considerations that need to 
> be made.  I think it's helpful to add a link to the wiki in a comment near 
> {{text_ja}} in {{scheme.xml}} to guide users to detailed information on 
> features available, how to use them, etc.
> I've made a placeholder page on 
> [http://wiki.apache.org/solr/JapaneseLanguageSupport] and I'll add details 
> post-release.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Robert Muir (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240387#comment-13240387
 ] 

Robert Muir commented on LUCENE-3930:
-

Now we have the problematic patched jars and the renamed unreleased jars.

I will start with the patched ones: these are the worst case.
I will look to see if we can have our patch file sitting in svn,
we download the sources (not jar), patch with the patch file,
and compile the thing up.



> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Robert Muir (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240385#comment-13240385
 ] 

Robert Muir commented on LUCENE-3930:
-

Thanks for all the help!!!

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3930) nuke jars from source tree and use ivy

[Chris Male (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Male updated LUCENE-3930:
---

Attachment: LUCENE-3930-solr-example.patch

Patch without pattern override.  I'll pick up where I left off in the AM.

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, 
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Robert Muir (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240379#comment-13240379
 ] 

Robert Muir commented on LUCENE-3930:
-

I think the patch is fine, but it doesn't need to override 
ivy.retrieve.pattern, 
example/lib is already its default.

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Chris Male (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240378#comment-13240378
 ] 

Chris Male commented on LUCENE-3930:


bq. Lets defer any unnecessary refactoring (even if it has benefits) to other 
issues.

Absolutely, just adding more information to chew over here.

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Robert Muir (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240377#comment-13240377
 ] 

Robert Muir commented on LUCENE-3930:
-

Lets defer any unnecessary refactoring (even if it has benefits) to other 
issues.

I think we want the minimal (reasonable) patch here that works as close as 
possible
to the ant build: given the incubator discussion about jars, unfortunately I 
think 
we need to backport this to 3.6.

So its important to keep everything as close as possible to what it was before 
so that
packaging tasks, etc work.

Seeing how things got working for solr I think we may want to revert even the 
test-framework/lib
and go back to lucene/lib intentionally just for this purpose: I'll look into 
this.


> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2698) Enhance CoreAdmin STATUS command to return index size

[Robert Muir (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated SOLR-2698:
--

Fix Version/s: (was: 4.0)

> Enhance CoreAdmin STATUS command to return index size
> -
>
> Key: SOLR-2698
> URL: https://issues.apache.org/jira/browse/SOLR-2698
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore
>Affects Versions: 4.0
>Reporter: Yury Kats
>Assignee: Mark Miller
> Fix For: 3.6
>
> Attachments: SOLR-2698.patch, SOLR-2698.patch
>
>
> CoreAdmin STATUS command returns all kinds of index info for all cores on the 
> server, except for the index size.
> However, indexSize can be retrieved for an individual core via a 
> /replication&command=details request.
> I have N Solrs servers, running M cores each. My application is monitoring 
> the status of all cores, including their index size.
> As it stands today, I need to issue N status requests plus N*M replication 
> requests to get all the information I need.
> If STATUS command returned indexSize, number of requests would be just N.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3290) Geocoding lookup for spatial search

[D Roser (Created) (JIRA)]

Geocoding lookup for spatial search
---

 Key: SOLR-3290
 URL: https://issues.apache.org/jira/browse/SOLR-3290
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Reporter: D Roser


Hi,
for searching locations "nearby" a address it would be a great enhancement to 
have a geocoding lookup through a webservice (like google geocoding,...) which 
results (lat long) can be used for spatial search.

e.g.

?q=party&nearby=street+123,+city



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3930) nuke jars from source tree and use ivy

[Robert Muir (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated LUCENE-3930:


 Priority: Blocker  (was: Major)
Fix Version/s: 3.6

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy

[Chris Male (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240371#comment-13240371
 ] 

Chris Male commented on LUCENE-3930:


This has a few other benefits.  We can move the other targets related to the 
example to example/build.xml and tie in the resolve target.

> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
> Attachments: LUCENE-3930-solr-example.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-3285) Document that StreamingUpdateSolrServer swallows exceptions

[Erick Erickson (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-3285.
--

   Resolution: Fixed
Fix Version/s: 3.6

r: 1306281

> Document that StreamingUpdateSolrServer swallows exceptions
> ---
>
> Key: SOLR-3285
> URL: https://issues.apache.org/jira/browse/SOLR-3285
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 3.5, 4.0
>Reporter: Shawn Heisey
>Priority: Trivial
> Fix For: 3.6
>
> Attachments: SOLR-3285-3x.patch
>
>
> Javadoc update for StreamingUpdateSolrServer stating that CHSS is a better 
> choice when exception handling is required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3289) Add Phonetic Search with Cologne Phonetic to documentation

[Karsten Tinnefeld (Created) (JIRA)]

Add Phonetic Search with Cologne Phonetic to documentation
--

 Key: SOLR-3289
 URL: https://issues.apache.org/jira/browse/SOLR-3289
 Project: Solr
  Issue Type: Task
  Components: documentation, Schema and Analysis
Affects Versions: 3.5, 4.0
Reporter: Karsten Tinnefeld
Priority: Minor


The results of https://issues.apache.org/jira/browse/SOLR-2276 (addition of 
ColognePhonetic as a phonetic search filter) should be documented in the 
javadocs of solr.PhoneticFilterFactory and in the Wiki 
http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3930) nuke jars from source tree and use ivy

[Chris Male (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Male updated LUCENE-3930:
---

Attachment: LUCENE-3930-solr-example.patch

Patch for addressing Solr's example/lib jars.
Adds a build.xml and ivy.xml to solr/example  

I haven't committed this since I'm unsure its the best way forward.  I've 
explored other options with ivy (through the use of confs for example) and 
there doesn't seem to be any other clean way.


> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
> Attachments: LUCENE-3930-solr-example.patch, LUCENE-3930.patch, 
> LUCENE-3930.patch, LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-3931) Adding "d" character to default ElisionFilter

[David Pilato (Created) (JIRA)]

Adding "d" character to default ElisionFilter
-

 Key: LUCENE-3931
 URL: https://issues.apache.org/jira/browse/LUCENE-3931
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/index
Reporter: David Pilato
Priority: Trivial


As described in Wikipedia (http://fr.wikipedia.org/wiki/%C3%89lision), the d 
character is used in french as an elision character.
E.g.: déclaration d'espèce
So, it would be useful to have it as a default elision token.

{code:title=ElisionFilter.java|borderStyle=solid}
  private static final CharArraySet DEFAULT_ARTICLES = 
CharArraySet.unmodifiableSet(
  new CharArraySet(Version.LUCENE_CURRENT, Arrays.asList(
  "l", "m", "t", "qu", "n", "s", "j", "d"), true));
{code}

HTH
David.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field

[Bill Bell (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240270#comment-13240270
 ] 

Bill Bell commented on SOLR-2242:
-

All tests pass on branch_3x now. 



> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2242-3x.patch, SOLR-2242-3x_4.patch, 
> SOLR-2242-solr40-3.patch, SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch, 
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch, 
> SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch
>
>
> When returning facet.field= you will get a list of matches for 
> distinct values. This is normal behavior. This patch tells you how many 
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
> 
>   
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>   
> 
> {code} 
> Several people use this to get the group.field count (the # of groups).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3272) Solr filter factory for MorfologikFilter

[Dawid Weiss (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240268#comment-13240268
 ] 

Dawid Weiss commented on SOLR-3272:
---

This is in trunk now, thanks Rafał.

> Solr filter factory for MorfologikFilter
> 
>
> Key: SOLR-3272
> URL: https://issues.apache.org/jira/browse/SOLR-3272
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Affects Versions: 4.0
>Reporter: Rafał Kuć
>Assignee: Dawid Weiss
> Fix For: 4.0
>
> Attachments: SOLR-3272-toupper-correction.patch, 
> SOLR-3272-with-javadoc-example-usage.patch, SOLR-3272.patch, SOLR-3272.patch, 
> SOLR-3272.patch, SOLR-3727-new.patch
>
>
> I didn't find MorfologikFilter factory in Solr, so here is a simple. Maybe 
> someone will have make use of it :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-3272) Solr filter factory for MorfologikFilter

[Dawid Weiss (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss resolved SOLR-3272.
---

Resolution: Fixed

Applied the patch. Thanks for clarifications concerning build deps, Steven. 
I've built and dist and the JARs make it under WEB-INF/lib so all seems good.

> Solr filter factory for MorfologikFilter
> 
>
> Key: SOLR-3272
> URL: https://issues.apache.org/jira/browse/SOLR-3272
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Affects Versions: 4.0
>Reporter: Rafał Kuć
>Assignee: Dawid Weiss
> Fix For: 4.0
>
> Attachments: SOLR-3272-toupper-correction.patch, 
> SOLR-3272-with-javadoc-example-usage.patch, SOLR-3272.patch, SOLR-3272.patch, 
> SOLR-3272.patch, SOLR-3727-new.patch
>
>
> I didn't find MorfologikFilter factory in Solr, so here is a simple. Maybe 
> someone will have make use of it :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3272) Solr filter factory for MorfologikFilter

[Dawid Weiss (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss updated SOLR-3272:
--

Attachment: SOLR-3272.patch

Final patch (applied).

> Solr filter factory for MorfologikFilter
> 
>
> Key: SOLR-3272
> URL: https://issues.apache.org/jira/browse/SOLR-3272
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Affects Versions: 4.0
>Reporter: Rafał Kuć
>Assignee: Dawid Weiss
> Fix For: 4.0
>
> Attachments: SOLR-3272-toupper-correction.patch, 
> SOLR-3272-with-javadoc-example-usage.patch, SOLR-3272.patch, SOLR-3272.patch, 
> SOLR-3272.patch, SOLR-3727-new.patch
>
>
> I didn't find MorfologikFilter factory in Solr, so here is a simple. Maybe 
> someone will have make use of it :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2242) Get distinct count of names for a facet field

[Bill Bell (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Bell updated SOLR-2242:


Attachment: (was: SOLR-2242-3x_3.patch)

> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2242-3x.patch, SOLR-2242-3x_4.patch, 
> SOLR-2242-solr40-3.patch, SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch, 
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch, 
> SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch
>
>
> When returning facet.field= you will get a list of matches for 
> distinct values. This is normal behavior. This patch tells you how many 
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
> 
>   
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>   
> 
> {code} 
> Several people use this to get the group.field count (the # of groups).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2242) Get distinct count of names for a facet field

[Bill Bell (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Bell updated SOLR-2242:


Attachment: SOLR-2242-3x_4.patch

Fixed one of the tests that was failing.
SOLR-2242-3x_4.patch


> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2242-3x.patch, SOLR-2242-3x_4.patch, 
> SOLR-2242-solr40-3.patch, SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch, 
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch, 
> SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch
>
>
> When returning facet.field= you will get a list of matches for 
> distinct values. This is normal behavior. This patch tells you how many 
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
> 
>   
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>   
> 
> {code} 
> Several people use this to get the group.field count (the # of groups).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2242) Get distinct count of names for a facet field

[Bill Bell (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Bell updated SOLR-2242:


Attachment: (was: SOLR-2242.solr35.patch)

> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2242-3x.patch, SOLR-2242-3x_3.patch, 
> SOLR-2242-solr40-3.patch, SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch, 
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch, 
> SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch
>
>
> When returning facet.field= you will get a list of matches for 
> distinct values. This is normal behavior. This patch tells you how many 
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
> 
>   
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>   
> 
> {code} 
> Several people use this to get the group.field count (the # of groups).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2242) Get distinct count of names for a facet field

[Bill Bell (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Bell updated SOLR-2242:


Attachment: (was: SOLR-2242-3x_2.patch)

> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2242-3x.patch, SOLR-2242-3x_3.patch, 
> SOLR-2242-solr40-3.patch, SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch, 
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch, 
> SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch
>
>
> When returning facet.field= you will get a list of matches for 
> distinct values. This is normal behavior. This patch tells you how many 
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
> 
>   
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>   
> 
> {code} 
> Several people use this to get the group.field count (the # of groups).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2242) Get distinct count of names for a facet field

[Bill Bell (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Bell updated SOLR-2242:


Attachment: SOLR-2242-3x_3.patch

Latest 3x patch. SOLR-2242-3x_3.patch

> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2242-3x.patch, SOLR-2242-3x_3.patch, 
> SOLR-2242-solr40-3.patch, SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch, 
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch, 
> SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch
>
>
> When returning facet.field= you will get a list of matches for 
> distinct values. This is normal behavior. This patch tells you how many 
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
> 
>   
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>   
> 
> {code} 
> Several people use this to get the group.field count (the # of groups).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field

[Bill Bell (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240240#comment-13240240
 ] 

Bill Bell commented on SOLR-2242:
-

Found a bug and attaching new patch.

> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Affects Versions: 4.0
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2242-3x.patch, SOLR-2242-3x_2.patch, 
> SOLR-2242-solr40-3.patch, SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch, 
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch, 
> SOLR-2242.solr3.1.patch, SOLR-2242.solr35.patch, SOLR.2242.solr3.1.patch
>
>
> When returning facet.field= you will get a list of matches for 
> distinct values. This is normal behavior. This patch tells you how many 
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=2&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=0&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numFacetTerms=1&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
> 
>   
> 14
> 31 name="19.95">111 name="179.99">111 name="329.95">111 name="479.95">111
>   
> 
> {code} 
> Several people use this to get the group.field count (the # of groups).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org