Building Solr with Maven 2 - Solr-19
Hi I am trying to build solr from solr-19 poms from the issue tracker. I've tried both of the most recent poms but pehaps it is my inexperience with maven that may be the issue. I have been reading up on maven but perhaps I am missing something. For the combined pom.xml (Jan 9 2008, Ryan McKinley) I placed it in the source directory and ran: mvn clean install The build failed indicating issues with the following files with serveral line numbes in the following files. I've only cut and pasted the first line of each src/java/org/apache/solr/handler/component/ShardRequest.java:[60,0] 'class' or 'interface' expected src/java/src/test/org/apache/solr/TestDistributedSearch.java:[129,0] 'class' or 'interface' expected src/java/src/java/org/apache/solr/handler/component/ShardDoc.java:[273,0] 'class' or 'interface' expected the trace running mvn -e is below. In any case, this was unsuccessful. For the pom that does the builds with solr in separate packages (solr-test-maven.zip, Dec 27 2007, Ryan McKinley) I unzipped the folders and the two poms to the source directory and ran mvn clean install mvn jetty:run It build successfully - see result below. Problem was how to run it. mvn jetty:run did not launch the server. Am i missing a step? Any hints would be helpful. Many thanks. Regards, David Build using combined pom.xml: [INFO] [INFO] Trace org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:516) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more [INFO] [INFO] Total time: 23 seconds [INFO] Finished at: Sat Jan 26 02:00:52 AST 2008 [INFO] Final Memory: 6M/21M [INFO] Build using solr-test-maven.zip: /Users/davidpratt/.m2/repository/org/apache/lucene/solr/solr-server/1.3-SNAPSHOT/solr-server-1.3-SNAPSHOT-tests.jar [INFO] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Solr Parent ... SUCCESS [31.160s] [INFO] Solr Common ... SUCCESS [15.464s] [INFO] Solr Client ... SUCCESS [7.087s] [INFO] Solr Core . SUCCESS [9.945s] [INFO] Solr Server ... SUCCESS [5.514s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 minute 15 seconds [INFO] Finished at: Sat Jan 26 10:38:32 AST 2008 [INFO] Final Memory: 12M/25M [INFO] -
Re: Building Solr with Maven 2 - Solr-19
I just posted the pom.xml I am using with the current trunk code. Give that a go. src/java/org/apache/solr/handler/component/ShardRequest.java:[60,0] 'class' or 'interface' expected src/java/src/test/org/apache/solr/TestDistributedSearch.java:[129,0] 'class' or 'interface' expected src/java/src/java/org/apache/solr/handler/component/ShardDoc.java:[273,0] 'class' or 'interface' expected This is not in trunk yet -- my guess is you are applying a SOLR-303 patch that is not in sync. make sure 'ant' works before trying to debug maven (for now) ryan
Re: spellcheckhandler
Anuvenk, I may be partially wrong on my prior statement. I created that JavaDoc comment as part of my work on the spellcheck handler so I might have been wrong about it being 100% superseded. There is a chance that although the code was changed, the JavaDocs were not updated (they are merely comments in the source code). Off hand I cannot comment on what has changed since my work load at work has shifted and I have yet to implement a spell checker within the project that needs it (a biomedical project focused on genetic based diseases, so hence the medical terms in the JavaDocs). But I think I recall reviewing the daily builds a few months ago that not only has the parameters been altered (for the better I think), but also the structure of the generated XML. Originally, the purpose of "multiWords" was to internally break a multi word string in to individual components and have each component checked individually, as what you were expecting and hence your confusion if it is no longer supported. So, I am sorry for any confusion but I don't know the current status of the handler. Best of luck! Scott Tabar anuvenk <[EMAIL PROTECTED]> wrote: Thanks. But i'm looking at this http://.../spellchecker?indent=on&onlyMorePopular=true&accuracy=.6&suggestionCount=20&q=facial+salophosphoprotein on http://lucene.apache.org/solr/api/org/apache/solr/handler/SpellCheckerRequestHandler.html It seems to return results (well in the example) with and without extendedResults=true does it mean that 'facial salophosphoprotein' was a single term in the index. hossman wrote: > > : > : I did try with the latest nightly build and followed the steps outlined > in > : http://wiki.apache.org/solr/SpellCheckerRequestHandler > : with regards to creating new catchall field 'spell' of type 'spell' and > : copied my text fields to 'spell' at index time. > : Still q=grapics returns 'graphics' > : but q=grapics card returns nothing. > : But the same queries return the correct spelling with string fieldtypes. > : Any fix available? > > I don't think Otis was suggesting any specific fix was available in the > nightly builds, i believe he was just addressing specificly that if there > was a bug someone commited a fix for you didnt' need to wait for 1.3 -- > you can test it now using the nightly builds. > > That said: I don't see any currently open or recent resolved bugs > related to spellchecking and multiple words ... i believe (but i'm not > 100% positive) that "multi word" spell correction will work, as long as > your dictionary contaisn those "multiple words" as individual "terms" > > ie: if you want "graphics card" to be a suggestion for "grapics card" then > you need to use a termSourceField in which "graphics card" is a single > term (either because it is untokenized, or maybe because you use a > word-based ngram tokenfilter, etc...) > > alternately, if you want to get "graphics asdfghjk" as a suggestion for > "grapics asdfghjk" (even though "asdfghjk" isn't in your index at all), > hiting the spellcorrection handler for each input word individually is > probably your best bet. > > > : > You don't need to wait for 1.3 to be released - you can simply use a > : > recent nightly build. > > > -Hoss > > > -- View this message in context: http://www.nabble.com/spellcheckhandler-tp14627712p15100704.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Spell Check Handler
Anuvenk, I see you are asking the same question multiple times and you have quoted one of my older postings on the SpellingCheckerRequestHandler that I submitted a while ago. Sorry to inform you that those postings no longer apply, since the work I done was superseded with another release and as such the instructions may no longer apply. Best of luck in resolving your issues. Scott Tabar anuvenk <[EMAIL PROTECTED]> wrote: I followed your instructions exactly. But still have trouble with multiword queries for eg: q=grapics returns 'graphics' but q=grapics card returns nothing. I even tried with the latest nightly build but didn't solve the problem. Any solution available. scott.tabar wrote: > > Matthew, > > Thanks for the question. The answer is that they come from your own > indexes so the dictionary is based upon the actual words that are already > stored in Solr. This makes sense; if the spell checker is suggesting a > word that is not in the Solr index, then it will not help the user find > what they are looking for. > > You can control which fields in Solr can feed the spell checker. Also you > can have more than one spell checker that is focused on a specific > subjects. > > The following example of a SpellCheckerRequestHandler is based upon the > one I created for the test case. You need to add this to yor > solrconfig.xml file. You can view the whole thing within the Solr source > code once it is commited in to the main stream. The path is: > /src/test/test-files/solr/conf/solrconfig-spellchecker.xml and > schema-spellchecker.xml in the same directory. > > >class="solr.SpellCheckerRequestHandler" startup="lazy"> > > >20 >0.60 > > > > > > > > spell > > > > > spell > > > > Some comments: > - The termSourceField should be a field you have defined within your > solr schema file. See notes below about the use of this field. > - The spellcheckeerIndexDir is the name of the directory that contain > the spellchecker indexes. In my example, I used spell, and it will be at > the same level of data and conf. You can name it what ever you would like > to. > - if you use the name of "/spellchecker" the url will be more RESTful > - if you need to have more than one spell checker in use at a time, then > you will need to change the name, spellcheckerIndexDir, and > termSourceField > - If you have more than one spell checker hitting the same index > directory, then when you rebuild the index through one of the handlers the > other handlers will not know it has been reindexed. To resolve this > issue, you may have to restart Solr. > > > The following components are from the schema-spellchecker.xml file: > >positionIncrementGap="100"> > > >words="stopwords.txt"/> > > > > > >ignoreCase="true" expand="true"/> >words="stopwords.txt"/> > > > > > > > > > > > Some comments on Schema items above: > - The fieldType must be contained within the types > - The spellText content can be named what every you want > - The spellText fieldType should not be too aggressive on stemming or > modifying the the contents of the field > - Could use string instead of the defined fieldType of spellText, but it > does not have to be that restrictive > > - The field spellText needs to be within the "fields" group with your > other defined fields > - You could always use the copyField to either copy another fields > content into your "spell" field: > > > > Some notes on the name of the handler: > - If you precede the name with "/" you can use the following url instead > of the second one: > - using the name of "/spellchecker" > http://yourSolrSite/solr/spellchecker?q=sialophosphoprotein > - using the name of "spellchecker" > http://yourSolrSite/solr/select?qt=spellchecker&q=sialophosphoprotein > > > Matthew, I hope you find this somewhat helpful. > >Scott Tabar > > Matthew Runo <[EMAIL PROTECTED]> wrote: > Where does the index come from in the first place? Do we have to > enter the words, or are they entered as documents enter the SOLR index? > > I'd love to be able to use my own documents as the spell check index > of "correctly spelled words". > > ++ > | Matthew Runo > | Zappos Development > | [EMAIL PROTECTED] > | 702-943-7833 > ++ > > > On Oct 11, 2007, at 7:08 AM, <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> wrote: > >> Climbingrose, >> >> I think you make a valid point. Each person may have a different >> concept of how something should work with their application. >> >> My thought on the subject of spell checking multiple words:
Re: spellcheckhandler
Anuvenk, Sorry for this "Third" email, but I was reading your question below and I think it warrants yet another reply. Just some background from my focus and involvement, and hence the generation of the JavaDocs. I was primarily interested in having a Solr based spell checker that behaved more like a traditional spell checker. In my application, when I generated the input in to Solr for inclusion of the spell checker indexer, I was only interested in single words and not multi-word sets. My intentions was to send multiple words to the handler and have it return details on each word as it stands independently when the parameter multiWords was set, otherwise it was to use all input words as a single check against the handler. As such, in my original efforts, I had no multiple words in a single term, as you were asking below. That is not to say it is not possible, but I just wanted to let you know the original focus of my work. I did look a little closer at the JavaDocs and it looks like they have been updated from what I originally generated. So perhaps they may be up to date? One thing I would like to point out, is that I put some efforts in creating a test case for the SpellCheckerRequestHandler. If it still exists (I have not checked the head for a long time) then it would be a good starting point to do some simple testing with limited data sets of your own. Just make a copy of it, and then feed in multi-word terms and see how it responds do the different settings. This will also allow you to play around with the configuration settings in the schema and solrconfig files without impacting your actual Solr instance and the turn around time could be in the seconds and not minutes with each alteration of a new test. The locations in svn and file names of the unit tests that I created were: /test/test-files/solr/conf/schema-spellchecker.xml /test/test-files/solr/conf/solrconfig-spellchecker.xml /test/org/apache/solr/handler/SpellCheckerRequestHandlerTest.java If these do not existing in svn currently, let me know and I can pass along the contents and you can recreate them locally to test with. Best of luck, Scott Tabar anuvenk <[EMAIL PROTECTED]> wrote: Thanks. But i'm looking at this http://.../spellchecker?indent=on&onlyMorePopular=true&accuracy=.6&suggestionCount=20&q=facial+salophosphoprotein on http://lucene.apache.org/solr/api/org/apache/solr/handler/SpellCheckerRequestHandler.html It seems to return results (well in the example) with and without extendedResults=true does it mean that 'facial salophosphoprotein' was a single term in the index. hossman wrote: > > : > : I did try with the latest nightly build and followed the steps outlined > in > : http://wiki.apache.org/solr/SpellCheckerRequestHandler > : with regards to creating new catchall field 'spell' of type 'spell' and > : copied my text fields to 'spell' at index time. > : Still q=grapics returns 'graphics' > : but q=grapics card returns nothing. > : But the same queries return the correct spelling with string fieldtypes. > : Any fix available? > > I don't think Otis was suggesting any specific fix was available in the > nightly builds, i believe he was just addressing specificly that if there > was a bug someone commited a fix for you didnt' need to wait for 1.3 -- > you can test it now using the nightly builds. > > That said: I don't see any currently open or recent resolved bugs > related to spellchecking and multiple words ... i believe (but i'm not > 100% positive) that "multi word" spell correction will work, as long as > your dictionary contaisn those "multiple words" as individual "terms" > > ie: if you want "graphics card" to be a suggestion for "grapics card" then > you need to use a termSourceField in which "graphics card" is a single > term (either because it is untokenized, or maybe because you use a > word-based ngram tokenfilter, etc...) > > alternately, if you want to get "graphics asdfghjk" as a suggestion for > "grapics asdfghjk" (even though "asdfghjk" isn't in your index at all), > hiting the spellcorrection handler for each input word individually is > probably your best bet. > > > : > You don't need to wait for 1.3 to be released - you can simply use a > : > recent nightly build. > > > -Hoss > > > -- View this message in context: http://www.nabble.com/spellcheckhandler-tp14627712p15100704.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: spellcheckhandler
Thanks a lot for clearing my doubts. Would you know if the solr wiki is up to date with the documentation for the new features that are being added? I totally rely on the solr wiki documentation for my project. If you may, please send me the files you had mentioned and i'll be happy to test them. I appreciate your help !! scott.tabar wrote: > > Anuvenk, > > Sorry for this "Third" email, but I was reading your question below and I > think it warrants yet another reply. > > Just some background from my focus and involvement, and hence the > generation of the JavaDocs. I was primarily interested in having a Solr > based spell checker that behaved more like a traditional spell checker. > In my application, when I generated the input in to Solr for inclusion of > the spell checker indexer, I was only interested in single words and not > multi-word sets. My intentions was to send multiple words to the handler > and have it return details on each word as it stands independently when > the parameter multiWords was set, otherwise it was to use all input words > as a single check against the handler. As such, in my original efforts, I > had no multiple words in a single term, as you were asking below. That is > not to say it is not possible, but I just wanted to let you know the > original focus of my work. > > I did look a little closer at the JavaDocs and it looks like they have > been updated from what I originally generated. So perhaps they may be up > to date? > > One thing I would like to point out, is that I put some efforts in > creating a test case for the SpellCheckerRequestHandler. If it still > exists (I have not checked the head for a long time) then it would be a > good starting point to do some simple testing with limited data sets of > your own. Just make a copy of it, and then feed in multi-word terms and > see how it responds do the different settings. This will also allow you > to play around with the configuration settings in the schema and > solrconfig files without impacting your actual Solr instance and the turn > around time could be in the seconds and not minutes with each alteration > of a new test. > > The locations in svn and file names of the unit tests that I created were: > /test/test-files/solr/conf/schema-spellchecker.xml > /test/test-files/solr/conf/solrconfig-spellchecker.xml > /test/org/apache/solr/handler/SpellCheckerRequestHandlerTest.java > > If these do not existing in svn currently, let me know and I can pass > along the contents and you can recreate them locally to test with. > > Best of luck, > Scott Tabar > > anuvenk <[EMAIL PROTECTED]> wrote: > > Thanks. But i'm looking at this > http://.../spellchecker?indent=on&onlyMorePopular=true&accuracy=.6&suggestionCount=20&q=facial+salophosphoprotein > on > http://lucene.apache.org/solr/api/org/apache/solr/handler/SpellCheckerRequestHandler.html > It seems to return results (well in the example) > with and without extendedResults=true > does it mean that 'facial salophosphoprotein' was a single term in the > index. > > > hossman wrote: >> >> : >> : I did try with the latest nightly build and followed the steps outlined >> in >> : http://wiki.apache.org/solr/SpellCheckerRequestHandler >> : with regards to creating new catchall field 'spell' of type 'spell' and >> : copied my text fields to 'spell' at index time. >> : Still q=grapics returns 'graphics' >> : but q=grapics card returns nothing. >> : But the same queries return the correct spelling with string >> fieldtypes. >> : Any fix available? >> >> I don't think Otis was suggesting any specific fix was available in the >> nightly builds, i believe he was just addressing specificly that if there >> was a bug someone commited a fix for you didnt' need to wait for 1.3 -- >> you can test it now using the nightly builds. >> >> That said: I don't see any currently open or recent resolved bugs >> related to spellchecking and multiple words ... i believe (but i'm not >> 100% positive) that "multi word" spell correction will work, as long as >> your dictionary contaisn those "multiple words" as individual "terms" >> >> ie: if you want "graphics card" to be a suggestion for "grapics card" >> then >> you need to use a termSourceField in which "graphics card" is a single >> term (either because it is untokenized, or maybe because you use a >> word-based ngram tokenfilter, etc...) >> >> alternately, if you want to get "graphics asdfghjk" as a suggestion for >> "grapics asdfghjk" (even though "asdfghjk" isn't in your index at all), >> hiting the spellcorrection handler for each input word individually is >> probably your best bet. >> >> >> : > You don't need to wait for 1.3 to be released - you can simply use a >> : > recent nightly build. >> >> >> -Hoss >> >> >> > > -- > View this message in context: > http://www.nabble.com/spellcheckhandler-tp14627712p15100704.html > Sent from the Solr - User mailing list archive at Nabb
Re: Building Solr with Maven 2 - Solr-19
Hey Ryan. You were right about SOLR-303. I checked out trunk from svn, patched source, ran the pom and manually ran the commons pom and it all built fine. Only trouble is I am not providing the right incantation for maven to start the server. This I am sure will all seem very simple once I have got this working at least the first time but I need a hint :-) Many thanks. Regards, David Ryan McKinley wrote: I just posted the pom.xml I am using with the current trunk code. Give that a go. src/java/org/apache/solr/handler/component/ShardRequest.java:[60,0] 'class' or 'interface' expected src/java/src/test/org/apache/solr/TestDistributedSearch.java:[129,0] 'class' or 'interface' expected src/java/src/java/org/apache/solr/handler/component/ShardDoc.java:[273,0] 'class' or 'interface' expected This is not in trunk yet -- my guess is you are applying a SOLR-303 patch that is not in sync. make sure 'ant' works before trying to debug maven (for now) ryan
Re: Building Solr with Maven 2 - Solr-19
aaah -- mvn jetty:run does not work with that pom you can run the example server from the example directory using "java -jar start.jar" check: http://lucene.apache.org/solr/tutorial.html ryan David Pratt wrote: Hey Ryan. You were right about SOLR-303. I checked out trunk from svn, patched source, ran the pom and manually ran the commons pom and it all built fine. Only trouble is I am not providing the right incantation for maven to start the server. This I am sure will all seem very simple once I have got this working at least the first time but I need a hint :-) Many thanks. Regards, David Ryan McKinley wrote: I just posted the pom.xml I am using with the current trunk code. Give that a go. src/java/org/apache/solr/handler/component/ShardRequest.java:[60,0] 'class' or 'interface' expected src/java/src/test/org/apache/solr/TestDistributedSearch.java:[129,0] 'class' or 'interface' expected src/java/src/java/org/apache/solr/handler/component/ShardDoc.java:[273,0] 'class' or 'interface' expected This is not in trunk yet -- my guess is you are applying a SOLR-303 patch that is not in sync. make sure 'ant' works before trying to debug maven (for now) ryan
