[jira] Commented: (SOLR-781) Change facet.sort from boolean to string and specify sort method explicitely
[ https://issues.apache.org/jira/browse/SOLR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654195#action_12654195 ] Lars Kotthoff commented on SOLR-781: Thanks Yonik! On the topic of issues which have been around for a long time... do you have some time to take a look at SOLR-540 as well ;) Change facet.sort from boolean to string and specify sort method explicitely Key: SOLR-781 URL: https://issues.apache.org/jira/browse/SOLR-781 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Lars Kotthoff Assignee: Erik Hatcher Fix For: 1.4 Attachments: SOLR-781.patch, SOLR-781.patch, SOLR-781.patch The facet.sort parameter is currently a boolean, which has some downsides as explained in http://www.nabble.com/facet.sort-parameter-td19570834.html Changing it to a string which explicitely states the sort method would address these issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Solr 1.3 - Field Collapsing - SOLR 236
Hi, About a year ago, I took the then-existing SOLR 1.2 patches for Field Collapsing, adapted them to my use, and have been using them successfully in production for most of this year. I'm now looking to upgrade my installation to SOLR 1.3. That leads to several questions. - As far as I can make out, Field Collapsing didn't make it into the 1.3 branch and the 1.4 trunk. - Any future plans for moving Field Collapsing into the core code base? - I'm willing to work with the existing patches to rebuild my version of FieldCollapsing into 1.3. I've been through the notes on 'SOLR 236'. However, I can't figure out which patches to use, in which order. - Is there a 'consolidated' patch anywhere? Any help is appreciated. Regards, Tracy
[jira] Updated: (SOLR-781) Change facet.sort from boolean to string and specify sort method explicitely
[ https://issues.apache.org/jira/browse/SOLR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Kotthoff updated SOLR-781: --- Attachment: SOLR-781.patch I've taken a look at the non-overrequesting stuff -- we also need to consider the legacy case (i.e. true/false instead of sort/lex). Attaching patch which addresses this and replaces some string constants which escaped me before with the constants from FacetParams. Change facet.sort from boolean to string and specify sort method explicitely Key: SOLR-781 URL: https://issues.apache.org/jira/browse/SOLR-781 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Lars Kotthoff Assignee: Erik Hatcher Fix For: 1.4 Attachments: SOLR-781.patch, SOLR-781.patch, SOLR-781.patch, SOLR-781.patch The facet.sort parameter is currently a boolean, which has some downsides as explained in http://www.nabble.com/facet.sort-parameter-td19570834.html Changing it to a string which explicitely states the sort method would address these issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-781) Change facet.sort from boolean to string and specify sort method explicitely
[ https://issues.apache.org/jira/browse/SOLR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654213#action_12654213 ] Yonik Seeley commented on SOLR-781: --- Lars, I already committed some code to normalize on the new facet.sort values so we don't need to check for both new and legacy everywhere. Also, you didn't miss those string constants - I removed those two cases since they were being used for the wrong variable (facet=true/false instead of facet.sort=true/false). Wrong context makes the code more confusing. Change facet.sort from boolean to string and specify sort method explicitely Key: SOLR-781 URL: https://issues.apache.org/jira/browse/SOLR-781 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Lars Kotthoff Assignee: Erik Hatcher Fix For: 1.4 Attachments: SOLR-781.patch, SOLR-781.patch, SOLR-781.patch, SOLR-781.patch The facet.sort parameter is currently a boolean, which has some downsides as explained in http://www.nabble.com/facet.sort-parameter-td19570834.html Changing it to a string which explicitely states the sort method would address these issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ant example, tika
I notice that SOLR-284 (extraction data handler + tika) is in the default example now. Is this what we want? On the topic of example, it used to be much faster in the past to use for debugging... now when I do ant example, I go get a cup of coffee. -Yonik
[jira] Commented: (SOLR-781) Change facet.sort from boolean to string and specify sort method explicitely
[ https://issues.apache.org/jira/browse/SOLR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654214#action_12654214 ] Lars Kotthoff commented on SOLR-781: bq. Lars, I already committed some code to normalize on the new facet.sort values so we don't need to check for both new and legacy everywhere. Ah sorry, missed that. Must have been in the gigantic diff :) bq. Also, you didn't miss those string constants - I removed those two cases since they were being used for the wrong variable (facet=true/false instead of facet.sort=true/false). Wrong context makes the code more confusing. Argh, the dangers of search and replace... Change facet.sort from boolean to string and specify sort method explicitely Key: SOLR-781 URL: https://issues.apache.org/jira/browse/SOLR-781 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Lars Kotthoff Assignee: Erik Hatcher Fix For: 1.4 Attachments: SOLR-781.patch, SOLR-781.patch, SOLR-781.patch, SOLR-781.patch The facet.sort parameter is currently a boolean, which has some downsides as explained in http://www.nabble.com/facet.sort-parameter-td19570834.html Changing it to a string which explicitely states the sort method would address these issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-900) Move solrj into root 'src' tree
[ https://issues.apache.org/jira/browse/SOLR-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654215#action_12654215 ] Ryan McKinley commented on SOLR-900: Looking over this now Something that does not fit nicely is where do we put the 'test' classes. For simplicity, I think we should put them all into the existing /src/test/org... tree Move solrj into root 'src' tree --- Key: SOLR-900 URL: https://issues.apache.org/jira/browse/SOLR-900 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 The existing solrj source layout makes circular dependencies. We can simplify this by bringing solr into the root src tree. For background discussion, see: http://www.nabble.com/Cleaning-up-a-Few-things-td20668918.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-900) Move solrj into root 'src' tree
[ https://issues.apache.org/jira/browse/SOLR-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-900: --- Attachment: SOLR-900-move-solrj-into-src.patch.gz Here is a patch that moves things around and updates the build.xml file. Since SVN patch does not deal well with 'svn mv', the patch is kinda useless, but I post it here for good measure... tests pass, and as far as i can tell the maven artifacts look reasonable. Move solrj into root 'src' tree --- Key: SOLR-900 URL: https://issues.apache.org/jira/browse/SOLR-900 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 Attachments: SOLR-900-move-solrj-into-src.patch.gz The existing solrj source layout makes circular dependencies. We can simplify this by bringing solr into the root src tree. For background discussion, see: http://www.nabble.com/Cleaning-up-a-Few-things-td20668918.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r724175 - in /lucene/solr/trunk: ./ client/java/ contrib/dataimporthandler/ contrib/extraction/ contrib/velocity/ lib/ src/common/ src/common/org/ src/common/org/apache/ src/common/org
sorry, just checked the .war file...
it is not building correctly, i'll fix it an check in soon...
On Dec 7, 2008, at 2:07 PM, [EMAIL PROTECTED] wrote:
Author: ryan
Date: Sun Dec 7 11:07:11 2008
New Revision: 724175
URL: http://svn.apache.org/viewvc?rev=724175view=rev
Log:
SOLR-900: Moving solrj into /src/solrj.
Added:
lucene/solr/trunk/lib/commons-httpclient-3.1.jar (props changed)
- copied unchanged from r724156, lucene/solr/trunk/client/java/
solrj/lib/commons-httpclient-3.1.jar
lucene/solr/trunk/lib/jcl-over-slf4j-1.5.5.jar (props changed)
- copied unchanged from r724156, lucene/solr/trunk/client/java/
solrj/lib/jcl-over-slf4j-1.5.5.jar
lucene/solr/trunk/src/common/
lucene/solr/trunk/src/common/org/
lucene/solr/trunk/src/common/org/apache/
lucene/solr/trunk/src/common/org/apache/solr/
lucene/solr/trunk/src/common/org/apache/solr/common/ (props
changed)
- copied from r724156, lucene/solr/trunk/src/java/org/apache/
solr/common/
lucene/solr/trunk/src/maven/solr-core-pom.xml.template (props
changed)
- copied unchanged from r724156, lucene/solr/trunk/src/maven/
solr-core-pom.xml.template
lucene/solr/trunk/src/maven/solr-solrj-pom.xml.template
(contents, props changed)
- copied, changed from r724156, lucene/solr/trunk/client/java/
solrj/solr-solrj-pom.xml.template
lucene/solr/trunk/src/solrj/
lucene/solr/trunk/src/solrj/org/ (props changed)
- copied from r724156, lucene/solr/trunk/client/java/solrj/src/
org/
lucene/solr/trunk/src/test/org/apache/solr/client/ (props
changed)
- copied from r724156, lucene/solr/trunk/client/java/solrj/test/
org/apache/solr/client/
lucene/solr/trunk/src/webapp/src/org/apache/solr/client/
lucene/solr/trunk/src/webapp/src/org/apache/solr/client/solrj/
lucene/solr/trunk/src/webapp/src/org/apache/solr/client/solrj/
embedded/ (props changed)
- copied from r724156, lucene/solr/trunk/client/java/solrj/src/
org/apache/solr/client/solrj/embedded/
Removed:
lucene/solr/trunk/client/java/
lucene/solr/trunk/src/java/org/apache/solr/common/
lucene/solr/trunk/src/maven/solr-common-pom.xml.template
lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/embedded/
Modified:
lucene/solr/trunk/CHANGES.txt
lucene/solr/trunk/build.xml
lucene/solr/trunk/contrib/dataimporthandler/build.xml
lucene/solr/trunk/contrib/extraction/build.xml
lucene/solr/trunk/contrib/velocity/build.xml
Modified: lucene/solr/trunk/CHANGES.txt
URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=724175r1=724174r2=724175view=diff
=
=
=
=
=
=
=
=
==
--- lucene/solr/trunk/CHANGES.txt (original)
+++ lucene/solr/trunk/CHANGES.txt Sun Dec 7 11:07:11 2008
@@ -184,6 +184,10 @@
9. SOLR-819: Upgraded to Lucene 2.9-dev (r724059) to get access to
Arabic public constructors (gsingers)
+10. SOLR-900: Moved solrj into /src/solrj. The contents of solr-
common.jar is now included
+in the solr-solrj.jar. (ryan)
+
+
Build
--
1. SOLR-776: Added in ability to sign artifacts via Ant for
releases (gsingers)
Modified: lucene/solr/trunk/build.xml
URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/build.xml?rev=724175r1=724174r2=724175view=diff
=
=
=
=
=
=
=
=
==
--- lucene/solr/trunk/build.xml (original)
+++ lucene/solr/trunk/build.xml Sun Dec 7 11:07:11 2008
@@ -97,18 +97,6 @@
!-- = COMPILATION-RELATED TASKS
= --
!--
=
=
=
=
=
--
- !-- Compile common classes. --
- target name=compile-common
- description=Compile the source code.
- depends=init-forrest-entities
-
-solr-javac destdir=${dest}/common
-classpathref=compile.classpath
- src path=${src}/java /
- include name=org/apache/solr/common/** /
-/solr-javac
- /target
-
!-- The compilation classpath --
path id=compile.classpath
fileset dir=${lib}
@@ -117,65 +105,82 @@
pathelement location=${dest}/common/
/path
+ target name=compile-solrj
+ description=Compile the java client.
+ depends=init-forrest-entities
+
+solr-javac destdir=${dest}/solrj
+classpathref=compile.classpath
+ src path=${src}/common /
+ src path=${src}/solrj /
+/solr-javac
+ /target
+
+
+ !-- This depend on all of solr --
+ path id=compile.classpath.solrj
+path refid=compile.classpath /
+pathelement location=${dest}/solrj/
+!-- jetty --
+fileset dir=example/lib
+ include name=**/*.jar /
+/fileset
+ /path
+
!-- Compile the project. --
target name=compile
description=Compile the source code.
- depends=compile-common,init-forrest-entities
+
Re: ant example, tika
On Dec 7, 2008, at 11:42 AM, Yonik Seeley wrote: I notice that SOLR-284 (extraction data handler + tika) is in the default example now. Is this what we want? I don't think so. Also, it looks like DataImportHandler puts itself in the war file -- I don't think we want that either. On the topic of example, it used to be much faster in the past to use for debugging... now when I do ant example, I go get a cup of coffee. Agreed -- I would hope that ant run-example would compile and run the minimum setup required. We can have a different setup that would do more things: dataimporthandler, velocity, and extraction. ryan
[jira] Commented: (SOLR-284) Parsing Rich Document Types
[
https://issues.apache.org/jira/browse/SOLR-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654234#action_12654234
]
Ryan McKinley commented on SOLR-284:
Looks like there are a bunch of duplicate .jar files in lib. You could remove
these and use the ones that are already in /lib
{panel}
Index: contrib/extraction/lib/commons-io-1.4.jar
Index: contrib/extraction/lib/commons-codec-1.3.jar
Index: contrib/extraction/lib/commons-lang-2.1.jar
Index: contrib/extraction/lib/commons-logging-1.0.4.jar
Index: contrib/extraction/lib/junit-3.8.1.jar
{panel}
Parsing Rich Document Types
---
Key: SOLR-284
URL: https://issues.apache.org/jira/browse/SOLR-284
Project: Solr
Issue Type: New Feature
Components: update
Reporter: Eric Pugh
Assignee: Grant Ingersoll
Fix For: 1.4
Attachments: libs.zip, rich.patch, rich.patch, rich.patch,
rich.patch, rich.patch, rich.patch, rich.patch, SOLR-284.patch,
SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, SOLR-284.patch,
SOLR-284.patch, SOLR-284.patch, solr-word.pdf, source.zip, test-files.zip,
test-files.zip, test.zip, un-hardcode-id.diff
I have developed a RichDocumentRequestHandler based on the CSVRequestHandler
that supports streaming a PDF, Word, Powerpoint, Excel, or PDF document into
Solr.
There is a wiki page with information here:
http://wiki.apache.org/solr/UpdateRichDocuments
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: ant example, tika
Tika shouldn't be in the example. It just puts the libs there but is not hooked into the config. On Dec 7, 2008, at 2:32 PM, Ryan McKinley wrote: On Dec 7, 2008, at 11:42 AM, Yonik Seeley wrote: I notice that SOLR-284 (extraction data handler + tika) is in the default example now. Is this what we want? I don't think so. Also, it looks like DataImportHandler puts itself in the war file -- I don't think we want that either. On the topic of example, it used to be much faster in the past to use for debugging... now when I do ant example, I go get a cup of coffee. Agreed -- I would hope that ant run-example would compile and run the minimum setup required. We can have a different setup that would do more things: dataimporthandler, velocity, and extraction. ryan
[jira] Commented: (SOLR-284) Parsing Rich Document Types
[ https://issues.apache.org/jira/browse/SOLR-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654235#action_12654235 ] Grant Ingersoll commented on SOLR-284: -- Thanks, Ryan, I will remove them. Parsing Rich Document Types --- Key: SOLR-284 URL: https://issues.apache.org/jira/browse/SOLR-284 Project: Solr Issue Type: New Feature Components: update Reporter: Eric Pugh Assignee: Grant Ingersoll Fix For: 1.4 Attachments: libs.zip, rich.patch, rich.patch, rich.patch, rich.patch, rich.patch, rich.patch, rich.patch, SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, solr-word.pdf, source.zip, test-files.zip, test-files.zip, test.zip, un-hardcode-id.diff I have developed a RichDocumentRequestHandler based on the CSVRequestHandler that supports streaming a PDF, Word, Powerpoint, Excel, or PDF document into Solr. There is a wiki page with information here: http://wiki.apache.org/solr/UpdateRichDocuments -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ant example, tika
On Dec 7, 2008, at 2:32 PM, Ryan McKinley wrote: On Dec 7, 2008, at 11:42 AM, Yonik Seeley wrote: I notice that SOLR-284 (extraction data handler + tika) is in the default example now. Is this what we want? I don't think so. Also, it looks like DataImportHandler puts itself in the war file -- I don't think we want that either. DIH has a JSP that needs to be in the WAR, unfortunately. Interestingly, the JSP could be done away with and the VelocityResponseWriter could be used, with templates externalized (in the DIH JAR file, for example) and plugged in as a true lib/ plugin. Erik
Re: ant example, tika
On Dec 7, 2008, at 3:04 PM, Erik Hatcher wrote: On Dec 7, 2008, at 2:32 PM, Ryan McKinley wrote: On Dec 7, 2008, at 11:42 AM, Yonik Seeley wrote: I notice that SOLR-284 (extraction data handler + tika) is in the default example now. scriplet Is this what we want? I don't think so. Also, it looks like DataImportHandler puts itself in the war file -- I don't think we want that either. DIH has a JSP that needs to be in the WAR, unfortunately. Interestingly, the JSP could be done away with and the VelocityResponseWriter could be used, with templates externalized (in the DIH JAR file, for example) and plugged in as a true lib/ plugin. yes, it would be nice to get rid of all .jsp and use some other system (i don't care what, but velocity seems like a good choice). This would let all the admin goodness be available from embedded systems as well as the standard stack. Also it would get rid of the untestable stuff. However, this may be on the 2.0 list :( ryan
[jira] Updated: (SOLR-475) multi-valued faceting via un-inverted field
[ https://issues.apache.org/jira/browse/SOLR-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-475: -- Attachment: SOLR-475.patch update: - closing of term enumerators (not strictly necessary in Lucene now, so shouldn't have caused any problems). - new fieldValueCache in SolrIndexSearcher - uninverted field statistics (per field) available with cache statistics multi-valued faceting via un-inverted field --- Key: SOLR-475 URL: https://issues.apache.org/jira/browse/SOLR-475 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Fix For: 1.4 Attachments: facet_performance.html, SOLR-475.patch, SOLR-475.patch, UnInvertedField.java, UnInvertedField.java Facet multi-valued fields via a counting method (like the FieldCache method) on an un-inverted representation of the field. For each doc, look at it's terms and increment a count for that term. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ant example, tika
On Sun, Dec 7, 2008 at 2:47 PM, Grant Ingersoll [EMAIL PROTECTED] wrote: Tika shouldn't be in the example. It just puts the libs there but is not hooked into the config. Hmmm, so it's half installed. Seems like we should either add in the extraction handler (perhaps lazily loaded if it takes up resources) to solrconfig.xml in example, or remove the extraction jars from lib. -Yonik
Re: svn commit: r724190 - in /lucene/solr/trunk/contrib/extraction: build.xml lib/commons-codec-1.3.jar lib/commons-io-1.4.jar lib/commons-lang-2.1.jar lib/junit-3.8.1.jar
On Dec 7, 2008, at 3:21 PM, [EMAIL PROTECTED] wrote: SOLR-284: remove duplicated Tika libs Removed: lucene/solr/trunk/contrib/extraction/lib/commons-lang-2.1.jar My mistake, commons-lang is not in the root /lib, so this may cause some problem with dependent libraries. I don't know if it matters, but the velocity contrib uses commons- lang-2.4.jar Also, I see you did not remove: commons-logging.jar -- that may be fine, but note that jcl-over-slf4j-1.5.5.jar is a drop in replacement for commons-logging.jar -- this way anything using commons-logging can be handled exactly the same as if it were using the slf4j API. ryan
[jira] Assigned: (SOLR-343) Constraining date facets by facet.mincount
[ https://issues.apache.org/jira/browse/SOLR-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned SOLR-343: Assignee: (was: Grant Ingersoll) Constraining date facets by facet.mincount -- Key: SOLR-343 URL: https://issues.apache.org/jira/browse/SOLR-343 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.2 Environment: Solr 1.2+ Reporter: Raiko Eckstein Priority: Minor Attachments: DateFacetsMincountPatch.patch It would be helpful to allow the facet.mincount parameter to work with date facets, i.e. constraining the results so that it would be possible to filter out date ranges in the results where no documents occur from the server-side. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ant example, tika
The jars aren't checked in to the example. The thing is, the extraction stuff is a contrib and not on by default and not packaged into the WAR. DIH currently does package into the WAR, but I don't think contribs should do that. Frankly, I think the better answer is an overhaul of the examples directory, like we discussed in the clean up thread that is also taking place. Keep the main example nice and simple, and then have more organized other examples. On Dec 7, 2008, at 3:17 PM, Yonik Seeley wrote: On Sun, Dec 7, 2008 at 2:47 PM, Grant Ingersoll [EMAIL PROTECTED] wrote: Tika shouldn't be in the example. It just puts the libs there but is not hooked into the config. Hmmm, so it's half installed. Seems like we should either add in the extraction handler (perhaps lazily loaded if it takes up resources) to solrconfig.xml in example, or remove the extraction jars from lib. -Yonik
Re: svn commit: r724190 - in /lucene/solr/trunk/contrib/extraction: build.xml lib/commons-codec-1.3.jar lib/commons-io-1.4.jar lib/commons-lang-2.1.jar lib/junit-3.8.1.jar
Hmm, the tests pass w/o commons-lang, but they fail w/o commons- logging. Sigh. I'll put lang back in. On Dec 7, 2008, at 3:46 PM, Ryan McKinley wrote: On Dec 7, 2008, at 3:21 PM, [EMAIL PROTECTED] wrote: SOLR-284: remove duplicated Tika libs Removed: lucene/solr/trunk/contrib/extraction/lib/commons-lang-2.1.jar My mistake, commons-lang is not in the root /lib, so this may cause some problem with dependent libraries. I don't know if it matters, but the velocity contrib uses commons- lang-2.4.jar Also, I see you did not remove: commons-logging.jar -- that may be fine, but note that jcl-over-slf4j-1.5.5.jar is a drop in replacement for commons-logging.jar -- this way anything using commons-logging can be handled exactly the same as if it were using the slf4j API. ryan
Re: ant example, tika
On Sun, Dec 7, 2008 at 5:50 PM, Grant Ingersoll [EMAIL PROTECTED] wrote: The jars aren't checked in to the example. But ant example puts them there - doesn't matter from a user perspective. The thing is, the extraction stuff is a contrib and not on by default and not packaged into the WAR. But then why do all the jars still get copied into the example lib directory? Is this intentional? -Yonik DIH currently does package into the WAR, but I don't think contribs should do that. Frankly, I think the better answer is an overhaul of the examples directory, like we discussed in the clean up thread that is also taking place. Keep the main example nice and simple, and then have more organized other examples. On Dec 7, 2008, at 3:17 PM, Yonik Seeley wrote: On Sun, Dec 7, 2008 at 2:47 PM, Grant Ingersoll [EMAIL PROTECTED] wrote: Tika shouldn't be in the example. It just puts the libs there but is not hooked into the config. Hmmm, so it's half installed. Seems like we should either add in the extraction handler (perhaps lazily loaded if it takes up resources) to solrconfig.xml in example, or remove the extraction jars from lib. -Yonik
Re: svn commit: r724181 - /lucene/solr/trunk/build.xml
Ryan,
I got an error when doing 'ant dist'.
Koji
[EMAIL PROTECTED] wrote:
Author: ryan
Date: Sun Dec 7 11:27:54 2008
New Revision: 724181
URL: http://svn.apache.org/viewvc?rev=724181view=rev
Log:
SOLR-900 -- fixing war file
Modified:
lucene/solr/trunk/build.xml
Modified: lucene/solr/trunk/build.xml
URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/build.xml?rev=724181r1=724180r2=724181view=diff
==
--- lucene/solr/trunk/build.xml (original)
+++ lucene/solr/trunk/build.xml Sun Dec 7 11:27:54 2008
@@ -458,10 +458,13 @@
lib dir=${lib}
exclude name=servlet-api*.jar /
exclude name=easymock.jar /
+ exclude name=junit-*.jar /
+ exclude name=*.txt /
+ exclude name=*.template /
/lib
lib dir=${dist}
include name=${fullname}-solrj-${version}.jar /
- include name=${fullname}-${version}.jar /
+ include name=${fullname}-core-${version}.jar /
/lib
fileset dir=${src}/webapp/web /
@@ -505,7 +508,7 @@
!-- Creates the solr jar. --
target name=dist-jar
description=Creates the Solr JAR Distribution file.
- depends=compile, make-manifest
+ depends=dist-solrj, compile, make-manifest
mkdir dir=${dist} /
solr-jar destfile=${dist}/${fullname}-core-${version}.jar
fileset dir=${dest}/solr /
@@ -516,7 +519,7 @@
!-- Creates the solr jar. --
target name=dist-solrj
description=Creates the Solr JAR Distribution file.
- depends=compile-solrj, dist-jar
+ depends=compile-solrj
mkdir dir=${dist} /
solr-jar
destfile=${dist}/${fullname}-solrj-${version}.jar
Re: svn commit: r724181 - /lucene/solr/trunk/build.xml
try now...
On Dec 7, 2008, at 8:20 PM, Koji Sekiguchi wrote:
Ryan,
I got an error when doing 'ant dist'.
Koji
[EMAIL PROTECTED] wrote:
Author: ryan
Date: Sun Dec 7 11:27:54 2008
New Revision: 724181
URL: http://svn.apache.org/viewvc?rev=724181view=rev
Log:
SOLR-900 -- fixing war file
Modified:
lucene/solr/trunk/build.xml
Modified: lucene/solr/trunk/build.xml
URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/build.xml?rev=724181r1=724180r2=724181view=diff
=
=
=
=
=
=
=
=
=
=
--- lucene/solr/trunk/build.xml (original)
+++ lucene/solr/trunk/build.xml Sun Dec 7 11:27:54 2008
@@ -458,10 +458,13 @@
lib dir=${lib}
exclude name=servlet-api*.jar /
exclude name=easymock.jar /
+ exclude name=junit-*.jar /
+ exclude name=*.txt /
+ exclude name=*.template /
/lib
lib dir=${dist}
include name=${fullname}-solrj-${version}.jar /
- include name=${fullname}-${version}.jar /
+ include name=${fullname}-core-${version}.jar /
/lib
fileset dir=${src}/webapp/web /
@@ -505,7 +508,7 @@
!-- Creates the solr jar. --
target name=dist-jar
description=Creates the Solr JAR Distribution file.
- depends=compile, make-manifest
+ depends=dist-solrj, compile, make-manifest
mkdir dir=${dist} /
solr-jar destfile=${dist}/${fullname}-core-${version}.jar
fileset dir=${dest}/solr /
@@ -516,7 +519,7 @@
!-- Creates the solr jar. --
target name=dist-solrj
description=Creates the Solr JAR Distribution file.
- depends=compile-solrj, dist-jar
+ depends=compile-solrj
mkdir dir=${dist} /
solr-jar
destfile=${dist}/${fullname}-solrj-${version}.jar
Re: ant example, tika
On Dec 7, 2008, at 5:50 PM, Grant Ingersoll wrote: The jars aren't checked in to the example. The thing is, the extraction stuff is a contrib and not on by default and not packaged into the WAR. DIH currently does package into the WAR, but I don't think contribs should do that. Frankly, I think the better answer is an overhaul of the examples directory, like we discussed in the clean up thread that is also taking place. Keep the main example nice and simple, and then have more organized other examples. +1 Rethinking the example directory structure / process is a good idea...
Re: svn commit: r724181 - /lucene/solr/trunk/build.xml
Ryan, Fixed. Thank you! Ryan McKinley wrote: try now...
Re: ant example, tika
On Dec 7, 2008, at 5:56 PM, Yonik Seeley wrote: On Sun, Dec 7, 2008 at 5:50 PM, Grant Ingersoll [EMAIL PROTECTED] wrote: The jars aren't checked in to the example. But ant example puts them there - doesn't matter from a user perspective. The thing is, the extraction stuff is a contrib and not on by default and not packaged into the WAR. But then why do all the jars still get copied into the example lib directory? Is this intentional? Yes, it is intentional. The patch originally had the ERH turned on in the example, but then crazily enough, the core unit tests have dependencies on the example, so go figure. So, I thought this was a compromise. Have the example ready to go if someone runs ant example but not break the unit tests that for some reason depend on example code. Like I said, I think we really need take a step back and better organize the code and think just a little bit more about packaging, core, contribs, clients, etc. b/c right now it's all a big mish-mash. -Grant
Re: logo contest
: I would personally prefer more of an elimination-style vote (i.e., STV). Ah... yeah, that seems like it would be a more fair way to deal with things then my suggestion, and it doesn't violate the spirt of the rules as original outlined (it's still a vote of ranked preferences). Are you volunteering to do the vote counting Mike? Anyone have objections to using STV? Background Info... http://en.wikipedia.org/wiki/Single_transferable_vote http://en.wikipedia.org/wiki/Instant-runoff_voting -Hoss
[jira] Created: (SOLR-901) FastOutputStream ignores write(byte[]) call
FastOutputStream ignores write(byte[]) call Key: SOLR-901 URL: https://issues.apache.org/jira/browse/SOLR-901 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Noble Paul Priority: Minor Attachments: SOLR-901.patch The method write(byte[]) does nothing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-901) FastOutputStream ignores write(byte[]) call
[ https://issues.apache.org/jira/browse/SOLR-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-901: Attachment: SOLR-901.patch the fix FastOutputStream ignores write(byte[]) call Key: SOLR-901 URL: https://issues.apache.org/jira/browse/SOLR-901 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Noble Paul Priority: Minor Attachments: SOLR-901.patch The method write(byte[]) does nothing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-902) Potential bug w/ FastInputStream
Potential bug w/ FastInputStream Key: SOLR-902 URL: https://issues.apache.org/jira/browse/SOLR-902 Project: Solr Issue Type: Bug Reporter: Noble Paul Priority: Minor When I use FastInputStream wrapped by a GZIPInputStream it does not work -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-902) Potential bug w/ FastInputStream
[ https://issues.apache.org/jira/browse/SOLR-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-902: Attachment: SOLR-902.patch A testcase to demonstrate this Potential bug w/ FastInputStream Key: SOLR-902 URL: https://issues.apache.org/jira/browse/SOLR-902 Project: Solr Issue Type: Bug Reporter: Noble Paul Priority: Minor Attachments: SOLR-902.patch When I use FastInputStream wrapped by a GZIPInputStream it does not work -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ant example, tika
On Mon, Dec 8, 2008 at 1:02 AM, Ryan McKinley [EMAIL PROTECTED] wrote: Also, it looks like DataImportHandler puts itself in the war file -- I don't think we want that either. One big difference between DataImportHandler and other contribs is that it has zero extra dependencies and it contains a JSP as well. Plus, it is becoming very popular. I'd like to keep it in the war by default. -- Regards, Shalin Shekhar Mangar.
Re: ant example, tika
On Dec 8, 2008, at 2:33 AM, Shalin Shekhar Mangar wrote: On Mon, Dec 8, 2008 at 1:02 AM, Ryan McKinley [EMAIL PROTECTED] wrote: Also, it looks like DataImportHandler puts itself in the war file -- I don't think we want that either. One big difference between DataImportHandler and other contribs is that it has zero extra dependencies and it contains a JSP as well. Plus, it is becoming very popular. I'd like to keep it in the war by default. Without the JSP it doesn't need to live in the WAR. But then again, if we remove the JSPs by my proposal, we end up with VelocityResponseWriter in the WAR :) [and VrW does have additional dependencies, and then DIH would depend on VrW - LOL] Erik
