[jira] Commented: (LUCENE-2957) generate-maven-artifacts target should include all non-Mavenized Lucene & Solr dependencies
[
https://issues.apache.org/jira/browse/LUCENE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004991#comment-13004991
]
Uwe Schindler commented on LUCENE-2957:
---
xml-apis.jar should have a real remote dependency, as its only bundled with
xerces/xalan. Same applies to serializer.jar (it is common to both xerces and
xalan and is simply for serializing XML). Only the patched JAR file should be
included on our lucene-local repo.
Alltogether, xml-apis.jar is not needed with xerces-2.9 and Java 5, as Java 5
already has these interface classes (JAXP 1.3). Xerces 2.11 needs it, because
it ships with Java 6's JAXP release (containing STAX & Co. not available in
Java 5).
> generate-maven-artifacts target should include all non-Mavenized Lucene &
> Solr dependencies
> ---
>
> Key: LUCENE-2957
> URL: https://issues.apache.org/jira/browse/LUCENE-2957
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Build
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
>
> Currently, in addition to deploying artifacts for all of the Lucene and Solr
> modules to a repository (by default local), the {{generate-maven-artifacts}}
> target also deploys artifacts for the following non-Mavenized Solr
> dependencies (lucene_solr_3_1 version given here):
> # {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
> org.apache.solr:solr-commons-csv:3.1
> # {{solr/lib/apache-solr-noggit-r944541.jar}} as
> org.apache.solr:solr-noggit:3.1
> \\ \\
> The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
> version given here):
> \\ \\
> # {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
> #
> {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
> # {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
> # {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
> # {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
> # {{solr/contrib/uima/lib/uima-an-calais.jar}}
> # {{solr/contrib/uima/lib/uima-an-tagger.jar}}
> # {{solr/contrib/uima/lib/uima-an-wst.jar}}
> # {{solr/contrib/uima/lib/uima-core.jar}}
> \\ \\
> I think it makes sense to follow the same model as the current non-Mavenized
> dependencies:
> \\ \\
> * {{groupId}} = {{org.apache.solr/.lucene}}
> * {{artifactId}} = {{solr-/lucene-}},
> * {{version}} = .
> **The carrot2-core jar doesn't need to be included in trunk's release
> artifacts, since there already is a Mavenized Java6-compiled jar. branch_3x
> and lucene_solr_3_1 will need this Solr-specific Java5-compiled maven
> artifact, though.
--
This message is automatically generated by JIRA.
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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5762 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5762/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8470 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2957) generate-maven-artifacts target should include all non-Mavenized Lucene & Solr dependencies
[
https://issues.apache.org/jira/browse/LUCENE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004987#comment-13004987
]
Dawid Weiss commented on LUCENE-2957:
-
Hi Steven. Would it help a lot if we released a Java 1.5 version of Carrot2
3.4.3? I would have to try to retrotranslate it manually, but I guess it'd be
possible -- we don't use that many Java 1.6 specific methods.
http://repo2.maven.org/maven2/org/carrot2/carrot2-mini/
> generate-maven-artifacts target should include all non-Mavenized Lucene &
> Solr dependencies
> ---
>
> Key: LUCENE-2957
> URL: https://issues.apache.org/jira/browse/LUCENE-2957
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Build
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
>
> Currently, in addition to deploying artifacts for all of the Lucene and Solr
> modules to a repository (by default local), the {{generate-maven-artifacts}}
> target also deploys artifacts for the following non-Mavenized Solr
> dependencies (lucene_solr_3_1 version given here):
> # {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
> org.apache.solr:solr-commons-csv:3.1
> # {{solr/lib/apache-solr-noggit-r944541.jar}} as
> org.apache.solr:solr-noggit:3.1
> \\ \\
> The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
> version given here):
> \\ \\
> # {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
> #
> {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
> # {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
> # {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
> # {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
> # {{solr/contrib/uima/lib/uima-an-calais.jar}}
> # {{solr/contrib/uima/lib/uima-an-tagger.jar}}
> # {{solr/contrib/uima/lib/uima-an-wst.jar}}
> # {{solr/contrib/uima/lib/uima-core.jar}}
> \\ \\
> I think it makes sense to follow the same model as the current non-Mavenized
> dependencies:
> \\ \\
> * {{groupId}} = {{org.apache.solr/.lucene}}
> * {{artifactId}} = {{solr-/lucene-}},
> * {{version}} = .
> **The carrot2-core jar doesn't need to be included in trunk's release
> artifacts, since there already is a Mavenized Java6-compiled jar. branch_3x
> and lucene_solr_3_1 will need this Solr-specific Java5-compiled maven
> artifact, though.
--
This message is automatically generated by JIRA.
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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5761 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5761/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8456 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-2957) generate-maven-artifacts target should include all non-Mavenized Lucene & Solr dependencies
[
https://issues.apache.org/jira/browse/LUCENE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-2957:
Description:
Currently, in addition to deploying artifacts for all of the Lucene and Solr
modules to a repository (by default local), the {{generate-maven-artifacts}}
target also deploys artifacts for the following non-Mavenized Solr dependencies
(lucene_solr_3_1 version given here):
# {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
org.apache.solr:solr-commons-csv:3.1
# {{solr/lib/apache-solr-noggit-r944541.jar}} as org.apache.solr:solr-noggit:3.1
\\ \\
The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
version given here):
\\ \\
# {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
# {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
# {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
# {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
# {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
# {{solr/contrib/uima/lib/uima-an-calais.jar}}
# {{solr/contrib/uima/lib/uima-an-tagger.jar}}
# {{solr/contrib/uima/lib/uima-an-wst.jar}}
# {{solr/contrib/uima/lib/uima-core.jar}}
\\ \\
I think it makes sense to follow the same model as the current non-Mavenized
dependencies:
\\ \\
* {{groupId}} = {{org.apache.solr/.lucene}}
* {{artifactId}} = {{solr-/lucene-}},
* {{version}} = .
**The carrot2-core jar doesn't need to be included in trunk's release
artifacts, since there already is a Mavenized Java6-compiled jar. branch_3x
and lucene_solr_3_1 will need this Solr-specific Java5-compiled maven artifact,
though.
was:
Currently, in addition to deploying artifacts for all of the Lucene and Solr
modules to a repository (by default local), the {{generate-maven-artifacts}}
target also deploys artifacts for the following non-Mavenized Solr dependencies
(lucene_solr_3_1 version given here):
# {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
org.apache.solr:solr-commons-csv:3.1
# {{solr/lib/apache-solr-noggit-r944541.jar}} as org.apache.solr:solr-noggit:3.1
\\ \\
The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
version given here):
\\ \\
# {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
# {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
# {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
# {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
# {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
# {{solr/contrib/uima/lib/uima-an-calais.jar}}
# {{solr/contrib/uima/lib/uima-an-tagger.jar}}
# {{solr/contrib/uima/lib/uima-an-wst.jar}}
# {{solr/contrib/uima/lib/uima-core.jar}}
# {{solr/example/lib/jetty-6.1.26-patched-JETTY-1340.jar}}
# {{solr/example/lib/jetty-util-6.1.26-patched-JETTY-1340.jar}}
\\ \\
I think it makes sense to follow the same model as the current non-Mavenized
dependencies:
\\ \\
* {{groupId}} = {{org.apache.solr/.lucene}}
* {{artifactId}} = {{solr-/lucene-}},
* {{version}} = .
**The carrot2-core jar doesn't need to be included in trunk's release
artifacts, since there already is a Mavenized Java6-compiled jar. branch_3x
and lucene_solr_3_1 will need this Solr-specific Java5-compiled maven artifact,
though.
Removed the jetty and jetty-util jars from the list of publishable
non-mavenized dependencies, as they are used mainly for testing.
> generate-maven-artifacts target should include all non-Mavenized Lucene &
> Solr dependencies
> ---
>
> Key: LUCENE-2957
> URL: https://issues.apache.org/jira/browse/LUCENE-2957
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Build
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
>
> Currently, in addition to deploying artifacts for all of the Lucene and Solr
> modules to a repository (by default local), the {{generate-maven-artifacts}}
> target also deploys artifacts for the following non-Mavenized Solr
> dependencies (lucene_solr_3_1 version given here):
> # {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
> org.apache.solr:solr-commons-csv:3.1
> # {{solr/lib/apache-solr-noggit-r944541.jar}} as
> org.apache.solr:solr-noggit:3.1
> \\ \\
> The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
> version given here):
> \\ \\
> # {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
> #
> {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
> # {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
> # {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
> # {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
> # {{solr/contrib/uima/lib/uima-an-calais.jar}}
> # {{solr/contrib/uima/lib/uima-an-tagger.jar}}
> # {{solr/contrib/uima/lib/uima-an-wst.jar}}
> # {{solr/c
[jira] Updated: (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-2562: Labels: gsoc2011 lucene-gsoc-11 (was: ) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Java > Issue Type: Task >Reporter: Mark Miller > Labels: gsoc2011, lucene-gsoc-11 > Attachments: luke1.jpg, luke2.jpg, luke3.jpg > > > see > http://search.lucidimagination.com/search/document/ee0e048c6b56ee2/luke_in_need_of_maintainer > http://search.lucidimagination.com/search/document/5e53136b7dcb609b/web_based_luke > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message is automatically generated by JIRA. 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-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004980#comment-13004980 ] Simon Willnauer commented on LUCENE-2562: - mark, I marked this as gsoc2011 so if somebody is interested in working on this during GSoC can apply for it. Hope that is ok for you though. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Java > Issue Type: Task >Reporter: Mark Miller > Labels: gsoc2011, lucene-gsoc-11 > Attachments: luke1.jpg, luke2.jpg, luke3.jpg > > > see > http://search.lucidimagination.com/search/document/ee0e048c6b56ee2/luke_in_need_of_maintainer > http://search.lucidimagination.com/search/document/5e53136b7dcb609b/web_based_luke > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5760 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5760/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8470 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5759 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5759/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8471 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Solr-3.x - Build # 289 - Failure
Build: https://hudson.apache.org/hudson/job/Solr-3.x/289/ All tests passed Build Log (for compile errors): [...truncated 11896 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5758 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5758/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8458 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5757 - Failure
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5757/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8489 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5755 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5755/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8470 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-2957) generate-maven-artifacts target should include all non-Mavenized Lucene & Solr dependencies
[
https://issues.apache.org/jira/browse/LUCENE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-2957:
Description:
Currently, in addition to deploying artifacts for all of the Lucene and Solr
modules to a repository (by default local), the {{generate-maven-artifacts}}
target also deploys artifacts for the following non-Mavenized Solr dependencies
(lucene_solr_3_1 version given here):
# {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
org.apache.solr:solr-commons-csv:3.1
# {{solr/lib/apache-solr-noggit-r944541.jar}} as org.apache.solr:solr-noggit:3.1
\\ \\
The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
version given here):
\\ \\
# {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
# {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
# {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
# {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
# {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
# {{solr/contrib/uima/lib/uima-an-calais.jar}}
# {{solr/contrib/uima/lib/uima-an-tagger.jar}}
# {{solr/contrib/uima/lib/uima-an-wst.jar}}
# {{solr/contrib/uima/lib/uima-core.jar}}
# {{solr/example/lib/jetty-6.1.26-patched-JETTY-1340.jar}}
# {{solr/example/lib/jetty-util-6.1.26-patched-JETTY-1340.jar}}
\\ \\
I think it makes sense to follow the same model as the current non-Mavenized
dependencies:
\\ \\
* {{groupId}} = {{org.apache.solr/.lucene}}
* {{artifactId}} = {{solr-/lucene-}},
* {{version}} = .
**The carrot2-core jar doesn't need to be included in trunk's release
artifacts, since there already is a Mavenized Java6-compiled jar. branch_3x
and lucene_solr_3_1 will need this Solr-specific Java5-compiled maven artifact,
though.
was:
Currently, in addition to deploying artifacts for all of the Lucene and Solr
modules to a repository (by default local), the {{generate-maven-artifacts}}
target also deploys artifacts for the following non-Mavenized Solr dependencies
(lucene_solr_3_1 version given here):
# {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
org.apache.solr:solr-commons-csv:3.1
# {{solr/lib/apache-solr-noggit-r944541.jar}} as org.apache.solr:solr-noggit:3.1
\\ \\
The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
version given here):
\\ \\
# {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
# {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
# {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
# {{lucene/contrib/db/bdb/lib/db-4.7.25.jar}}
# {{lucene/contrib/db/bdb-je/lib/je-3.3.93.jar}}
# {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}
# {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
# {{solr/contrib/uima/lib/uima-an-calais.jar}}
# {{solr/contrib/uima/lib/uima-an-tagger.jar}}
# {{solr/contrib/uima/lib/uima-an-wst.jar}}
# {{solr/contrib/uima/lib/uima-core.jar}}
# {{solr/example/lib/jetty-6.1.26-patched-JETTY-1340.jar}}
# {{solr/example/lib/jetty-util-6.1.26-patched-JETTY-1340.jar}}
\\ \\
I think it makes sense to follow the same model as the current non-Mavenized
dependencies:
\\ \\
* {{groupId}} = {{org.apache.solr/.lucene}}
* {{artifactId}} = {{solr-/lucene-}},
* {{version}} = .
Edited description:
# Removed berkeleydb jars from the list. These are not in the source tree, I
assume because their licenses aren't compatible with the ASL, so releasing them
as maven artifacts makes no sense.
# Added note about carrot2-core
> generate-maven-artifacts target should include all non-Mavenized Lucene &
> Solr dependencies
> ---
>
> Key: LUCENE-2957
> URL: https://issues.apache.org/jira/browse/LUCENE-2957
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Build
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
>
> Currently, in addition to deploying artifacts for all of the Lucene and Solr
> modules to a repository (by default local), the {{generate-maven-artifacts}}
> target also deploys artifacts for the following non-Mavenized Solr
> dependencies (lucene_solr_3_1 version given here):
> # {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
> org.apache.solr:solr-commons-csv:3.1
> # {{solr/lib/apache-solr-noggit-r944541.jar}} as
> org.apache.solr:solr-noggit:3.1
> \\ \\
> The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
> version given here):
> \\ \\
> # {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
> #
> {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
> # {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
> # {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
> # {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
> # {{solr/contrib/uima/lib/uima-an-calais.jar}}
> # {{solr/con
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5754 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5754/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8493 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5753 - Failure
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5753/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8475 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Resolved: (SOLR-2411) Build target prepare-release should produce a directory containing only distribution files
[
https://issues.apache.org/jira/browse/SOLR-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe resolved SOLR-2411.
---
Resolution: Fixed
Committed:
branch_3x revision 1080071
lucene_solr_3_1 revision 1080078
trunk revision 1080094
> Build target prepare-release should produce a directory containing only
> distribution files
> --
>
> Key: SOLR-2411
> URL: https://issues.apache.org/jira/browse/SOLR-2411
> Project: Solr
> Issue Type: Improvement
> Components: Build
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
> Attachments: SOLR-2411.patch, SOLR-2411.patch
>
>
> The {{solr/dist/}} directory is currently used:
> # to hold binary artifacts to be used by example configurations;
> # to store intermediate binary, source and javadoc archives that will be part
> of a release packages and deployed as maven artifacts; and
> # to hold the results of the {{package}}, {{package-src}} and
> {{generate-maven-artifacts}} targets: binary and source packages and maven
> artifacts.
> Release packages and maven artifacts should go someplace else so that the
> files comprising a release are clearly separated from the other stuff.
--
This message is automatically generated by JIRA.
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-2418) remove deprecated syntax
remove deprecated syntax
Key: SOLR-2418
URL: https://issues.apache.org/jira/browse/SOLR-2418
Project: Solr
Issue Type: Task
Components: highlighter
Affects Versions: 1.4.1, 3.1
Reporter: Koji Sekiguchi
Assignee: Koji Sekiguchi
Priority: Trivial
Fix For: 3.2, 4.0
excerpt from CHANGES.txt:
{noformat}
== 3.1.0-dev ==
Upgrading from Solr 1.4
--
* Old syntax of configuration in solrconfig.xml
is deprecated (SOLR-1696)
{noformat}
--
This message is automatically generated by JIRA.
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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5751 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5751/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8466 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Lucene and Solr 3.1 release candidate
Hi Grant, On 3/9/2001 at 6:38 AM Grant Ingersoll wrote: > > 2011/3/8 Steven A Rowe : > >> Solr (and some Lucene modules) have several non-Mavenized dependencies. > > In the past, we have usually published these along with Solr, by changing > the names to be something like solr-foo.1.5.jar (see the commons-csv from > 1.4) You're right. I have no idea why this didn't occur to me. I think this should be fixed before 3.1 gets released. I've created an issue to track the work: https://issues.apache.org/jira/browse/LUCENE-2957 Steve
[jira] Updated: (SOLR-1566) Allow components to add fields to outgoing documents
[ https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-1566: Attachment: SOLR-1566-DocTransformer.patch updating this patch with a non-trivial transformation. This adds explain info directly to the results SOLR-2417 > Allow components to add fields to outgoing documents > > > Key: SOLR-1566 > URL: https://issues.apache.org/jira/browse/SOLR-1566 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Noble Paul >Assignee: Grant Ingersoll > Fix For: Next > > Attachments: SOLR-1566-DocTransformer.patch, > SOLR-1566-DocTransformer.patch, SOLR-1566-DocTransformer.patch, > SOLR-1566-gsi.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch, > SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566.patch, > SOLR-1566.patch, SOLR-1566.patch, SOLR-1566.patch > > > Currently it is not possible for components to add fields to outgoing > documents which are not in the the stored fields of the document. This makes > it cumbersome to add computed fields/metadata . -- This message is automatically generated by JIRA. 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-2417) Allow explain info directly to response documents
Allow explain info directly to response documents - Key: SOLR-2417 URL: https://issues.apache.org/jira/browse/SOLR-2417 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Priority: Minor Fix For: 4.0 Currently explain information in displayed in the debugInfo part of the response. This requires clients to build a Map and link results later if they want them displayed together. It also does not nicely allow for multiple queries in one result. As part of SOLR-1566, we can add the explain info directly to the result -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5750 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5750/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8477 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Resolved: (SOLR-2414) Remove CESU-Hack from PHPSerializedResponseWriter
[ https://issues.apache.org/jira/browse/SOLR-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved SOLR-2414. - Resolution: Fixed Committed trunk revision: 1080038 Committed 3.x revision: 1080041 Committed 3.1 revision: 1080042 > Remove CESU-Hack from PHPSerializedResponseWriter > - > > Key: SOLR-2414 > URL: https://issues.apache.org/jira/browse/SOLR-2414 > Project: Solr > Issue Type: Task >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.1, 3.2, 4.0 > > Attachments: SOLR-2414.patch > > > When SOLR-2381 is committed we no longer use the Writer supplied by the > underlying Servlet Container. We can therefore assume that UTF-8 is not CESU, > so the hack in PHPSerilaizedResponseWriter is obsolete. > We should remove it or at least disable the system property, as this is > explained in the Wiki and some people may already used it, now failing with > 3.1, as we always produce UTF-8 and if the CESU property is true, the > serialized output is suddenly wrong. -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5749 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5749/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8457 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2415) Change XMLWriter version parameter to "wt.xml.version"
[ https://issues.apache.org/jira/browse/SOLR-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004834#comment-13004834 ] Yonik Seeley commented on SOLR-2415: "version" doesn't have to just apply to the XML response format - it could apply to any response formats that change. If we were starting off fresh, something like "xml.version" might make sense... but for people using "version" right now, it would be nice if the XML format didn't change out from under them next time we upgrade the format? > Change XMLWriter version parameter to "wt.xml.version" > -- > > Key: SOLR-2415 > URL: https://issues.apache.org/jira/browse/SOLR-2415 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Trivial > Fix For: 4.0 > > > The XMLWriter has a parameter called 'version'. This controls some specifics > about how the XMLWriter works. Using the parameter name 'version' made sense > back when the XMLWriter was the only option, but with all the various writers > and different places where 'version' makes sense, I think we should change > this parameter name to "wt.xml.version" so that it specifically refers to the > XMLWriter. -- This message is automatically generated by JIRA. 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-2399) Solr Admin Interface, reworked
[ https://issues.apache.org/jira/browse/SOLR-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004828#comment-13004828 ] Stefan Matheis (steffkes) commented on SOLR-2399: - Thanks Jan for testing - after modifying the regex which was used to detect the environment, it's now working correctly [[github commit|https://github.com/steffkes/solr-admin/commit/69ea499]] > Solr Admin Interface, reworked > -- > > Key: SOLR-2399 > URL: https://issues.apache.org/jira/browse/SOLR-2399 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Priority: Minor > > *The idea was to create a new, fresh (and hopefully clean) Solr Admin > Interface.* [Based on this > [ML-Thread|http://www.lucidimagination.com/search/document/ae35e236d29d225e/solr_admin_interface_reworked_go_on_go_away]] > I've quickly created a Github-Repository (Just for me, to keep track of the > changes) > ยป https://github.com/steffkes/solr-admin > [This commit shows the > differences|https://github.com/steffkes/solr-admin/commit/5f80bb0ea9deb4b94162632912fe63386f869e0d] > between old/existing index.jsp and my new one (which is could > copy-cut/paste'd from the existing one). > Main Action takes place in > [js/script.js|https://github.com/steffkes/solr-admin/blob/master/js/script.js] > which is actually neither clean nor pretty .. just work-in-progress. > Actually it's Work in Progress, so ... give it a try. It's developed with > Firefox as Browser, so, for a first impression .. please don't use _things_ > like Internet Explorer or so ;o > Jan already suggested a bunch of good things, i'm sure there are more ideas > over there :) -- This message is automatically generated by JIRA. 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-2957) generate-maven-artifacts target should include all non-Mavenized Lucene & Solr dependencies
generate-maven-artifacts target should include all non-Mavenized Lucene & Solr
dependencies
---
Key: LUCENE-2957
URL: https://issues.apache.org/jira/browse/LUCENE-2957
Project: Lucene - Java
Issue Type: Improvement
Components: Build
Affects Versions: 3.1, 3.2, 4.0
Reporter: Steven Rowe
Priority: Minor
Fix For: 3.1, 3.2, 4.0
Currently, in addition to deploying artifacts for all of the Lucene and Solr
modules to a repository (by default local), the {{generate-maven-artifacts}}
target also deploys artifacts for the following non-Mavenized Solr dependencies
(lucene_solr_3_1 version given here):
# {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
org.apache.solr:solr-commons-csv:3.1
# {{solr/lib/apache-solr-noggit-r944541.jar}} as org.apache.solr:solr-noggit:3.1
\\ \\
The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
version given here):
\\ \\
# {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
# {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
# {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
# {{lucene/contrib/db/bdb/lib/db-4.7.25.jar}}
# {{lucene/contrib/db/bdb-je/lib/je-3.3.93.jar}}
# {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}
# {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
# {{solr/contrib/uima/lib/uima-an-calais.jar}}
# {{solr/contrib/uima/lib/uima-an-tagger.jar}}
# {{solr/contrib/uima/lib/uima-an-wst.jar}}
# {{solr/contrib/uima/lib/uima-core.jar}}
# {{solr/example/lib/jetty-6.1.26-patched-JETTY-1340.jar}}
# {{solr/example/lib/jetty-util-6.1.26-patched-JETTY-1340.jar}}
\\ \\
I think it makes sense to follow the same model as the current non-Mavenized
dependencies:
\\ \\
* {{groupId}} = {{org.apache.solr/.lucene}}
* {{artifactId}} = {{solr-/lucene-}},
* {{version}} = .
--
This message is automatically generated by JIRA.
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-2945) Surround Query doesn't properly handle equals/hashcode
[ https://issues.apache.org/jira/browse/LUCENE-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-2945: - Attachment: LUCENE-2945c.patch The LUCENE-2945c.patch starts from the patch of 5 March. It adds static inner classes to with hashCode() and equals() as needed here. For now, these classes throw a RuntimeException created from a CloneNotSupportedException in their clone() methods. This leaves clone() not correctly implemented, but at least now a RuntimeException is thrown instead of previously returning an incorrect result. The patch also includes a single passing test in SrndQueryTest for equal queries when parsed from strings that only differ in whitespace. The other tests there have been commented out because they use clone() via QueryUtils More tests are still needed, also for inequality. The earlier tests all pass. > Surround Query doesn't properly handle equals/hashcode > -- > > Key: LUCENE-2945 > URL: https://issues.apache.org/jira/browse/LUCENE-2945 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 3.0.3, 3.1, 4.0 >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 3.1.1, 4.0 > > Attachments: LUCENE-2945-partial1.patch, LUCENE-2945.patch, > LUCENE-2945.patch, LUCENE-2945.patch, LUCENE-2945c.patch > > > In looking at using the surround queries with Solr, I am hitting issues > caused by collisions due to equals/hashcode not being implemented on the > anonymous inner classes that are created by things like DistanceQuery (branch > 3.x, near line 76) -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5748 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5748/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8477 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-2947) NGramTokenizer shouldn't trim whitespace
[
https://issues.apache.org/jira/browse/LUCENE-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Byrne updated LUCENE-2947:
Attachment: LUCENE-2947.patch
I've finished my first attempt at a patch. The code could benefit from a bit
of refactoring, but I wanted to make sure everyone agrees to the changes in
principal before working on refining it. The test cases (hopefully) illustrate
most of the nuances.
Benefits:
- accepts strings of any length (not just 1024 chars)
- collapses consecutive whitespace characters
- takes custom sets of chars to be treated as whitespace
- "pads" the beginning and end of the string
- Follows the same format as the PDF Robert linked above
Quirks (examples in the test cases):
- Unigrams aren't "padded"...it just made the most sense
- because of the format, underscores will look identical to whitespace
- leading or trailing whitespace can result in weird looking ngrams (i.e. "__")
- offset values for ngrams with collapsed whitespace can be unintuitive (but
consistent)
> NGramTokenizer shouldn't trim whitespace
>
>
> Key: LUCENE-2947
> URL: https://issues.apache.org/jira/browse/LUCENE-2947
> Project: Lucene - Java
> Issue Type: Bug
> Components: contrib/analyzers
>Affects Versions: 3.0.3
>Reporter: David Byrne
>Priority: Minor
> Attachments: LUCENE-2947.patch, NGramTokenizerTest.java
>
>
> Before I tokenize my strings, I am padding them with white space:
> String foobar = " " + foo + " " + bar + " ";
> When constructing term vectors from ngrams, this strategy has a couple
> benefits. First, it places special emphasis on the starting and ending of a
> word. Second, it improves the similarity between phrases with swapped words.
> " foo bar " matches " bar foo " more closely than "foo bar" matches "bar
> foo".
> The problem is that Lucene's NGramTokenizer trims whitespace. This forces me
> to do some preprocessing on my strings before I can tokenize them:
> foobar.replaceAll(" ","$"); //arbitrary char not in my data
> This is undocumented, so users won't realize their strings are being
> trim()'ed, unless they look through the source, or examine the tokens
> manually.
> I am proposing NGramTokenizer should be changed to respect whitespace. Is
> there a compelling reason against this?
--
This message is automatically generated by JIRA.
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-2956) Support updateDocument() with DWPTs
[
https://issues.apache.org/jira/browse/LUCENE-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004818#comment-13004818
]
Michael Busch commented on LUCENE-2956:
---
An idea from Mike how to fix this problem:
{quote}
To avoid the full-stop, I think during the flush we can have two global delete
pools. We carefully sweep all DWPTs and flush each, in succession. Any DWPT not
yet flushed is free to continue indexing as normal, putting deletes into the
first global pool, flushing as normal. But, a DWPT that has been flushed by the
"sweeper" must instead put deletes for an updateDocument carefully into the 2nd
pool, and not buffer the delete into DWPTs not yet flushed.
{quote}
> Support updateDocument() with DWPTs
> ---
>
> Key: LUCENE-2956
> URL: https://issues.apache.org/jira/browse/LUCENE-2956
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
>Affects Versions: Realtime Branch
>Reporter: Michael Busch
>Assignee: Michael Busch
>Priority: Minor
> Fix For: Realtime Branch
>
>
> With separate DocumentsWriterPerThreads (DWPT) it can currently happen that
> the delete part of an updateDocument() is flushed and committed separately
> from the corresponding new document.
> We need to make sure that updateDocument() is always an atomic operation from
> a IW.commit() and IW.getReader() perspective. See LUCENE-2324 for more
> details.
--
This message is automatically generated by JIRA.
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-2956) Support updateDocument() with DWPTs
[ https://issues.apache.org/jira/browse/LUCENE-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch updated LUCENE-2956: -- Component/s: Index Description: With separate DocumentsWriterPerThreads (DWPT) it can currently happen that the delete part of an updateDocument() is flushed and committed separately from the corresponding new document. We need to make sure that updateDocument() is always an atomic operation from a IW.commit() and IW.getReader() perspective. See LUCENE-2324 for more details. was: With separate DocumentsWriterPerThreads (DWPT) it can currently happen that the delete part of an updateDocument() is flushed and committed separately from the corresponding new document. We need to make sure that updateDocument() is always a atomic operation from a IW.commit() and IW.getReader() perspective. See LUCENE-2324 for more details. Affects Version/s: Realtime Branch Fix Version/s: Realtime Branch > Support updateDocument() with DWPTs > --- > > Key: LUCENE-2956 > URL: https://issues.apache.org/jira/browse/LUCENE-2956 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: Realtime Branch >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Minor > Fix For: Realtime Branch > > > With separate DocumentsWriterPerThreads (DWPT) it can currently happen that > the delete part of an updateDocument() is flushed and committed separately > from the corresponding new document. > We need to make sure that updateDocument() is always an atomic operation from > a IW.commit() and IW.getReader() perspective. See LUCENE-2324 for more > details. -- This message is automatically generated by JIRA. 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-2956) Support updateDocument() with DWPTs
Support updateDocument() with DWPTs --- Key: LUCENE-2956 URL: https://issues.apache.org/jira/browse/LUCENE-2956 Project: Lucene - Java Issue Type: Bug Reporter: Michael Busch Assignee: Michael Busch Priority: Minor With separate DocumentsWriterPerThreads (DWPT) it can currently happen that the delete part of an updateDocument() is flushed and committed separately from the corresponding new document. We need to make sure that updateDocument() is always a atomic operation from a IW.commit() and IW.getReader() perspective. See LUCENE-2324 for more details. -- This message is automatically generated by JIRA. 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
Adding Support for occurances in SpanQueries
I'm currently working on a project that involves highlighting all the words in
document that match a given Query.
Right now, there is a highlighter in Lucene, but all it does, I think, is to
take the query, extract the terms out of it, and highlight every term.
I presume this is what everyone wants usually, but in my case, what I want is
to match every word that is actually part of the queries internal evaluation.
For example, Lets say I used a SpanNearNot query, I would not want to highlight
the terms in the spans that were excluded.
I was thinking of adding this feature to the SpanQueries, since they share an
API that regular Queries do not have: getSpans().
Regular queries, I think, do not allow us to get the positions of the matched
elements in the query (if any matched) so I would not touch these.
Considering SpanQueries have the getSpans() method, I wanted to add this API to
it :
*
public abstract class Spans {
public abstract boolean next() throws IOException;
public abstract boolean skipTo(int target) throws IOException;
public abstract int doc();
public abstract int start();
public abstract int end();
public abstract Collection/**/ getPayload() throws IOException;
public abstract boolean isPayloadAvailable();
//NEW STUFF HERE
public abstract Collection/*SpanMatchedTerm*/ getSpanMatchedTerms();
}
public class SpanMatchedTerm {
public Term term;
public String displayName;
public int position;
/**
* Creates a MatchedTerm. The displayName is an optional name that
* refers to this query. Used when term.getTerm() is not enough.
* A good example would be when you stem terms.
* You could use the displayName as the non-stemmed text, which
* you would use afterwards to display this match.
**/
public SpanMatchedTerm(Term term, String displayName, int position) {
this.term = term;
this.position = position;
this.displayName = displayName;
}
}
**
So basically, I can create a SpanQuery, then call getSpans() on it, cycle
through the spans, each time calling getSpanMatchedTerms() to get the
individual terms that allowed this span to match.
The getSpanMatchedTerms would work just like the getPayloads, except it will
return the positions of the match along with whatever optional displayName you
tagged along for this term.
The displayName is useful if you want to write a SpanWildcardQuery() that
mimics the WildcardQuery. In that case, you would like to highlight every term,
but if you want to show a navigation bar to cycle through hits, you want to
show the original term with the wildcard in it, not every different term that
matched.
Do you think its the good way of going about this problem?
Would it stand a chance of getting included if this implementation was submited
as a patch along with the fixes to the various Spans*** classes to make it work?
Thanks!
Daniel Shane
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-1351) facet on same field different ways
[ https://issues.apache.org/jira/browse/SOLR-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004807#comment-13004807 ] Robert Purdy commented on SOLR-1351: Patch does not work with current nightly in solr 3.2, solr 4.0 and with latest stable release 1.4.1. Has this been integrated into the current version(s)? If not is there an updated patch somewhere? Thanks Robert. > facet on same field different ways > -- > > Key: SOLR-1351 > URL: https://issues.apache.org/jira/browse/SOLR-1351 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Fix For: Next > > Attachments: SOLR-1351.patch > > > There is a general need to facet on the same field in different ways > (different prefixes, different filters). We need a way to express this. -- This message is automatically generated by JIRA. 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-2414) Remove CESU-Hack from PHPSerializedResponseWriter
[ https://issues.apache.org/jira/browse/SOLR-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-2414: Attachment: SOLR-2414.patch > Remove CESU-Hack from PHPSerializedResponseWriter > - > > Key: SOLR-2414 > URL: https://issues.apache.org/jira/browse/SOLR-2414 > Project: Solr > Issue Type: Task >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.1, 3.2, 4.0 > > Attachments: SOLR-2414.patch > > > When SOLR-2381 is committed we no longer use the Writer supplied by the > underlying Servlet Container. We can therefore assume that UTF-8 is not CESU, > so the hack in PHPSerilaizedResponseWriter is obsolete. > We should remove it or at least disable the system property, as this is > explained in the Wiki and some people may already used it, now failing with > 3.1, as we always produce UTF-8 and if the CESU property is true, the > serialized output is suddenly wrong. -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5747 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5747/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8479 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-2025) Ability to turn off the store for an index
[ https://issues.apache.org/jira/browse/LUCENE-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-2025: Labels: gsoc2011 lucene-gsoc-11 (was: ) > Ability to turn off the store for an index > -- > > Key: LUCENE-2025 > URL: https://issues.apache.org/jira/browse/LUCENE-2025 > Project: Lucene - Java > Issue Type: New Feature > Components: Index >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Minor > Labels: gsoc2011, lucene-gsoc-11 > Fix For: 4.0 > > > It would be really good in combination with parallel indexing if the > Lucene store could be turned off entirely for an index. > The reason is that part of the store is the FieldIndex (.fdx file), > which contains an 8 bytes pointer for each document in a segment, even > if a document does not contain any stored fields. > With parallel indexing we will want to rewrite certain parallel > indexes to update them, and if such an update affects only a small > number of documents it will be a waste if you have to write the .fdx > file every time. > So in the case where you only want to update a data structure in the > inverted index it makes sense to separate your index into multiple > parallel indexes, where the ones you want to update don't contain any > stored fields. > It'd be also great to not only allow turning off the store but to make > it customizable, similarly to what flexible indexing wants to achieve > regarding the inverted index. > As a start I'd be happy with the ability to simply turn off the store and to > add more flexibility later. -- This message is automatically generated by JIRA. 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-2026) Refactoring of IndexWriter
[ https://issues.apache.org/jira/browse/LUCENE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-2026: Labels: gsoc2011 lucene-gsoc-11 (was: ) > Refactoring of IndexWriter > -- > > Key: LUCENE-2026 > URL: https://issues.apache.org/jira/browse/LUCENE-2026 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Minor > Labels: gsoc2011, lucene-gsoc-11 > Fix For: 4.0 > > > I've been thinking for a while about refactoring the IndexWriter into > two main components. > One could be called a SegmentWriter and as the > name says its job would be to write one particular index segment. The > default one just as today will provide methods to add documents and > flushes when its buffer is full. > Other SegmentWriter implementations would do things like e.g. appending or > copying external segments [what addIndexes*() currently does]. > The second component's job would it be to manage writing the segments > file and merging/deleting segments. It would know about > DeletionPolicy, MergePolicy and MergeScheduler. Ideally it would > provide hooks that allow users to manage external data structures and > keep them in sync with Lucene's data during segment merges. > API wise there are things we have to figure out, such as where the > updateDocument() method would fit in, because its deletion part > affects all segments, whereas the new document is only being added to > the new segment. > Of course these should be lower level APIs for things like parallel > indexing and related use cases. That's why we should still provide > easy to use APIs like today for people who don't need to care about > per-segment ops during indexing. So the current IndexWriter could > probably keeps most of its APIs and delegate to the new classes. -- This message is automatically generated by JIRA. 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-1566) Allow components to add fields to outgoing documents
[
https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004800#comment-13004800
]
Ryan McKinley commented on SOLR-1566:
-
Updated patch. This changes the the API to:
{code:java}
public abstract class DocTransformer
{
public void setContext( TransformContext context ) {}
public abstract void transform(SolrDocument doc, int docid);
}
{code}
This will let the TransformContext hold objects that may be useful for filling
up the SolrDocument later.
For example, the DocIterator is included in TransformContext and that is used
to fill in the score (rather then passing Float score to every transformer).
Another example would be if we have the Query object and want to add 'explain'
info directly to the document.
Bill -- re geodist(), yes that is my real motivation for this! see SOLR-1298
Something is still weird with the Distributed search stuff, but figure I should
get feedback on general approach before worrying about that.
> Allow components to add fields to outgoing documents
>
>
> Key: SOLR-1566
> URL: https://issues.apache.org/jira/browse/SOLR-1566
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Noble Paul
>Assignee: Grant Ingersoll
> Fix For: Next
>
> Attachments: SOLR-1566-DocTransformer.patch,
> SOLR-1566-DocTransformer.patch, SOLR-1566-gsi.patch, SOLR-1566-rm.patch,
> SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch,
> SOLR-1566-rm.patch, SOLR-1566.patch, SOLR-1566.patch, SOLR-1566.patch,
> SOLR-1566.patch
>
>
> Currently it is not possible for components to add fields to outgoing
> documents which are not in the the stored fields of the document. This makes
> it cumbersome to add computed fields/metadata .
--
This message is automatically generated by JIRA.
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-1566) Allow components to add fields to outgoing documents
[ https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-1566: Attachment: SOLR-1566-DocTransformer.patch > Allow components to add fields to outgoing documents > > > Key: SOLR-1566 > URL: https://issues.apache.org/jira/browse/SOLR-1566 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Noble Paul >Assignee: Grant Ingersoll > Fix For: Next > > Attachments: SOLR-1566-DocTransformer.patch, > SOLR-1566-DocTransformer.patch, SOLR-1566-gsi.patch, SOLR-1566-rm.patch, > SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch, > SOLR-1566-rm.patch, SOLR-1566.patch, SOLR-1566.patch, SOLR-1566.patch, > SOLR-1566.patch > > > Currently it is not possible for components to add fields to outgoing > documents which are not in the the stored fields of the document. This makes > it cumbersome to add computed fields/metadata . -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5746 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5746/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8467 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2621) Extend Codec to handle also stored fields and term vectors
[ https://issues.apache.org/jira/browse/LUCENE-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004796#comment-13004796 ] Simon Willnauer commented on LUCENE-2621: - FYI - I marked this as gsoc-2011 I think this would make a wonderful project. If any student needs more info go ahead and ask on the dev list. > Extend Codec to handle also stored fields and term vectors > -- > > Key: LUCENE-2621 > URL: https://issues.apache.org/jira/browse/LUCENE-2621 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Affects Versions: 4.0 >Reporter: Andrzej Bialecki > Labels: gsoc2011, lucene-gsoc-11 > > Currently Codec API handles only writing/reading of term-related data, while > stored fields data and term frequency vector data writing/reading is handled > elsewhere. > I propose to extend the Codec API to handle this data as well. -- This message is automatically generated by JIRA. 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-2621) Extend Codec to handle also stored fields and term vectors
[ https://issues.apache.org/jira/browse/LUCENE-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-2621: Labels: gsoc2011 lucene-gsoc-11 (was: ) > Extend Codec to handle also stored fields and term vectors > -- > > Key: LUCENE-2621 > URL: https://issues.apache.org/jira/browse/LUCENE-2621 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Affects Versions: 4.0 >Reporter: Andrzej Bialecki > Labels: gsoc2011, lucene-gsoc-11 > > Currently Codec API handles only writing/reading of term-related data, while > stored fields data and term frequency vector data writing/reading is handled > elsewhere. > I propose to extend the Codec API to handle this data as well. -- This message is automatically generated by JIRA. 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
On Wed, Mar 9, 2011 at 5:48 PM, Grant Ingersoll wrote: > I think we, Lucene committers, need to identify who is willing to mentor. ย ย > In my experience, it is less than 5 hours a week. ย Most of the work is done > as part of the community. ย Sometimes you have to be tough and fail someone (I > did last year) but most of the time, if you take the time to interview the > candidates up front, it is a good experience for everyone. count me in > > I'd add it would be useful to have everyone put the lucene-gsoc-11 label on > their issues too, that way we can quickly find the Lucene ones. done on at least one ;) simon > > Also, feel free to label existing bugs. > > > On Mar 9, 2011, at 2:11 AM, Simon Willnauer wrote: > >> Hey David and all others who want to contribute to GSoC, >> >> the ASF has applied for GSoC 2011 as a mentoring organization. As a >> ASF project we don't need to apply directly though but we need to >> register our ideas now. This works like almost anything in the ASF >> through JIRA. All ideas should be recorded as JIRA tickets ย labeled >> with "gsoc2011". Once this is done it will show up here: >> http://s.apache.org/gsoc2011tasks >> >> Everybody who is interested in GSoC as a mentor or student should now >> read this too http://community.apache.org/gsoc.html >> >> >> Thanks, >> >> Simon >> >> >> >> >> On Thu, Feb 24, 2011 at 12:14 PM, David Nemeskey >> wrote: >>> Please find the implementation plan attached. The word "soon" gets a new >>> meaning when power outages are taken into account. :) >>> >>> As before, comments are welcome. >>> >>> David >>> >>> On Tuesday, February 22, 2011 15:22:57 Simon Willnauer wrote: I think that is good for now. I should get started on codeawards and wrap up our proposals. I hope I can do that this week. simon On Tue, Feb 22, 2011 at 3:16 PM, David Nemeskey wrote: > Hey, > > I have written the proposal. Please let me know if you want more / less > of certain parts. Should I upload it somewhere? > > Implementation plan soon to follow. > > Sorry for the late reply; I have been rather busy these past few weeks. > > David > > On Wednesday, February 02, 2011 10:35:55 Simon Willnauer wrote: >> Hey David, >> >> I saw that you added a tiny line to the GSoC Lucene wiki - thanks for >> that. >> >> On Wed, Feb 2, 2011 at 10:10 AM, David Nemeskey >> >> wrote: >>> Hi guys, >>> >>> Mark, Robert, Simon: thanks for the support! I really hope we can work >>> together this summer (and before that, obviously). >> >> Same here! >> >>> According to http://www.google- >>> melange.com/document/show/gsoc_program/google/gsoc2011/timeline , >>> there's still some time until the application period. So let me use >>> this week to finish my PhD research plan, and get back to you next >>> week. >>> >>> I am not really familiar with how the program works, i.e. how detailed >>> the application description should be, when mentorship is decided, >>> etc. so I guess we will have a lot to talk about. :) >> >> so from a 1ft view it work like this: >> >> 1. Write up a short proposal what your idea is about >> 2. make it public! and publish a implementation plan - how you would >> want to realize your proposal. If you don't follow that 100% in the >> actual impl. don't worry. Its just mean to give us an idea that you >> know what you are doing and where you want to go. something like a 1 >> A4 rough design doc. >> 3. give other people the change to apply for the same suggestion (this >> is how it works though) >> 4 Let the ASF / us assign one or more possible mentors to it >> 5. let us apply for a slot in GSoC (those are limited for organizations) >> 6. get accepted >> 7. rock it! >> >>> (Actually, should we move this discussion private?) >> >> no - we usually do everything in public except of discussion within >> the PMC that are meant to be private for legal reasons or similar >> things. Lets stick to the mailing list for all communication except >> you have something that should clearly not be public. This also give >> other contributors a chance to help and get interested in your work!! >> >> simon >> >>> David >>> Hi David, honestly this sounds fantastic. It would be great to have someone to work with us on this issue! To date, progress is pretty slow-going (minor improvements, cleanups, additional stats here and there)... but we really need all the help we can get, especially from people who have a really good understanding of the various models. In case you are interested, here are some references to discussions about adding more flexibility (with some prototypes etc): http://www
RE: [Lucene.Net] [VOTE] New Directory Layout for Project
Actually what IS contrib.net? It looks like it replaces certain files in Lucene.Net core - are they files better suited to .net? What are they? If they are plugins / additional contributions like snowball, etc - why not just break it out and include the appropriate stuff in contrib? Do we need to specify that they are not avaliable in the java version? > Date: Wed, 9 Mar 2011 22:18:22 +0200 > From: digyd...@gmail.com > To: lucene-net-...@lucene.apache.org > Subject: Re: [Lucene.Net] [VOTE] New Directory Layout for Project > > 0 > > ".Net"s seem to be redundant under /src/contrib/ . It could be something > like > Analyzers > Highlighter > Similarity > ... > > > > (Maybe, we should find a different name for contrib.net. It contains > "contributions specific to Lucene.Net which are not available in > Lucene.java) > > DIGY > > On Wed, Mar 9, 2011 at 9:08 PM, Prescott Nasser wrote: > > > > > Probably just a miss - but under the src/contrib folder you also have a > > number of tests in there... > > > > > > Also, is it necessary to have all the sub folders? For the most part the > > stuff in contrib.net is contrib.net - why the secondary folder? Unless > > that is a requirement of NUnit to have the structure that way it seems a bit > > cluttered. > > > > I would think something like > > > > src/contrib/contrib.net/ > > src/contrib/Snowball.net/ > > > > instead of > > > > src/contrib/contrib.net/contrib.net/ > > src/contrib/snowball/snowball.net/ > > > > I don't know how people feel about that > > > > > > ~P > > > > > > > > > Date: Wed, 9 Mar 2011 13:31:34 -0500 > > > From: mhern...@wickedsoftware.net > > > To: lucene-net-...@lucene.apache.org > > > CC: thowar...@gmail.com > > > Subject: Re: [Lucene.Net] [VOTE] New Directory Layout for Project > > > > > > +1 > > > > > > just a question though. for cmd/bat//sh files for letting people > > executing > > > the build or just executing other tools from the command line, would > > those > > > have a place in /bin or somewhere els? This is that someone can just > > export > > > PATH = / SET PATH= to that one folder and then be able to execute those > > > commands from one location? > > > > > > > > > > > > On Sun, Mar 6, 2011 at 11:27 PM, Troy Howard wrote: > > > > > > > All, > > > > > > > > We'd like to update the project directory structure/layout. > > > > > > > > See below for a proposed layout. I've also uploaded an example which > > > > you can navigate at: > > > > > > > > > > http://people.apache.org/~thoward/Lucene.Net/directory-structure-example > > > > > > > > NOTE: This will not build!! I just put things in the appropriate > > > > places without updating the solution/project files to show how we > > > > might lay things out. Also, I included NUnit as an example of a > > > > third-party dependency that we might include in the repository under > > > > 'lib'. We of course will *not* be distributing NUnit in this manner, > > > > due to licensing restrictions. > > > > > > > > Ok, disclaimer over... > > > > > > > > Please vote on this layout, or suggest a modification or alternative > > > > layout. > > > > > > > > Voting will be open for 72 hours. > > > > > > > > [ ] +1 Use this directory structure exactly as described, or with a > > > > minor modification > > > > [ ] 0 Use a different structure (described in response) > > > > [ ] -1 Do not change the directory structure at all > > > > > > > > > > > > Text description of directory schema: > > > > > > > > Build Files: > > > > > > > > \build > > > > \build\VS2008 > > > > \build\VS2010 > > > > > > > > > > > > Source Projects: > > > > > > > > \src > > > > \src\contrib > > > > \src\core > > > > \src\demo > > > > \src\contrib\ > > > > \src\core\ > > > > \src\demo\ > > > > > > > > > > > > Test Projects: > > > > > > > > \test > > > > \test\contrib > > > > \test\core > > > > \test\demo > > > > \test\contrib\ > > > > \test\core\ > > > > \test\demo\ > > > > > > > > > > > > Product Documentation: > > > > > > > > \doc > > > > \doc\contrib > > > > \doc\core > > > > \doc\demo > > > > \doc\contrib\ > > > > \doc\core\ > > > > \doc\demo\ > > > > > > > > > > > > Third-Party Dependencies: > > > > > > > > \lib > > > > \lib\ > > > > \lib\\ > > > > \lib\\\ > > > > > > > > > > > > Binary Builds: > > > > > > > > \bin > > > > \bin\contrib > > > > \bin\core > > > > \bin\demo > > > > \bin\contrib\ > > > > \bin\core\ > > > > \bin\demo\ > > > >
[jira] Updated: (LUCENE-2878) Allow Scorer to expose positions and payloads aka. nuke spans
[ https://issues.apache.org/jira/browse/LUCENE-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-2878: Labels: gsoc2011 (was: ) > Allow Scorer to expose positions and payloads aka. nuke spans > -- > > Key: LUCENE-2878 > URL: https://issues.apache.org/jira/browse/LUCENE-2878 > Project: Lucene - Java > Issue Type: Improvement > Components: Search >Affects Versions: Bulk Postings branch >Reporter: Simon Willnauer >Assignee: Simon Willnauer > Labels: gsoc2011 > Attachments: LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, > LUCENE-2878.patch > > > Currently we have two somewhat separate types of queries, the one which can > make use of positions (mainly spans) and payloads (spans). Yet Span*Query > doesn't really do scoring comparable to what other queries do and at the end > of the day they are duplicating lot of code all over lucene. Span*Queries are > also limited to other Span*Query instances such that you can not use a > TermQuery or a BooleanQuery with SpanNear or anthing like that. > Beside of the Span*Query limitation other queries lacking a quiet interesting > feature since they can not score based on term proximity since scores doesn't > expose any positional information. All those problems bugged me for a while > now so I stared working on that using the bulkpostings API. I would have done > that first cut on trunk but TermScorer is working on BlockReader that do not > expose positions while the one in this branch does. I started adding a new > Positions class which users can pull from a scorer, to prevent unnecessary > positions enums I added ScorerContext#needsPositions and eventually > Scorere#needsPayloads to create the corresponding enum on demand. Yet, > currently only TermQuery / TermScorer implements this API and other simply > return null instead. > To show that the API really works and our BulkPostings work fine too with > positions I cut over TermSpanQuery to use a TermScorer under the hood and > nuked TermSpans entirely. A nice sideeffect of this was that the Position > BulkReading implementation got some exercise which now :) work all with > positions while Payloads for bulkreading are kind of experimental in the > patch and those only work with Standard codec. > So all spans now work on top of TermScorer ( I truly hate spans since today ) > including the ones that need Payloads (StandardCodec ONLY)!! I didn't bother > to implement the other codecs yet since I want to get feedback on the API and > on this first cut before I go one with it. I will upload the corresponding > patch in a minute. > I also had to cut over SpanQuery.getSpans(IR) to > SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk > first but after that pain today I need a break first :). > The patch passes all core tests > (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't > look into the MemoryIndex BulkPostings API yet) -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5745 - Failure
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5745/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8470 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Resolved: (SOLR-2413) Cleanup XMLWriter, remove support for version < 2.2
[ https://issues.apache.org/jira/browse/SOLR-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-2413. - Resolution: Fixed Assignee: Ryan McKinley > Cleanup XMLWriter, remove support for version < 2.2 > --- > > Key: SOLR-2413 > URL: https://issues.apache.org/jira/browse/SOLR-2413 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2413-remove-XMLWriter-version.patch, > SOLR-2413-remove-XMLWriter-version.patch > > > XMLWriter includes support for a a pre 1.0 response format where multi-valued > fields are not collected together in an tag. > One problem is that many tests assume this format. > In 4.0, lets remove support for the old style XML formats -- This message is automatically generated by JIRA. 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-2413) Cleanup XMLWriter, remove support for version < 2.2
[ https://issues.apache.org/jira/browse/SOLR-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004762#comment-13004762 ] Ryan McKinley commented on SOLR-2413: - added to /trunk in #1079963 and updated wiki > Cleanup XMLWriter, remove support for version < 2.2 > --- > > Key: SOLR-2413 > URL: https://issues.apache.org/jira/browse/SOLR-2413 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2413-remove-XMLWriter-version.patch, > SOLR-2413-remove-XMLWriter-version.patch > > > XMLWriter includes support for a a pre 1.0 response format where multi-valued > fields are not collected together in an tag. > One problem is that many tests assume this format. > In 4.0, lets remove support for the old style XML formats -- This message is automatically generated by JIRA. 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-2416) Solr Cell & DataImport Tika handler broken - fails to index Zip file contents
[ https://issues.apache.org/jira/browse/SOLR-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayendra Patil updated SOLR-2416: - Attachment: SOLR-2416_ExtractingDocumentLoader.patch Fix attached. > Solr Cell & DataImport Tika handler broken - fails to index Zip file contents > - > > Key: SOLR-2416 > URL: https://issues.apache.org/jira/browse/SOLR-2416 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler, contrib - Solr Cell (Tika > extraction) >Affects Versions: 4.0 >Reporter: Jayendra Patil > Attachments: SOLR-2416_ExtractingDocumentLoader.patch > > > Working with the latest Solr Trunk code and seems the Tika handlers for Solr > Cell (ExtractingDocumentLoader.java) and Data Import handler > (TikaEntityProcessor.java) fails to index the zip file contents again. > It just indexes the file names again. > This issue was addressed some time back, late last year, but seems to have > reappeared with the latest code. > Jira for the Data Import handler part with the patch and the testcase - > https://issues.apache.org/jira/browse/SOLR-2332. -- This message is automatically generated by JIRA. 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-2416) Solr Cell & DataImport Tika handler broken - fails to index Zip file contents
Solr Cell & DataImport Tika handler broken - fails to index Zip file contents - Key: SOLR-2416 URL: https://issues.apache.org/jira/browse/SOLR-2416 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler, contrib - Solr Cell (Tika extraction) Affects Versions: 4.0 Reporter: Jayendra Patil Working with the latest Solr Trunk code and seems the Tika handlers for Solr Cell (ExtractingDocumentLoader.java) and Data Import handler (TikaEntityProcessor.java) fails to index the zip file contents again. It just indexes the file names again. This issue was addressed some time back, late last year, but seems to have reappeared with the latest code. Jira for the Data Import handler part with the patch and the testcase - https://issues.apache.org/jira/browse/SOLR-2332. -- This message is automatically generated by JIRA. 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-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved SOLR-2381. - Resolution: Fixed Fix Version/s: 3.2 Committed 3.x revision: 1079954 Committed 3.1 revision: 1079955 > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 3.2, 4.0 > > Attachments: SOLR-2381-3.x+3.1.patch, SOLR-2381.patch, > SOLR-2381_take2.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, SOLR-ServletOutputWriter.patch, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-JETTY-1340.jar, > jetty-6.1.26-patched-SOLR-2381.jar, jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5743 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5743/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8461 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004745#comment-13004745 ] Robert Muir commented on SOLR-2381: --- OK, i committed my patch to trunk: Committed revision 1079949. Uwe, can you take it from here for 3.x and 3.1? > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381-3.x+3.1.patch, SOLR-2381.patch, > SOLR-2381_take2.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, SOLR-ServletOutputWriter.patch, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-JETTY-1340.jar, > jetty-6.1.26-patched-SOLR-2381.jar, jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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: [Lucene.Net] [VOTE] New Directory Layout for Project
Probably just a miss - but under the src/contrib folder you also have a number of tests in there... Also, is it necessary to have all the sub folders? For the most part the stuff in contrib.net is contrib.net - why the secondary folder? Unless that is a requirement of NUnit to have the structure that way it seems a bit cluttered. I would think something like src/contrib/contrib.net/ src/contrib/Snowball.net/ instead of src/contrib/contrib.net/contrib.net/ src/contrib/snowball/snowball.net/ I don't know how people feel about that ~P > Date: Wed, 9 Mar 2011 13:31:34 -0500 > From: mhern...@wickedsoftware.net > To: lucene-net-...@lucene.apache.org > CC: thowar...@gmail.com > Subject: Re: [Lucene.Net] [VOTE] New Directory Layout for Project > > +1 > > just a question though. for cmd/bat//sh files for letting people executing > the build or just executing other tools from the command line, would those > have a place in /bin or somewhere els? This is that someone can just export > PATH = / SET PATH= to that one folder and then be able to execute those > commands from one location? > > > > On Sun, Mar 6, 2011 at 11:27 PM, Troy Howard wrote: > > > All, > > > > We'd like to update the project directory structure/layout. > > > > See below for a proposed layout. I've also uploaded an example which > > you can navigate at: > > > > http://people.apache.org/~thoward/Lucene.Net/directory-structure-example > > > > NOTE: This will not build!! I just put things in the appropriate > > places without updating the solution/project files to show how we > > might lay things out. Also, I included NUnit as an example of a > > third-party dependency that we might include in the repository under > > 'lib'. We of course will *not* be distributing NUnit in this manner, > > due to licensing restrictions. > > > > Ok, disclaimer over... > > > > Please vote on this layout, or suggest a modification or alternative > > layout. > > > > Voting will be open for 72 hours. > > > > [ ] +1 Use this directory structure exactly as described, or with a > > minor modification > > [ ] 0 Use a different structure (described in response) > > [ ] -1 Do not change the directory structure at all > > > > > > Text description of directory schema: > > > > Build Files: > > > > \build > > \build\VS2008 > > \build\VS2010 > > > > > > Source Projects: > > > > \src > > \src\contrib > > \src\core > > \src\demo > > \src\contrib\ > > \src\core\ > > \src\demo\ > > > > > > Test Projects: > > > > \test > > \test\contrib > > \test\core > > \test\demo > > \test\contrib\ > > \test\core\ > > \test\demo\ > > > > > > Product Documentation: > > > > \doc > > \doc\contrib > > \doc\core > > \doc\demo > > \doc\contrib\ > > \doc\core\ > > \doc\demo\ > > > > > > Third-Party Dependencies: > > > > \lib > > \lib\ > > \lib\\ > > \lib\\\ > > > > > > Binary Builds: > > > > \bin > > \bin\contrib > > \bin\core > > \bin\demo > > \bin\contrib\ > > \bin\core\ > > \bin\demo\ > >
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5742 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5742/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8457 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (SOLR-2415) Change XMLWriter version parameter to "wt.xml.version"
Change XMLWriter version parameter to "wt.xml.version" -- Key: SOLR-2415 URL: https://issues.apache.org/jira/browse/SOLR-2415 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Priority: Trivial Fix For: 4.0 The XMLWriter has a parameter called 'version'. This controls some specifics about how the XMLWriter works. Using the parameter name 'version' made sense back when the XMLWriter was the only option, but with all the various writers and different places where 'version' makes sense, I think we should change this parameter name to "wt.xml.version" so that it specifically refers to the XMLWriter. -- This message is automatically generated by JIRA. 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-2414) Remove CESU-Hack from PHPSerializedResponseWriter
Remove CESU-Hack from PHPSerializedResponseWriter - Key: SOLR-2414 URL: https://issues.apache.org/jira/browse/SOLR-2414 Project: Solr Issue Type: Task Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 3.1, 3.2, 4.0 When SOLR-2381 is committed we no longer use the Writer supplied by the underlying Servlet Container. We can therefore assume that UTF-8 is not CESU, so the hack in PHPSerilaizedResponseWriter is obsolete. We should remove it or at least disable the system property, as this is explained in the Wiki and some people may already used it, now failing with 3.1, as we always produce UTF-8 and if the CESU property is true, the serialized output is suddenly wrong. -- This message is automatically generated by JIRA. 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-2413) Cleanup XMLWriter, remove support for version < 2.2
[ https://issues.apache.org/jira/browse/SOLR-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-2413: Attachment: SOLR-2413-remove-XMLWriter-version.patch updated patch that does not remove the 'version' tag, just drops support for version less then 2.2 I'll make a new ticket to drop the version param > Cleanup XMLWriter, remove support for version < 2.2 > --- > > Key: SOLR-2413 > URL: https://issues.apache.org/jira/browse/SOLR-2413 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2413-remove-XMLWriter-version.patch, > SOLR-2413-remove-XMLWriter-version.patch > > > XMLWriter includes support for a a pre 1.0 response format where multi-valued > fields are not collected together in an tag. > One problem is that many tests assume this format. > In 4.0, lets remove support for the old style XML formats -- This message is automatically generated by JIRA. 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-2413) Cleanup XMLWriter, remove support for version < 2.2
[ https://issues.apache.org/jira/browse/SOLR-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004728#comment-13004728 ] Ryan McKinley commented on SOLR-2413: - will need to update: http://wiki.apache.org/solr/XMLResponseFormat > Cleanup XMLWriter, remove support for version < 2.2 > --- > > Key: SOLR-2413 > URL: https://issues.apache.org/jira/browse/SOLR-2413 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2413-remove-XMLWriter-version.patch, > SOLR-2413-remove-XMLWriter-version.patch > > > XMLWriter includes support for a a pre 1.0 response format where multi-valued > fields are not collected together in an tag. > One problem is that many tests assume this format. > In 4.0, lets remove support for the old style XML formats -- This message is automatically generated by JIRA. 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-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-2381: Attachment: (was: SOLR-2381-3.x+3.1.patch) > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381-3.x+3.1.patch, SOLR-2381.patch, > SOLR-2381_take2.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, SOLR-ServletOutputWriter.patch, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-JETTY-1340.jar, > jetty-6.1.26-patched-SOLR-2381.jar, jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-2381: Attachment: SOLR-2381-3.x+3.1.patch Again revised (one optimization in the deprecated UpdateServlet). Sorry for multiple patch posts. Its now ready to commit (all branches). > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381-3.x+3.1.patch, SOLR-2381-3.x+3.1.patch, > SOLR-2381.patch, SOLR-2381_take2.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, SOLR-ServletOutputWriter.patch, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-JETTY-1340.jar, > jetty-6.1.26-patched-SOLR-2381.jar, jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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-2413) Cleanup XMLWriter, remove support for version < 2.2
[ https://issues.apache.org/jira/browse/SOLR-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-2413: Description: XMLWriter includes support for a a pre 1.0 response format where multi-valued fields are not collected together in an tag. One problem is that many tests assume this format. In 4.0, lets remove support for the old style XML formats was: XMLWriter includes support for a a pre 1.0 response format where multi-valued fields are not collected together in an tag. One problem is that many tests assume this format. Lets remove this in 4.0 Summary: Cleanup XMLWriter, remove support for version < 2.2 (was: Cleanup XMLWriter, remove 'version' parameter) > Cleanup XMLWriter, remove support for version < 2.2 > --- > > Key: SOLR-2413 > URL: https://issues.apache.org/jira/browse/SOLR-2413 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2413-remove-XMLWriter-version.patch > > > XMLWriter includes support for a a pre 1.0 response format where multi-valued > fields are not collected together in an tag. > One problem is that many tests assume this format. > In 4.0, lets remove support for the old style XML formats -- This message is automatically generated by JIRA. 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-2945) Surround Query doesn't properly handle equals/hashcode
[ https://issues.apache.org/jira/browse/LUCENE-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004714#comment-13004714 ] Paul Elschot commented on LUCENE-2945: -- bq. The Query class already is cloneable so it needs to support what the QueryUtils is doing. Would that include throwing a CloneNotSupportedException? For these classes I could not find a better name in their package when I wrote this. Also I wanted the possibility to generate a query for another engine, so I needed an (factory) layer between the parser and the final query. There is already a BasicQueryFactory in there that generates Lucene TermQuery and SpanTermQuery leaf objects, so perhaps the other Lucene Query objects could also be made there. These others are objects of the inner classes that need hashCode() and equals() here, and Lucene BooleanQuery objects. This could be a spin off issue. > Surround Query doesn't properly handle equals/hashcode > -- > > Key: LUCENE-2945 > URL: https://issues.apache.org/jira/browse/LUCENE-2945 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 3.0.3, 3.1, 4.0 >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 3.1.1, 4.0 > > Attachments: LUCENE-2945-partial1.patch, LUCENE-2945.patch, > LUCENE-2945.patch, LUCENE-2945.patch > > > In looking at using the surround queries with Solr, I am hitting issues > caused by collisions due to equals/hashcode not being implemented on the > anonymous inner classes that are created by things like DistanceQuery (branch > 3.x, near line 76) -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5741 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5741/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8474 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-2381: Attachment: SOLR-2381-3.x+3.1.patch Patch for 3.1 and 3.x, revised & cleaned up as described before > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381-3.x+3.1.patch, SOLR-2381.patch, > SOLR-2381_take2.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, SOLR-ServletOutputWriter.patch, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-JETTY-1340.jar, > jetty-6.1.26-patched-SOLR-2381.jar, jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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: [Lucene.Net] [VOTE] New Directory Layout for Project
+1 just a question though. for cmd/bat//sh files for letting people executing the build or just executing other tools from the command line, would those have a place in /bin or somewhere els? This is that someone can just export PATH = / SET PATH= to that one folder and then be able to execute those commands from one location? On Sun, Mar 6, 2011 at 11:27 PM, Troy Howard wrote: > All, > > We'd like to update the project directory structure/layout. > > See below for a proposed layout. I've also uploaded an example which > you can navigate at: > > http://people.apache.org/~thoward/Lucene.Net/directory-structure-example > > NOTE: This will not build!! I just put things in the appropriate > places without updating the solution/project files to show how we > might lay things out. Also, I included NUnit as an example of a > third-party dependency that we might include in the repository under > 'lib'. We of course will *not* be distributing NUnit in this manner, > due to licensing restrictions. > > Ok, disclaimer over... > > Please vote on this layout, or suggest a modification or alternative > layout. > > Voting will be open for 72 hours. > > [ ] +1 Use this directory structure exactly as described, or with a > minor modification > [ ] 0 Use a different structure (described in response) > [ ] -1 Do not change the directory structure at all > > > Text description of directory schema: > > Build Files: > > \build > \build\VS2008 > \build\VS2010 > > > Source Projects: > > \src > \src\contrib > \src\core > \src\demo > \src\contrib\ > \src\core\ > \src\demo\ > > > Test Projects: > > \test > \test\contrib > \test\core > \test\demo > \test\contrib\ > \test\core\ > \test\demo\ > > > Product Documentation: > > \doc > \doc\contrib > \doc\core > \doc\demo > \doc\contrib\ > \doc\core\ > \doc\demo\ > > > Third-Party Dependencies: > > \lib > \lib\ > \lib\\ > \lib\\\ > > > Binary Builds: > > \bin > \bin\contrib > \bin\core > \bin\demo > \bin\contrib\ > \bin\core\ > \bin\demo\ >
[jira] Commented: (SOLR-2413) Cleanup XMLWriter, remove 'version' parameter
[ https://issues.apache.org/jira/browse/SOLR-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004705#comment-13004705 ] Ryan McKinley commented on SOLR-2413: - I'd like to commit this soon... it will make a working version of SOLR-1566 much easier > Cleanup XMLWriter, remove 'version' parameter > - > > Key: SOLR-2413 > URL: https://issues.apache.org/jira/browse/SOLR-2413 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2413-remove-XMLWriter-version.patch > > > XMLWriter includes support for a a pre 1.0 response format where multi-valued > fields are not collected together in an tag. > One problem is that many tests assume this format. > Lets remove this in 4.0 -- This message is automatically generated by JIRA. 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-2413) Cleanup XMLWriter, remove 'version' parameter
[
https://issues.apache.org/jira/browse/SOLR-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-2413:
Attachment: SOLR-2413-remove-XMLWriter-version.patch
Here is a patch that removes support for the old version, and fixes tests that
depends on it.
Most of the test chagnes look like this:
{code}
-assertQ(req("id:100"),"//str[@name='my_s'][.='quoted']");
+assertQ(req("id:100"),"//arr[@name='my_s']/str[.='quoted']");
{code}
that is rather then just str[@name...] it is now arr[@name...]/str
This removes the multi version support added in SOLR-59
> Cleanup XMLWriter, remove 'version' parameter
> -
>
> Key: SOLR-2413
> URL: https://issues.apache.org/jira/browse/SOLR-2413
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2413-remove-XMLWriter-version.patch
>
>
> XMLWriter includes support for a a pre 1.0 response format where multi-valued
> fields are not collected together in an tag.
> One problem is that many tests assume this format.
> Lets remove this in 4.0
--
This message is automatically generated by JIRA.
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-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-2381: Attachment: (was: SOLR-2381-3.x+3.1.patch) > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381.patch, SOLR-2381_take2.patch, > SOLR-2381_xmltest.patch, SOLR-ServletOutputWriter.patch, > SOLR-ServletOutputWriter.patch, jetty-6.1.26-patched-JETTY-1340.jar, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-SOLR-2381.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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-2381) The included jetty server does not support UTF-8
[
https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004688#comment-13004688
]
Yonik Seeley commented on SOLR-2381:
Awesome news guys... not using Jetty's writers did in fact result in
performance improvements!
This was a simple test that requested 500 docs per request (hitting all the
caches to try and isolate writer performance). Performance improvements of
almost 30% for XML!
{code}
=== trunk, using jetty's writers ==
wt=javabin
qps: 1297
50% = 7938
qps: 1317
50% = 8114
qps: 1319
50% = 8395
qps: 1349
50% = 8160
qps: 1293
50% = 8922
wt=xml
qps: 634
50% = 21983
qps: 713
50% = 22138
qps: 718
50% = 21594
qps: 717
50% = 20935
qps: 741
50% = 20546
wt=json
qps: 945
50% = 15500
qps: 938
50% = 16812
qps: 921
50% = 15467
qps: 930
50% = 15337
qps: 932
50% = 15447
wt=python
qps: 1024
50% = 12975
qps: 1046
50% = 12883
qps: 996
50% = 14033
qps: 988
50% = 14295
qps: 1013
50% = 13206
wt=ruby
qps: 893
50% = 18897
qps: 878
50% = 18943
qps: 871
50% = 18413
qps: 857
50% = 19190
qps: 902
50% = 18554
= trunk with SOLR-2381_take2.patch (not using jetty's writers)
===
wt=javabin
qps: 1315
50% = 7884
qps: 1285
50% = 8946
qps: 1280
50% = 8083
qps: 1340
50% = 7899
qps: 1310
50% = 7872
wt=xml
qps: 773
50% = 16006
qps: 938
50% = 14316
qps: 946
50% = 15709
qps: 956
50% = 14735
qps: 950
50% = 14825
wt=json
qps: 1127
50% = 10168
qps: 1104
50% = 11147
qps: 1166
50% = 10691
qps: 1100
50% = 10654
qps: 1138
50% = 10437
wt=python
qps: 1004
50% = 12502
qps: 1033
50% = 13525
qps: 1007
50% = 13762
qps: 1043
50% = 11854
qps: 985
50% = 13289
wt=ruby
qps: 1164
50% = 9457
qps: 1175
50% = 9994
qps: 1212
50% = 9437
qps: 1203
50% = 9756
qps: 1197
50% = 10640
{code}
> The included jetty server does not support UTF-8
>
>
> Key: SOLR-2381
> URL: https://issues.apache.org/jira/browse/SOLR-2381
> Project: Solr
> Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Blocker
> Fix For: 3.1, 4.0
>
> Attachments: SOLR-2381-3.x+3.1.patch, SOLR-2381.patch,
> SOLR-2381_take2.patch, SOLR-2381_xmltest.patch,
> SOLR-ServletOutputWriter.patch, SOLR-ServletOutputWriter.patch,
> jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-JETTY-1340.jar,
> jetty-6.1.26-patched-SOLR-2381.jar, jetty-util-6.1.26-patched-JETTY-1340.jar,
> jetty-util-6.1.26-patched-JETTY-1340.jar,
> jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh,
> utf8enhanced.xml
>
>
> Some background here:
> http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene
> Some possible solutions:
> * wait and see if we get resolution on
> http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure
> where jetty is being maintained (there is a separate jetty project at
> eclipse.org with another bugtracker, but the older releases are at codehaus).
> * include a patched version of jetty with correct utf-8, using that patch.
> * remove jetty and include a different container instead.
--
This message is automatically generated by JIRA.
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-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-2381: Attachment: SOLR-2381-3.x+3.1.patch Here the patch for 3.x and 3.1, also fixing the other Servlets to use only byte streams when reading/writing. This also contains the rest of issue SOLR-2347 to fix deprecated parts of XML using Readers (legacyUpdateRequest). > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381-3.x+3.1.patch, SOLR-2381.patch, > SOLR-2381_take2.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, SOLR-ServletOutputWriter.patch, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-JETTY-1340.jar, > jetty-6.1.26-patched-SOLR-2381.jar, jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5740 - Failure
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5740/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8499 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [HUDSON] Lucene-Solr-tests-only-trunk - Build # 5738 - Still Failing
By the way, I've been seeing this for a while in my local (this test often causes my jre to crash). So its nothing wrong with hudson, I just thought it might have been my computer since nobody else complained. On Wed, Mar 9, 2011 at 12:13 PM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5738/ > > 2 tests failed. > FAILED: ย > org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren > > Error Message: > Forked Java VM exited abnormally. Please note the time in the report does not > reflect the time until the VM exit. > > Stack Trace: > junit.framework.AssertionFailedError: Forked Java VM exited abnormally. > Please note the time in the report does not reflect the time until the VM > exit. > ย ย ย ย at java.lang.Thread.run(Thread.java:636) > > > FAILED: ย TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. > > Error Message: > > > Stack Trace: > Test report file > /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml > was length 0 > > > > Build Log (for compile errors): > [...truncated 8466 lines...] > > > > - > 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: real reason for java.lang.NoClassDefFoundError ?
On Wed, 9 Mar 2011, Anton Korosov wrote:
I'm trying to use BEAM/Visat software in Python. It is a large project
with > 100 JARs. I try to 'convert' these JARs into Python specifying each
after --jar option:
python -m jcc.__init__ \
--python testbeam \
--jar /host/local/beam-4.8/modules/beam-landsat-reader-1.2.1.jar \
--jar /host/local/beam-4.8/modules/beam-meris-boreal-lakes-1.4.2.jar \
--jar /host/local/beam-4.8/modules/beam-meris-case2-core-1.4.2.jar \
--jar /host/local/beam-4.8/modules/beam-meris-case2-regional-1.4.2.jar \
--jar /host/local/beam-4.8/modules/beam-meris-cloud-1.5.203.jar \
--jar /host/local/beam-4.8/modules/beam-meris-eutrophic-lakes-1.4.2.jar \
--jar /host/local/beam-4.8/modules/beam-merisl3-reader-1.1.jar \
...
If any of these jar files depend on other jar files not listed with --jar,
such as lucene's (as you hint below with QueryParser not being found) then
you must list lucene's jar on --classpath or ensure it's on the CLASSPATH
env var.
Also, you only need to list --jar files whose public classes you want to
make accessible from Python. Dependencies can be listed with --classpath or
--include.
See output of 'python -m jcc.__main__' for details about JCC's command line
flags.
Andi..
However I immediately got error:
While loading com/jidesoft/lucene/c$1
Traceback (most recent call last):
File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File
"/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__init__.py",
line 32, in
import jcc.__main__
File
"/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py",
line 98, in
cpp.jcc(sys.argv)
File
"/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
line 501, in jcc
cls = findClass(className.replace('.', '/'), iii)
File
"/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
line 73, in findClass
cls = _findClass(className)
jcc.cpp.JavaError: java.lang.NoClassDefFoundError:
org/apache/lucene/queryParser/QueryParser
Java stacktrace:
java.lang.NoClassDefFoundError: org/apache/lucene/queryParser/QueryParser
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Caused by: java.lang.ClassNotFoundException:
org.apache.lucene.queryParser.QueryParser
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
... 11 more
Why is that? Does that mean that the class com/jidesoft/lucene/c$1 has
reference to a class org/apache/lucene/queryParser/QueryParser but the
latter is not given in any JAR?
How can such situation occur if Beam/Visat works perfectly? Could it be
that Beam/Visat simply don't call
org/apache/lucene/queryParser/QueryParser ?
What should I do? Download a JAR with
org/apache/lucene/queryParser/QueryParser or rather --exclude
com/jidesoft/lucene/c ? Will it influence performance of the Python
module?
Thank you very much for any ideas/suggestions!
Anton
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5738 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5738/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8466 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2413) Cleanup XMLWriter, remove 'version' parameter
[ https://issues.apache.org/jira/browse/SOLR-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-2413: Fix Version/s: 4.0 > Cleanup XMLWriter, remove 'version' parameter > - > > Key: SOLR-2413 > URL: https://issues.apache.org/jira/browse/SOLR-2413 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > > XMLWriter includes support for a a pre 1.0 response format where multi-valued > fields are not collected together in an tag. > One problem is that many tests assume this format. > Lets remove this in 4.0 -- This message is automatically generated by JIRA. 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-2413) Cleanup XMLWriter, remove 'version' parameter
Cleanup XMLWriter, remove 'version' parameter - Key: SOLR-2413 URL: https://issues.apache.org/jira/browse/SOLR-2413 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Priority: Minor XMLWriter includes support for a a pre 1.0 response format where multi-valued fields are not collected together in an tag. One problem is that many tests assume this format. Lets remove this in 4.0 -- This message is automatically generated by JIRA. 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-2945) Surround Query doesn't properly handle equals/hashcode
[ https://issues.apache.org/jira/browse/LUCENE-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004655#comment-13004655 ] Grant Ingersoll commented on LUCENE-2945: - The Query class already is cloneable so it needs to support what the QueryUtils is doing. I think it is the anonymous inner class (or in my case, just the inner class) that is the one that matters for all of this. It is an instance of Query and thus needs a proper equals/hashcode. I don't really care about the outer containing classes other than I think it is a misnomer to call them Query classes when they really are factory classes for creating Lucene Queries. > Surround Query doesn't properly handle equals/hashcode > -- > > Key: LUCENE-2945 > URL: https://issues.apache.org/jira/browse/LUCENE-2945 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 3.0.3, 3.1, 4.0 >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 3.1.1, 4.0 > > Attachments: LUCENE-2945-partial1.patch, LUCENE-2945.patch, > LUCENE-2945.patch, LUCENE-2945.patch > > > In looking at using the surround queries with Solr, I am hitting issues > caused by collisions due to equals/hashcode not being implemented on the > anonymous inner classes that are created by things like DistanceQuery (branch > 3.x, near line 76) -- This message is automatically generated by JIRA. 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-2955) Add utitily class to manage NRT reopening
[ https://issues.apache.org/jira/browse/LUCENE-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-2955: --- Attachment: LUCENE-2955.patch Patch. The sources are in Lucene core now but I think we should commit into contrib somewhere since this is really a "wrapper" around core APIs. > Add utitily class to manage NRT reopening > - > > Key: LUCENE-2955 > URL: https://issues.apache.org/jira/browse/LUCENE-2955 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 3.2, 4.0 > > Attachments: LUCENE-2955.patch > > > I created a simple class, NRTManager, that tries to abstract away some > of the reopen logic when using NRT readers. > You give it your IW, tell it min and max nanoseconds staleness you can > tolerate, and it privately runs a reopen thread to periodically reopen > the searcher. > It subsumes the SearcherManager from LIA2. Besides running the reopen > thread, it also adds the notion of a "generation" containing changes > you've made. So eg it has addDocument, returning a long. You can > then take that long value and pass it back to the getSearcher method > and getSearcher will return a searcher that reflects the changes made > in that generation. > This gives your app the freedom to force "immediate" consistency (ie > wait for the reopen) only for those searches that require it, like a > verifier that adds a doc and then immediately searches for it, but > also use "eventual consistency" for other searches. > I want to also add support for the new "applyDeletions" option when > pulling an NRT reader. > Also, this is very new and I'm sure buggy -- the concurrency is either > wrong over overly-locking. But it's a start... -- This message is automatically generated by JIRA. 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-2945) Surround Query doesn't properly handle equals/hashcode
[ https://issues.apache.org/jira/browse/LUCENE-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004646#comment-13004646 ] Paul Elschot commented on LUCENE-2945: -- As to the patch of 5 March, QueryUtils uses clone() to test hashCode() and I'd rather not support clone() because of the presence of the basic query factory and because I don't expect reparsing to be a problem to start a clone. Also implementing equals() on an anonymous inner class is not easily possible when hashCode() uses a "qualified this", because equals() would need the same qualification on the other object and I don't see a way to have that. An explicit reference from an object of a named static inner class gets around that, and I am curious to know whether equals() could be implemented without an explicit reference in this case. I have started coding in these directions, once some tests pass I'll post a patch. > Surround Query doesn't properly handle equals/hashcode > -- > > Key: LUCENE-2945 > URL: https://issues.apache.org/jira/browse/LUCENE-2945 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 3.0.3, 3.1, 4.0 >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 3.1.1, 4.0 > > Attachments: LUCENE-2945-partial1.patch, LUCENE-2945.patch, > LUCENE-2945.patch, LUCENE-2945.patch > > > In looking at using the surround queries with Solr, I am hitting issues > caused by collisions due to equals/hashcode not being implemented on the > anonymous inner classes that are created by things like DistanceQuery (branch > 3.x, near line 76) -- This message is automatically generated by JIRA. 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-2955) Add utitily class to manage NRT reopening
Add utitily class to manage NRT reopening - Key: LUCENE-2955 URL: https://issues.apache.org/jira/browse/LUCENE-2955 Project: Lucene - Java Issue Type: Improvement Components: Index Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.2, 4.0 I created a simple class, NRTManager, that tries to abstract away some of the reopen logic when using NRT readers. You give it your IW, tell it min and max nanoseconds staleness you can tolerate, and it privately runs a reopen thread to periodically reopen the searcher. It subsumes the SearcherManager from LIA2. Besides running the reopen thread, it also adds the notion of a "generation" containing changes you've made. So eg it has addDocument, returning a long. You can then take that long value and pass it back to the getSearcher method and getSearcher will return a searcher that reflects the changes made in that generation. This gives your app the freedom to force "immediate" consistency (ie wait for the reopen) only for those searches that require it, like a verifier that adds a doc and then immediately searches for it, but also use "eventual consistency" for other searches. I want to also add support for the new "applyDeletions" option when pulling an NRT reader. Also, this is very new and I'm sure buggy -- the concurrency is either wrong over overly-locking. But it's a start... -- This message is automatically generated by JIRA. 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-17) XSD for solr requests/responses
[ https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004642#comment-13004642 ] Bill Bell commented on SOLR-17: --- Can we have a version of XSD for each released version of SOLR? solr14.xsd solr141.xsd solr31.xsd solrtrunk.xsd This would be very helpful, and we can keep it pretty open for now. Bill > XSD for solr requests/responses > --- > > Key: SOLR-17 > URL: https://issues.apache.org/jira/browse/SOLR-17 > Project: Solr > Issue Type: Improvement >Reporter: Mike Baranczak >Priority: Minor > Attachments: SOLR-17.Mattmann.121709.patch.txt, > UselessRequestHandler.java, solr-complex.xml, solr-rev2.xsd, solr.xsd > > > Attaching an XML schema definition for the responses and the update requests. > I needed to do this for myself anyway, so I might as well contribute it to > the project. > At the moment, I have no plans to write an XSD for the config documents, but > it wouldn't be a bad idea. > TODO: change the schema URL. I'm guessing that Apache already has some sort > of naming convention for these? -- This message is automatically generated by JIRA. 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
I think we, Lucene committers, need to identify who is willing to mentor.In my experience, it is less than 5 hours a week. Most of the work is done as part of the community. Sometimes you have to be tough and fail someone (I did last year) but most of the time, if you take the time to interview the candidates up front, it is a good experience for everyone. I'd add it would be useful to have everyone put the lucene-gsoc-11 label on their issues too, that way we can quickly find the Lucene ones. Also, feel free to label existing bugs. On Mar 9, 2011, at 2:11 AM, Simon Willnauer wrote: > Hey David and all others who want to contribute to GSoC, > > the ASF has applied for GSoC 2011 as a mentoring organization. As a > ASF project we don't need to apply directly though but we need to > register our ideas now. This works like almost anything in the ASF > through JIRA. All ideas should be recorded as JIRA tickets labeled > with "gsoc2011". Once this is done it will show up here: > http://s.apache.org/gsoc2011tasks > > Everybody who is interested in GSoC as a mentor or student should now > read this too http://community.apache.org/gsoc.html > > > Thanks, > > Simon > > > > > On Thu, Feb 24, 2011 at 12:14 PM, David Nemeskey > wrote: >> Please find the implementation plan attached. The word "soon" gets a new >> meaning when power outages are taken into account. :) >> >> As before, comments are welcome. >> >> David >> >> On Tuesday, February 22, 2011 15:22:57 Simon Willnauer wrote: >>> I think that is good for now. I should get started on codeawards and >>> wrap up our proposals. I hope I can do that this week. >>> >>> simon >>> >>> On Tue, Feb 22, 2011 at 3:16 PM, David Nemeskey >>> >>> wrote: Hey, I have written the proposal. Please let me know if you want more / less of certain parts. Should I upload it somewhere? Implementation plan soon to follow. Sorry for the late reply; I have been rather busy these past few weeks. David On Wednesday, February 02, 2011 10:35:55 Simon Willnauer wrote: > Hey David, > > I saw that you added a tiny line to the GSoC Lucene wiki - thanks for > that. > > On Wed, Feb 2, 2011 at 10:10 AM, David Nemeskey > > wrote: >> Hi guys, >> >> Mark, Robert, Simon: thanks for the support! I really hope we can work >> together this summer (and before that, obviously). > > Same here! > >> According to http://www.google- >> melange.com/document/show/gsoc_program/google/gsoc2011/timeline , >> there's still some time until the application period. So let me use >> this week to finish my PhD research plan, and get back to you next >> week. >> >> I am not really familiar with how the program works, i.e. how detailed >> the application description should be, when mentorship is decided, >> etc. so I guess we will have a lot to talk about. :) > > so from a 1ft view it work like this: > > 1. Write up a short proposal what your idea is about > 2. make it public! and publish a implementation plan - how you would > want to realize your proposal. If you don't follow that 100% in the > actual impl. don't worry. Its just mean to give us an idea that you > know what you are doing and where you want to go. something like a 1 > A4 rough design doc. > 3. give other people the change to apply for the same suggestion (this > is how it works though) > 4 Let the ASF / us assign one or more possible mentors to it > 5. let us apply for a slot in GSoC (those are limited for organizations) > 6. get accepted > 7. rock it! > >> (Actually, should we move this discussion private?) > > no - we usually do everything in public except of discussion within > the PMC that are meant to be private for legal reasons or similar > things. Lets stick to the mailing list for all communication except > you have something that should clearly not be public. This also give > other contributors a chance to help and get interested in your work!! > > simon > >> David >> >>> Hi David, honestly this sounds fantastic. >>> >>> It would be great to have someone to work with us on this issue! >>> >>> To date, progress is pretty slow-going (minor improvements, cleanups, >>> additional stats here and there)... but we really need all the help >>> we can get, especially from people who have a really good >>> understanding of the various models. >>> >>> In case you are interested, here are some references to discussions >>> about adding more flexibility (with some prototypes etc): >>> http://www.lucidimagination.com/search/document/72787e0e54f798e4/baby >>> _st eps _towards_making_lucene_s_scoring_more_flexible >>> https://issues.apache.org/jira/browse/LUCENE-2392 >>> >>> On F
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5737 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5737/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8476 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-1566) Allow components to add fields to outgoing documents
[
https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004636#comment-13004636
]
Ryan McKinley commented on SOLR-1566:
-
Here is a different approach that allows the whole Document to be transformed
rather then just letting you add fields to the response. The basic interface
is now:
{code:java}
public abstract class DocTransformer
{
public abstract void transform(SolrDocument doc, int docid, Float score);
}
{code}
Some notes about the patch -- many tests fail because this does not support the
old xml style where multivalued fields show up as a single item.
> Allow components to add fields to outgoing documents
>
>
> Key: SOLR-1566
> URL: https://issues.apache.org/jira/browse/SOLR-1566
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Noble Paul
>Assignee: Grant Ingersoll
> Fix For: Next
>
> Attachments: SOLR-1566-DocTransformer.patch, SOLR-1566-gsi.patch,
> SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch,
> SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566.patch, SOLR-1566.patch,
> SOLR-1566.patch, SOLR-1566.patch
>
>
> Currently it is not possible for components to add fields to outgoing
> documents which are not in the the stored fields of the document. This makes
> it cumbersome to add computed fields/metadata .
--
This message is automatically generated by JIRA.
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-1566) Allow components to add fields to outgoing documents
[ https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-1566: Attachment: SOLR-1566-DocTransformer.patch This takes a different approach -- it forces all the writers to use SolrDocument rather then DocList > Allow components to add fields to outgoing documents > > > Key: SOLR-1566 > URL: https://issues.apache.org/jira/browse/SOLR-1566 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Noble Paul >Assignee: Grant Ingersoll > Fix For: Next > > Attachments: SOLR-1566-DocTransformer.patch, SOLR-1566-gsi.patch, > SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch, > SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566.patch, SOLR-1566.patch, > SOLR-1566.patch, SOLR-1566.patch > > > Currently it is not possible for components to add fields to outgoing > documents which are not in the the stored fields of the document. This makes > it cumbersome to add computed fields/metadata . -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5736 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5736/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8466 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2381: -- Attachment: jetty-util-6.1.26-patched-JETTY-1340.jar jetty-6.1.26-patched-JETTY-1340.jar SOLR-2381_take2.patch Here is _take2.patch: 1. I took Bernd's update to JETTY-1340, retested and rebuilt jetty. things look good from this perspective. 2. I then added my random test, and things look fine with the new Jetty. 3. Finally I incorporated uwe's patch also. I think this is the best solution, much safer and with a lot better tests. > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381.patch, SOLR-2381_take2.patch, > SOLR-2381_xmltest.patch, SOLR-ServletOutputWriter.patch, > SOLR-ServletOutputWriter.patch, jetty-6.1.26-patched-JETTY-1340.jar, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-SOLR-2381.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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
real reason for java.lang.NoClassDefFoundError ?
Hello!
I'm trying to use BEAM/Visat software in Python. It is a large project
with > 100 JARs. I try to 'convert' these JARs into Python specifying each
after --jar option:
python -m jcc.__init__ \
--python testbeam \
--jar /host/local/beam-4.8/modules/beam-landsat-reader-1.2.1.jar \
--jar /host/local/beam-4.8/modules/beam-meris-boreal-lakes-1.4.2.jar \
--jar /host/local/beam-4.8/modules/beam-meris-case2-core-1.4.2.jar \
--jar /host/local/beam-4.8/modules/beam-meris-case2-regional-1.4.2.jar \
--jar /host/local/beam-4.8/modules/beam-meris-cloud-1.5.203.jar \
--jar /host/local/beam-4.8/modules/beam-meris-eutrophic-lakes-1.4.2.jar \
--jar /host/local/beam-4.8/modules/beam-merisl3-reader-1.1.jar \
...
However I immediately got error:
While loading com/jidesoft/lucene/c$1
Traceback (most recent call last):
File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File
"/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__init__.py",
line 32, in
import jcc.__main__
File
"/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py",
line 98, in
cpp.jcc(sys.argv)
File
"/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
line 501, in jcc
cls = findClass(className.replace('.', '/'), iii)
File
"/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
line 73, in findClass
cls = _findClass(className)
jcc.cpp.JavaError: java.lang.NoClassDefFoundError:
org/apache/lucene/queryParser/QueryParser
Java stacktrace:
java.lang.NoClassDefFoundError: org/apache/lucene/queryParser/QueryParser
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Caused by: java.lang.ClassNotFoundException:
org.apache.lucene.queryParser.QueryParser
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
... 11 more
Why is that? Does that mean that the class com/jidesoft/lucene/c$1 has
reference to a class org/apache/lucene/queryParser/QueryParser but the
latter is not given in any JAR?
How can such situation occur if Beam/Visat works perfectly? Could it be
that Beam/Visat simply don't call
org/apache/lucene/queryParser/QueryParser ?
What should I do? Download a JAR with
org/apache/lucene/queryParser/QueryParser or rather --exclude
com/jidesoft/lucene/c ? Will it influence performance of the Python
module?
Thank you very much for any ideas/suggestions!
Anton
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5735 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5735/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8471 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5734 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5734/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8483 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004597#comment-13004597 ] Bernd Fehling commented on SOLR-2381: - Jetty patch will be uploaded to http://jira.codehaus.org/browse/JETTY-1340. I'm installing Uwe's patch also and try to "stay away" from XML for java. > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, SOLR-ServletOutputWriter.patch, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-SOLR-2381.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004595#comment-13004595 ] Robert Muir commented on SOLR-2381: --- Thanks Uwe: my test passes with your patch. To summarize, this is what I think we should do, once we get Bernd's patch: 1. we should commit the random test (SOLR-2381_xmltest.patch) 2. rebuild/test jetty with Bernd's modifications, and commit that if everything is ok. 3. we should commit Uwe's patch for extra safety and improved performance. > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, SOLR-ServletOutputWriter.patch, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-SOLR-2381.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-2381: Attachment: SOLR-ServletOutputWriter.patch Robert and me discussed about the Jetty OutputWriter and found out: - It's much more broken, as it would even not support writing half surrogates in write(char[], ofset, length), which may also fail for other ResponseWriters!!! - Jettys implementation is SLOOOW! The attached patch now uses no Writer supplied by Jetty or any other servlet container at all - it just handles HTTP as it is: a binary protocol using byte streams. Like for UpdateReqHandler it uses its own mapper inside Solr (on the input side ContentStream is used for that). As most output in solr is done using UTF-8 (the default), it uses a pre-looked up NIO Charset for that. > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, SOLR-ServletOutputWriter.patch, > jetty-6.1.26-patched-JETTY-1340.jar, jetty-6.1.26-patched-SOLR-2381.jar, > jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004584#comment-13004584 ] Robert Muir commented on SOLR-2381: --- Bernd, i didn't test your jars, but can you update the patch on http://jira.codehaus.org/browse/JETTY-1340 with your fixes? As an open source project, we can't just commit the binary jars. I did however, test Uwe's patch. I think we should fix this bug in jetty, but I think we should also use Uwe's patch (my random test passes always with his patch). This jetty writer is hardly fast, i think it makes sense to try to bypass this "optimization" in jetty which only causes bugs and likely only makes things slower actually (for example lots of conditionals and state-keeping, Character.isLowSurrogate on every char, and handling silly 6-byte UTF-8 cases which do not exist). Its also a good safety net, I don't trust these servlet containers to do this correctly. > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, jetty-6.1.26-patched-JETTY-1340.jar, > jetty-6.1.26-patched-SOLR-2381.jar, jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5733 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5733/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8494 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2381) The included jetty server does not support UTF-8
[ https://issues.apache.org/jira/browse/SOLR-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Fehling updated SOLR-2381: Attachment: jetty-util-6.1.26-patched-SOLR-2381.jar jetty-6.1.26-patched-SOLR-2381.jar And here it is, the fixed jetty. jetty-6.1-26-patched-SOLR-2381.jar jetty-util-6.1.26-patched-SOLR-2381 Please test it and give your feedback. At least my problems are gone. Thanks for your patience and help. > The included jetty server does not support UTF-8 > > > Key: SOLR-2381 > URL: https://issues.apache.org/jira/browse/SOLR-2381 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Blocker > Fix For: 3.1, 4.0 > > Attachments: SOLR-2381.patch, SOLR-2381_xmltest.patch, > SOLR-ServletOutputWriter.patch, jetty-6.1.26-patched-JETTY-1340.jar, > jetty-6.1.26-patched-SOLR-2381.jar, jetty-util-6.1.26-patched-JETTY-1340.jar, > jetty-util-6.1.26-patched-SOLR-2381.jar, post_utf8enhanced.sh, > utf8enhanced.xml > > > Some background here: > http://www.lucidimagination.com/search/document/6babe83bd4a98b64/which_unicode_version_is_supported_with_lucene > Some possible solutions: > * wait and see if we get resolution on > http://jira.codehaus.org/browse/JETTY-1340. To be honest, I am not even sure > where jetty is being maintained (there is a separate jetty project at > eclipse.org with another bugtracker, but the older releases are at codehaus). > * include a patched version of jetty with correct utf-8, using that patch. > * remove jetty and include a different container instead. -- This message is automatically generated by JIRA. 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
