Git repo
Is there a git repo location that mirrors apache svn repos for solr? Cheers, Mark -- [image: @mire Inc.] *Mark Diggory *(Schedule a Meetinghttps://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg ) *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* *Esperantolaan 4, Heverlee 3001, Belgium* http://www.atmire.com
Re: Field Collapsing SOLR-236
Correct, it uses maven and just constructs the War executable, its upto you to
configure the location of your solr home directory still.
svn co https://scm.dspace.org/svn/repo/modules/dspace-solr/trunk solr
cd solr
mvn package
then you can go into the webapp/target directory and get the generated war file
there and/or manipulate your solr home settings prior to deploying it.
note if you just want to use it, you don't have build it, you can just get the
precompiled binary from the maven central repo
http://repo2.maven.org/maven2/org/dspace/dependencies/solr/dspace-solr-webapp/1.4.0.1/dspace-solr-webapp-1.4.0.1.war
likewise for the modified solrj
http://repo2.maven.org/maven2/org/dspace/dependencies/solr/dspace-solr-solrj/1.4.0.1/dspace-solr-solrj-1.4.0.1.jar
Cheers,
Mark
On Jun 17, 2010, at 9:50 AM, Moazzam Khan wrote:
Hi Mark,
Thanks for posting those links. I know this is probably a dumb
question, but how do I make Solr work through your repository? I ask
this because I don't see a build xml file and the folder structure is
a bit different (I'm guessing I am not supposed to use ant on that :D)
Thanks,
Moazzam
On Thu, Jun 17, 2010 at 4:23 AM, Rakhi Khatwani rkhatw...@gmail.com wrote:
Hi Moazzam,
Yup i hv encountered the same thing.
Build errors after applying the patch.
Rakhi
On Thu, Jun 17, 2010 at 3:33 AM, Moazzam Khan moazz...@gmail.com wrote:
I got the code from trunk again and now I get this error:
[javac] symbol : class StringIndex
[javac] location: interface org.apache.lucene.search.FieldCache
[javac] private final MapString, FieldCache.StringIndex
fieldCaches =
new HashMapString, FieldCache.StringIndex();
[javac] ^
[javac]
C:\svn\solr\src\java\org\apache\solr\search\SolrIndexSearcher.java:6
74: cannot find symbol
[javac] symbol : class DocSetScoreCollector
[javac] location: class org.apache.solr.search.SolrIndexSearcher
[javac] if (query instanceof TermQuery !(collector instanceof
Doc
SetScoreCollector)) {
[javac]
^
[javac]
C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\AbstractDo
cumentCollapser.java:257: cannot find symbol
[javac] symbol : method
getStringIndex(org.apache.solr.search.SolrIndexRead
er,java.lang.String)
[javac] location: interface org.apache.lucene.search.FieldCache
[javac] fieldValues =
FieldCache.DEFAULT.getStringIndex(searcher.getRead
er(), collapseField);
[javac] ^
[javac]
C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
AggregateCollapseCollectorFactory.java:163: cannot find symbol
[javac] symbol : class StringIndex
[javac] location: interface org.apache.lucene.search.FieldCache
[javac] private final MapString, FieldCache.StringIndex
fieldCaches =
new HashMapString, FieldCache.StringIndex();
[javac]
^
[javac]
C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
AggregateCollapseCollectorFactory.java:173: cannot find symbol
[javac] symbol : method
getStringIndex(org.apache.solr.search.SolrIndexRead
er,java.lang.String)
[javac] location: interface org.apache.lucene.search.FieldCache
[javac] fieldCaches.put(fieldName,
FieldCache.DEFAULT.getStringInd
ex(searcher.getReader(), fieldName));
[javac]^
[javac]
C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
AggregateCollapseCollectorFactory.java:183: cannot find symbol
[javac] symbol : class StringIndex
[javac] location: interface org.apache.lucene.search.FieldCache
[javac] FieldCache.StringIndex stringIndex =
fieldCaches.get(aggrega
teField.getFieldName());
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 10 errors
I am compiling using jdk 1.5 update 22. Does that have anything to do
with the errors?
-Moazzam
On Wed, Jun 16, 2010 at 4:34 PM, Moazzam Khan moazz...@gmail.com wrote:
I did the same thing. And, the code compiles without the patch but
when I apply the patch I get these errors:
[javac]
C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
FieldValueCountCollapseCollectorFactory.java:127: class, interface, or
enum expe
cted
[javac] import java.util.HashMap;
[javac] ^
[javac]
C:\svn\solr\src\java\org\apache\solr\search\fieldcollapse\collector\
FieldValueCountCollapseCollectorFactory.java:128: class, interface, or
enum expe
cted
[javac] import java.util.Map;
[javac] ^
[javac]
Solr Project Structure (was Re: Field Collapsing SOLR-236)
Erik, I try not to be exclusionary of others development tool choices in the selection of my own. However, just to surely stir up a nest of hornets in true Apache fashion... when I saw what was done with the templating of the Maven pom work that was originally donated to solr, I just cringed at it. The point of using Maven as a build tool is to avoid the complexity that was introduced by one off'ing in the manner that was finally committed. https://issues.apache.org/jira/browse/SOLR-19 https://issues.apache.org/jira/browse/SOLR-586 I choose to do the inverse of the solr build process as a means to manage our own dependency on solr in a Maven way, conventional to our current build and modularity practices. I don't think Solr needs to adopt maven if they prefer ant, just draw clearer lines through the project about how to separate code for functional areas and clearly document the interfaces that should be customizable/changeable. JIRA Tasks should tackle core code changes separately from addon functionality that can be swapped out or left behind such as to avoid the risks of producing spaghetti interdependencies in the codebase. And if using Ant, efforts should be made to not do highly complex transformations of the sourcecode and or generated artifacts. Ideally, source directories should have a 1 to 1 relationship to artifacts that are produced. This SOLR-236 is a posterchild of an unclear practice or convention for how to package customizations to Solr. Really, isn't SOLR-236 wanted enough to warrant that it actually reside in the svn where it could be developed properly rather than as a task thats been open for how many years?! I'd highly recommend the Field Collapsing prototype ceased to be managed as patches in a JIRA task and actually got some code re-visioning behind it and interim release building available. I'll even confess that my patch cludge in my maven project to apply SOLR-236 to the solr source is not at all a best practice in terms of supporting addons to solr. It was simply an attempt to compensate. Ideally, Field Collapsing should have been a separately maintained codebase in a separate maven project that did not interfere with the solr, solr core request handler or configuration implementations and simply just depended on them. Then it could be dropped into a lib dir of any solr 1.4.0. (and conversely just added to my webapp poms as a maven dependency when they are assembled in our own build processes). further comments below... On Jun 17, 2010, at 11:20 AM, Erik Hatcher wrote: On Jun 16, 2010, at 7:31 PM, Mark Diggory wrote: p.s. I'd be glad to contribute our Maven build re-organization back to the community to get Solr properly Mavenized so that it can be distributed and released more often. For us the benefit of this structure is that we will be able to overlay addons such as RequestHandlers and other third party support without having to rebuild Solr from scratch. But you don't have to rebuild Solr from scratch to add a new request handler or other plugins - simply compile your custom stuff into a JAR and put it in solr-home/lib (or point to it with lib in solrconfig.xml). Tu chez! Ideally, a Maven Archetype could be created that would allow one rapidly produce a Solr webapp and fire it up in Jetty in mere seconds. How's that any different than cd example; java -jar start.jar? Or do you mean a Solr client webapp? mvn package jetty:run Its not much different, but it is different in that its webapplication and development tool centric, theres no special startup code, thats just using maven+jetty or your debugging environment to fire up the war for testing. Finally, with projects such as Bobo, integration with Spring would make configuration more consistent and request significantly less java coding just to add new capabilities everytime someone authors a new RequestHandler. It's one line of config to add a new request handler. How many ridiculously ugly confusing lines of Spring XML would it take? But if I have my own configuration for that Request Handler, how many lines of java to I need to add/alter to get that configuration to parse in solr config and be available? Even if its just a few, its IMO, its still the wrong way to be cutting the cake. The biggest thing I learned about Solr in my work thusfar is that patches like these could be standalone modules in separate projects if it weren't for having to hack the configuration and solrj methods up to adopt them. Which brings me to SolrJ, great API if it would stay generic and have less concern for adding method each time some custom collections and query support for morelikethis or collapseddocs needs to be added. I personally find it silly that we customize SolrJ for all these request handlers anyway. You get a decent navigable data structure back from general SolrJ query requests as it is, there's no need
Re: Field Collapsing SOLR-236
Blargy? I produced a patched version of Solr 1.4 and released it into the maven central repository under our DSpace groupid as a dependency for our applications. Your welcome to test it out and use our code for examples. Although, it is not the most recent patch of Field Collapsing, it has been sufficient for our work until then FeildCollapsing solution is finalized. Solr 1.4 + FieldCollapse Patch http://scm.dspace.org/svn/repo/modules/dspace-solr/trunk/ http://scm.dspace.org/svn/repo/modules/dspace-discovery/trunk/ I have just recently made the release available... http://repo2.maven.org/maven2/org/dspace/dependencies/solr/ Mark p.s. I'd be glad to contribute our Maven build re-organization back to the community to get Solr properly Mavenized so that it can be distributed and released more often. For us the benefit of this structure is that we will be able to overlay addons such as RequestHandlers and other third party support without having to rebuild Solr from scratch. Ideally, a Maven Archetype could be created that would allow one rapidly produce a Solr webapp and fire it up in Jetty in mere seconds. Finally, with projects such as Bobo, integration with Spring would make configuration more consistent and request significantly less java coding just to add new capabilities everytime someone authors a new RequestHandler. The biggest thing I learned about Solr in my work thusfar is that patches like these could be standalone modules in separate projects if it weren't for having to hack the configuration and solrj methods up to adopt them. Which brings me to SolrJ, great API if it would stay generic and have less concern for adding method each time some custom collections and query support for morelikethis or collapseddocs needs to be added. On Jun 16, 2010, at 1:37 AM, Rakhi Khatwani wrote: Hi, I wanted to try out field collapsing for a requirement. i went through the wiki and solr-236. but there are lot of patch files. and the comments below left me confused. i tried applyin the patch file on 1.4.0 release but ended up with many compile errors. i even downloaded the latest code from the repository and applied the patch(solr-trunk-236 dtd 16th May 2010). but ended up with build errors. Can someone tell me which patch file to apply on which build? so that i can get collapsing working? Regards, Raakhi. On Thu, Mar 25, 2010 at 11:15 PM, Rob Z zman...@hotmail.com wrote: What do you mean you had to revert to Trunk 1.5. Do you mean upgrade? Which version were you using before hand? Can you please list the exact version of 1.5 and the patch # you used. I downloaded the latest nightly build and tried patching using the 2/1 patch. Everything went ok but I am getting 1 failing test. Would you recommend using the latest nightly 1.5 build or 1.4 for production use? I really need this feature so I don't think I have much of a choice. Can you also explain the performance implications you are seeing AND what configuration tweaks you've used that helped. Thanks! From: mark.robe...@red-gate.com To: solr-user@lucene.apache.org Date: Thu, 25 Mar 2010 15:21:54 + Subject: RE: Field Collapsing SOLR-236 Yeah got it working fine - but I needed to revert to Trunk (1.5) to get the patch to apply. It does certainly have some performance implications, but tweaking configuration can help here. Overall the benefits very much outweigh the costs for us :) Mark. -Original Message- From: Dennis Gearon [mailto:gear...@sbcglobal.net] Sent: 25 March 2010 00:49 To: solr-user@lucene.apache.org Subject: Re: Field Collapsing SOLR-236 Boy, I hope that field collapsing works! I'm planning on using it heavily. Dennis Gearon Signature Warning EARTH has a Right To Life, otherwise we all die. Read 'Hot, Flat, and Crowded' Laugh at http://www.yert.com/film.php --- On Wed, 3/24/10, blargy zman...@hotmail.com wrote: From: blargy zman...@hotmail.com Subject: Field Collapsing SOLR-236 To: solr-user@lucene.apache.org Date: Wednesday, March 24, 2010, 12:17 PM Has anyone had any luck with the field collapsing patch (SOLR-236) with Solr 1.4? I tried patching my version of 1.4 with no such luck. Thanks -- View this message in context: http://old.nabble.com/Field-Collapsing-SOLR-236-tp28019949p28019949.html Sent from the Solr - User mailing list archive at Nabble.com. _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. http://clk.atdmt.com/GBL/go/210850552/direct/01/
Can multiple Solr webapps access the same lucene index files?
Hello, I have a question I can't find an answer to in the list. Can mutliple solr webapps (for instance in separate cluster nodes) share the same lucene index files stored within a shared filesystem? We do this with a custom Lucene search application right now, I'm trying to switch to using solr and am curious if we can use the same deployment strategy. Mark
