Solr-3.x - Build # 214 - Still Failing
Build: https://hudson.apache.org/hudson/job/Solr-3.x/214/ All tests passed Build Log (for compile errors): [...truncated 20224 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2611) IntelliJ IDEA and Eclipse setup
[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976371#action_12976371
]
Lance Norskog commented on LUCENE-2611:
---
About making it easier to contribute with patches: what makes this easy is Git
or Mercurial, not an IDE. If you make a local Git repository matching your
checkout you can make separate branches for each project. Git is way too
flexible and confusing, but I can't live without it now.
You can do a full GIT checkout from the links on git.apache.org. There is a
nice GIT extension for Eclipse that makes it really easy to manage branches.
Cheers, Lance.
> IntelliJ IDEA and Eclipse setup
> ---
>
> Key: LUCENE-2611
> URL: https://issues.apache.org/jira/browse/LUCENE-2611
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Build
>Affects Versions: 3.1, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611_eclipse.patch, LUCENE-2611_mkdir.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test.patch, LUCENE-2611_test.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test_2.patch
>
>
> Setting up Lucene/Solr in IntelliJ IDEA or Eclipse can be time-consuming.
> The attached patches add a new top level directory {{dev-tools/}} with
> sub-dirs {{idea/}} and {{eclipse/}} containing basic setup files for trunk,
> as well as top-level ant targets named "idea" and "eclipse" that copy these
> files into the proper locations. This arrangement avoids the messiness
> attendant to in-place project configuration files directly checked into
> source control.
> The IDEA configuration includes modules for Lucene and Solr, each Lucene and
> Solr contrib, and each analysis module. A JUnit run configuration per module
> is included.
> The Eclipse configuration includes a source entry for each
> source/test/resource location and classpath setup: a library entry for each
> jar.
> For IDEA, once {{ant idea}} has been run, the only configuration that must be
> performed manually is configuring the project-level JDK. For Eclipse, once
> {{ant eclipse}} has been run, the user has to refresh the project
> (right-click on the project and choose Refresh).
> If these patches is committed, Subversion svn:ignore properties should be
> added/modified to ignore the destination IDEA and Eclipse configuration
> locations.
> Iam Jambour has written up on the Lucene wiki a detailed set of instructions
> for applying the 3.X branch patch for IDEA:
> http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2611) IntelliJ IDEA and Eclipse setup
[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976370#action_12976370
]
Lance Norskog commented on LUCENE-2611:
---
Robert, thank you for this grand effort. After a few times, I can set it up
faster now but it's still a pain.
Now, the last thing you want to hear :) I use Eclipse text search a lot and
it's much faster when a code based is split between a few projects instead of
one large project. Maybe I can help on that one.
> IntelliJ IDEA and Eclipse setup
> ---
>
> Key: LUCENE-2611
> URL: https://issues.apache.org/jira/browse/LUCENE-2611
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Build
>Affects Versions: 3.1, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611_eclipse.patch, LUCENE-2611_mkdir.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test.patch, LUCENE-2611_test.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test_2.patch
>
>
> Setting up Lucene/Solr in IntelliJ IDEA or Eclipse can be time-consuming.
> The attached patches add a new top level directory {{dev-tools/}} with
> sub-dirs {{idea/}} and {{eclipse/}} containing basic setup files for trunk,
> as well as top-level ant targets named "idea" and "eclipse" that copy these
> files into the proper locations. This arrangement avoids the messiness
> attendant to in-place project configuration files directly checked into
> source control.
> The IDEA configuration includes modules for Lucene and Solr, each Lucene and
> Solr contrib, and each analysis module. A JUnit run configuration per module
> is included.
> The Eclipse configuration includes a source entry for each
> source/test/resource location and classpath setup: a library entry for each
> jar.
> For IDEA, once {{ant idea}} has been run, the only configuration that must be
> performed manually is configuring the project-level JDK. For Eclipse, once
> {{ant eclipse}} has been run, the user has to refresh the project
> (right-click on the project and choose Refresh).
> If these patches is committed, Subversion svn:ignore properties should be
> added/modified to ignore the destination IDEA and Eclipse configuration
> locations.
> Iam Jambour has written up on the Lucene wiki a detailed set of instructions
> for applying the 3.X branch patch for IDEA:
> http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: strange problem of PForDelta decoder
Please purchase and read Lucene In Action 2. It will explain how all of this works and how to used Lucene efficiently. http://www.lucidimagination.com/blog/2009/03/11/lia2/ http://www.lucidimagination.com/blog/2010/08/01/lucene-in-action-2d-edition-authors-round-table-podcast/ http://www.lucidimagination.com/Community/Hear-from-the-Experts/Podcasts-and-Videos/Lucene-in-Action It is available from Manning as a downloadable E-Book (PDF) so you don't have to wait for it to be shipped. 2010/12/30 Li Li : > is there anyone familiar with MG4J(http://mg4j.dsi.unimi.it/) > it says Multithreading. Indices can be queried and scored concurrently. > maybe we can learn something from it. > > 2010/12/31 Li Li : >> plus >> 2 means search a term need seek many times for tis(if it's not cached in tii) >> >> 2010/12/31 Li Li : >>> searching multi segments is a alternative solution but it has some >>> disadvantages. >>> 1. idf is not global?(I am not familiar with its implementation) maybe >>> it's easy to solve it by share global idf >>> 2. each segments will has it's own tii and tis files, which may make >>> search slower(that's why optimization of >>> index is neccessary) >>> 3. one term's docList is distributed in many files rather than one. >>> more than one frq files means >>> hard disk must seek different tracks, it's time consuming. if there is >>> only one segment, the are likely >>> stored in a single track. >>> >>> >>> 2010/12/31 Earwin Burrfoot : >>>until we fix Lucene to run a single search concurrently (which we >>>badly need to do). > I am interested in this idea.(I have posted it before) do you have some > resources such as papers or tech articles about it? > I have tried but it need to modify index format dramatically and we use > solr distributed search to relieve the problem of response time. so > finally > give it up. > lucene4's index format is more flexible that it supports customed codecs > and it's now on development, I think it's good time to take it into > consideration > that let it support multithread searching for a single query. > I have a naive solution. dividing docList into many groups > e.g grouping docIds by it's even or odd > term1 df1=4 docList = 0 4 8 10 > term1 df2=4 docList = 1 3 9 11 > > term2 df1=4 docList = 0 6 8 12 > term2 df2=4 docList = 3 9 11 15 > then we can use 2 threads to search topN docs on even group and odd > group > and finally merge their results into a single on just like solr > distributed search. > But it's better than solr distributed search. > First, it's in a single process and data communication between > threads is much > faster than network. > Second, each threads process the same number of documents.For solr > distributed > search, one shard may process 7 documents and another shard may 1 document > Even if we can make each shard have the same document number. we can not > make it uniformly for each term. > e.g. shard1 has doc1 doc2 > shard2 has doc3 doc4 > but term1 may only occur in doc1 and doc2 > while term2 may only occur in doc3 and doc4 > we may modify it > shard1 doc1 doc3 > shard2 doc2 doc4 > it's good for term1 and term2 > but term3 may occur in doc1 and doc3... > So I think it's fine-grained distributed in index while solr > distributed search is coarse- > grained. This is just crazy :) The simple way is just to search different segments in parallel. BalancedSegmentMergePolicy makes sure you have roughly even-sized large segments (and small ones don't count, they're small!). If you're bound on squeezing out that extra millisecond (and making your life miserable along the way), you can search a single segment with multiple threads (by dividing it in even chunks, and then doing skipTo to position your iterators to the beginning of each chunk). First approach is really easy to implement. Second one is harder, but still doesn't require you to cook the number of CPU cores available into your index! It's the law of diminishing returns at play here. You're most likely to search in parallel over mostly memory-resident index (RAMDir/mmap/filesys cache - doesn't matter), as most of IO subsystems tend to slow down considerably on parallel sequential reads, so you already have pretty decent speed. Searching different segments in parallel (with BSMP) makes you several times faster. Searching in parallel within a segment requires some weird hacks, but has maybe a few percent advantage over previous solution. Sharding posting lists requires a great deal of weird hacks, makes index machine-bound, and boosts speed by another couple of percent. Sounds worthless. -- Kirill Za
Lucene-3.x - Build # 228 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-3.x/228/ All tests passed Build Log (for compile errors): [...truncated 20926 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2299) improve test-running from eclipse
[ https://issues.apache.org/jira/browse/SOLR-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976359#action_12976359 ] Yonik Seeley commented on SOLR-2299: bq. as for speed the tests are the same here, like 2 minutes. but, if dih is spewing exceptions, the test runner buffering could be slowing you down Hmmm, I was unable to reproduce the slowdown - false alarm! > improve test-running from eclipse > - > > Key: SOLR-2299 > URL: https://issues.apache.org/jira/browse/SOLR-2299 > Project: Solr > Issue Type: Test > Components: Build >Reporter: Robert Muir > Fix For: 3.1, 4.0 > > Attachments: SOLR-2299.patch, SOLR-2299.patch, SOLR-2299_part2.patch > > > In eclipse, its currently difficult to get a solr development environment > working. > One big thing that would help would be to make it easier to run the tests. > When loading resources, if we checked the config dir + file directory from > the resource path, > then users could simply add src/test/test-files to their eclipse build > classpath, and tests would just work from the IDE. > I gather that this might make things easier for other IDEs too, though I'm > aware that ones like Intellij > let you configure the test 'working directory' on a project basis, but > eclipse doesn't > (you have to make a custom run configuration every time you run the tests) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2299) improve test-running from eclipse
[ https://issues.apache.org/jira/browse/SOLR-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976358#action_12976358 ] Robert Muir commented on SOLR-2299: --- looks like a bug in dih, masked all along because we set the CWD before. I think it is not properly respecting solr home? but trying to write to solr/... as for speed the tests are the same here, like 2 minutes. but, if dih is spewing exceptions, the test runner buffering could be slowing you down, I think we should open an issue to fix this bug in dih... this issue merely unmasked it > improve test-running from eclipse > - > > Key: SOLR-2299 > URL: https://issues.apache.org/jira/browse/SOLR-2299 > Project: Solr > Issue Type: Test > Components: Build >Reporter: Robert Muir > Fix For: 3.1, 4.0 > > Attachments: SOLR-2299.patch, SOLR-2299.patch, SOLR-2299_part2.patch > > > In eclipse, its currently difficult to get a solr development environment > working. > One big thing that would help would be to make it easier to run the tests. > When loading resources, if we checked the config dir + file directory from > the resource path, > then users could simply add src/test/test-files to their eclipse build > classpath, and tests would just work from the IDE. > I gather that this might make things easier for other IDEs too, though I'm > aware that ones like Intellij > let you configure the test 'working directory' on a project basis, but > eclipse doesn't > (you have to make a custom run configuration every time you run the tests) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2299) improve test-running from eclipse
[
https://issues.apache.org/jira/browse/SOLR-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976357#action_12976357
]
Yonik Seeley commented on SOLR-2299:
I think I'm seeing more exceptions come out of the DIH tests (and the complete
solr test suite suddenly takes longer to run too... from ~5 to ~8 min). Looks
like it may be related to this issue/changes?
{code}
[junit] SEVERE: Could not write property file
[junit] org.apache.solr.handler.dataimport.DataImportHandlerException:
Unable to persist Index Start Time Processing Document # 2
[junit] at
org.apache.solr.handler.dataimport.SolrWriter.persist(SolrWriter.java:111)
[...]
[junit] Caused by: java.io.FileNotFoundException:
solr-dih\conf\dataimport.properties (The system cannot find the path specified)
[junit] at java.io.FileOutputStream.open(Native Method)
[junit] at java.io.FileOutputStream.(FileOutputStream.java:179)
[junit] at java.io.FileOutputStream.(FileOutputStream.java:70)
[junit] at
org.apache.solr.handler.dataimport.SolrWriter.persist(SolrWriter.java:107)
{code}
This doesn't cause the test to fail for some reason...
Some of the methods are ignored because of TZ issues... but not all seem to
fall into that category.
> improve test-running from eclipse
> -
>
> Key: SOLR-2299
> URL: https://issues.apache.org/jira/browse/SOLR-2299
> Project: Solr
> Issue Type: Test
> Components: Build
>Reporter: Robert Muir
> Fix For: 3.1, 4.0
>
> Attachments: SOLR-2299.patch, SOLR-2299.patch, SOLR-2299_part2.patch
>
>
> In eclipse, its currently difficult to get a solr development environment
> working.
> One big thing that would help would be to make it easier to run the tests.
> When loading resources, if we checked the config dir + file directory from
> the resource path,
> then users could simply add src/test/test-files to their eclipse build
> classpath, and tests would just work from the IDE.
> I gather that this might make things easier for other IDEs too, though I'm
> aware that ones like Intellij
> let you configure the test 'working directory' on a project basis, but
> eclipse doesn't
> (you have to make a custom run configuration every time you run the tests)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2611) IntelliJ IDEA and Eclipse setup
[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976353#action_12976353
]
Robert Muir commented on LUCENE-2611:
-
ok, you should be able to checkout a project with subclipse (svn location:
https://svn.apache.org/repos/asf/lucene/dev/trunk)
After the svn checkout is done, run 'ant eclipse'. Then refresh your project...
and things should work.
I'll backport to 3.x and try to improve the docs etc later.
> IntelliJ IDEA and Eclipse setup
> ---
>
> Key: LUCENE-2611
> URL: https://issues.apache.org/jira/browse/LUCENE-2611
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Build
>Affects Versions: 3.1, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611_eclipse.patch, LUCENE-2611_mkdir.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test.patch, LUCENE-2611_test.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test_2.patch
>
>
> Setting up Lucene/Solr in IntelliJ IDEA or Eclipse can be time-consuming.
> The attached patches add a new top level directory {{dev-tools/}} with
> sub-dirs {{idea/}} and {{eclipse/}} containing basic setup files for trunk,
> as well as top-level ant targets named "idea" and "eclipse" that copy these
> files into the proper locations. This arrangement avoids the messiness
> attendant to in-place project configuration files directly checked into
> source control.
> The IDEA configuration includes modules for Lucene and Solr, each Lucene and
> Solr contrib, and each analysis module. A JUnit run configuration per module
> is included.
> The Eclipse configuration includes a source entry for each
> source/test/resource location and classpath setup: a library entry for each
> jar.
> For IDEA, once {{ant idea}} has been run, the only configuration that must be
> performed manually is configuring the project-level JDK. For Eclipse, once
> {{ant eclipse}} has been run, the user has to refresh the project
> (right-click on the project and choose Refresh).
> If these patches is committed, Subversion svn:ignore properties should be
> added/modified to ignore the destination IDEA and Eclipse configuration
> locations.
> Iam Jambour has written up on the Lucene wiki a detailed set of instructions
> for applying the 3.X branch patch for IDEA:
> http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
heads up: running solr tests from IDE
I have been working on SOLR-2299 because there is basically no way to run the solr tests from an eclipse IDE without hacks or changing your CWD each time. Anyway, the ant build system now works instead by putting test resources into the classpath (like lucene's). So if you are using an IDE or some custom python script you wrote or something else, you might have to change your configuration instead of changing your CWD to src/test/test-files or whatever it is for the various contribs. You can set the CWD to whatever you want (the default, or ideally something not located under source control like your build directory). For reference in the eclipse configuration this consists of adding the following to your classpath (source folders): solr/src/test/test-files, solr/contrib/analysis-extras/src/test/test-files, solr/contrib/clustering/src/test/resources, solr/contrib/dataimporthandler/src/test/resources, solr/contrib/dataimporthandler/src/extras/test/resources, solr/contrib/extraction/src/test/resources - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2841) CommonGramsFilter improvements
[
https://issues.apache.org/jira/browse/LUCENE-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976344#action_12976344
]
Steven Rowe commented on LUCENE-2841:
-
{quote}
bq. you still aren't ever removing any stopwords, but using this solely to
speed up phrase queries by forming bigrams around the common terms.
Isn't ShingleFilter for that case?
{quote}
On the index side: ShingleFilter generates token ngrams for all input tokens,
not just those around and including common words, so although it *could* be
used to speed up phrase queries, it would be at the expense of a much larger
term dicitionary.
On the query side: ShingleFilter could be a useful replacement for
CommonGramsQueryFilter if you don't have access to the list of words used by
CommonGramsFilter on the index side.
> CommonGramsFilter improvements
> --
>
> Key: LUCENE-2841
> URL: https://issues.apache.org/jira/browse/LUCENE-2841
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Analysis
>Affects Versions: 3.1, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 4.0
>
>
> Currently CommonGramsFilter expects users to remove the common words around
> which output token ngrams are formed, by appending a StopFilter to the
> analysis pipeline. This is inefficient in two ways: captureState() is called
> on (trailing) stopwords, and then the whole stream has to be re-examined by
> the following StopFilter.
> The current ctor should be deprecated, and another ctor added with a boolean
> option controlling whether the common words should be output as unigrams.
> If common words *are* configured to be output as unigrams, captureState()
> will still need to be called, as it is now.
> If the common words are *not* configured to be output as unigrams, rather
> than calling captureState() for the trailing token in each output token
> ngram, the term text, position and offset can be maintained in the same way
> as they are now for the leading token: using a System.arrayCopy()'d term
> buffer and a few ints for positionIncrement and offsetd. The user then no
> longer would need to append a StopFilter to the analysis chain.
> An example illustrating both possibilities should also be added.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2841) CommonGramsFilter improvements
[ https://issues.apache.org/jira/browse/LUCENE-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976343#action_12976343 ] Robert Muir commented on LUCENE-2841: - No, ShingleFilter forms bigrams around all terms, not just common ones. > CommonGramsFilter improvements > -- > > Key: LUCENE-2841 > URL: https://issues.apache.org/jira/browse/LUCENE-2841 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis >Affects Versions: 3.1, 4.0 >Reporter: Steven Rowe >Priority: Minor > Fix For: 3.1, 4.0 > > > Currently CommonGramsFilter expects users to remove the common words around > which output token ngrams are formed, by appending a StopFilter to the > analysis pipeline. This is inefficient in two ways: captureState() is called > on (trailing) stopwords, and then the whole stream has to be re-examined by > the following StopFilter. > The current ctor should be deprecated, and another ctor added with a boolean > option controlling whether the common words should be output as unigrams. > If common words *are* configured to be output as unigrams, captureState() > will still need to be called, as it is now. > If the common words are *not* configured to be output as unigrams, rather > than calling captureState() for the trailing token in each output token > ngram, the term text, position and offset can be maintained in the same way > as they are now for the leading token: using a System.arrayCopy()'d term > buffer and a few ints for positionIncrement and offsetd. The user then no > longer would need to append a StopFilter to the analysis chain. > An example illustrating both possibilities should also be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2841) CommonGramsFilter improvements
[ https://issues.apache.org/jira/browse/LUCENE-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976341#action_12976341 ] Jason Rutherglen commented on LUCENE-2841: -- bq. you still aren't ever removing any stopwords, but using this solely to speed up phrase queries by forming bigrams around the common terms. Isn't ShingleFilter for that case? > CommonGramsFilter improvements > -- > > Key: LUCENE-2841 > URL: https://issues.apache.org/jira/browse/LUCENE-2841 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis >Affects Versions: 3.1, 4.0 >Reporter: Steven Rowe >Priority: Minor > Fix For: 3.1, 4.0 > > > Currently CommonGramsFilter expects users to remove the common words around > which output token ngrams are formed, by appending a StopFilter to the > analysis pipeline. This is inefficient in two ways: captureState() is called > on (trailing) stopwords, and then the whole stream has to be re-examined by > the following StopFilter. > The current ctor should be deprecated, and another ctor added with a boolean > option controlling whether the common words should be output as unigrams. > If common words *are* configured to be output as unigrams, captureState() > will still need to be called, as it is now. > If the common words are *not* configured to be output as unigrams, rather > than calling captureState() for the trailing token in each output token > ngram, the term text, position and offset can be maintained in the same way > as they are now for the leading token: using a System.arrayCopy()'d term > buffer and a few ints for positionIncrement and offsetd. The user then no > longer would need to append a StopFilter to the analysis chain. > An example illustrating both possibilities should also be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2841) CommonGramsFilter improvements
[ https://issues.apache.org/jira/browse/LUCENE-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976338#action_12976338 ] Robert Muir commented on LUCENE-2841: - +1, this would be a great improvement. there are two basic use cases (that I see): # you still aren't ever removing any stopwords, but using this solely to speed up phrase queries by forming bigrams around the common terms. # you are using commongrams+stopfilter as a "stopfilter replacement", which gives a more reasonable index size, the relevance benefits of stopwords, but a user can always refine the query with double quotes and the stopwords are taken into consideration, and fast. the latter case currently requires you to also use a stopfilter, but it means we are doing needless captureState very very often (by definition, on common terms!). It also means you are specifying your stopwords list twice, and hashing two chararraysets, etc. So it would be nice to add the boolean and accelerate case #2. > CommonGramsFilter improvements > -- > > Key: LUCENE-2841 > URL: https://issues.apache.org/jira/browse/LUCENE-2841 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis >Affects Versions: 3.1, 4.0 >Reporter: Steven Rowe >Priority: Minor > Fix For: 3.1, 4.0 > > > Currently CommonGramsFilter expects users to remove the common words around > which output token ngrams are formed, by appending a StopFilter to the > analysis pipeline. This is inefficient in two ways: captureState() is called > on (trailing) stopwords, and then the whole stream has to be re-examined by > the following StopFilter. > The current ctor should be deprecated, and another ctor added with a boolean > option controlling whether the common words should be output as unigrams. > If common words *are* configured to be output as unigrams, captureState() > will still need to be called, as it is now. > If the common words are *not* configured to be output as unigrams, rather > than calling captureState() for the trailing token in each output token > ngram, the term text, position and offset can be maintained in the same way > as they are now for the leading token: using a System.arrayCopy()'d term > buffer and a few ints for positionIncrement and offsetd. The user then no > longer would need to append a StopFilter to the analysis chain. > An example illustrating both possibilities should also be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (LUCENE-2841) CommonGramsFilter improvements
CommonGramsFilter improvements -- Key: LUCENE-2841 URL: https://issues.apache.org/jira/browse/LUCENE-2841 Project: Lucene - Java Issue Type: Improvement Components: Analysis Affects Versions: 3.1, 4.0 Reporter: Steven Rowe Priority: Minor Fix For: 3.1, 4.0 Currently CommonGramsFilter expects users to remove the common words around which output token ngrams are formed, by appending a StopFilter to the analysis pipeline. This is inefficient in two ways: captureState() is called on (trailing) stopwords, and then the whole stream has to be re-examined by the following StopFilter. The current ctor should be deprecated, and another ctor added with a boolean option controlling whether the common words should be output as unigrams. If common words *are* configured to be output as unigrams, captureState() will still need to be called, as it is now. If the common words are *not* configured to be output as unigrams, rather than calling captureState() for the trailing token in each output token ngram, the term text, position and offset can be maintained in the same way as they are now for the leading token: using a System.arrayCopy()'d term buffer and a few ints for positionIncrement and offsetd. The user then no longer would need to append a StopFilter to the analysis chain. An example illustrating both possibilities should also be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (SOLR-2301) RSS Feed URL Breaking
[
https://issues.apache.org/jira/browse/SOLR-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976333#action_12976333
]
Adam Estrada edited comment on SOLR-2301 at 12/31/10 1:59 PM:
--
Hoss,
You are correct! When I replaced "&" with "& amp;" everything worked correctly.
Note the space in the HTML representation. I hope that others find this issue
useful!
v/r,
Adam
was (Author: adamestrada):
Hoss,
You are correct! When I replaced "&" with &
everything worked correctly. I hope that others find this issue useful!
v/r,
Adam
> RSS Feed URL Breaking
> -
>
> Key: SOLR-2301
> URL: https://issues.apache.org/jira/browse/SOLR-2301
> Project: Solr
> Issue Type: Bug
> Components: clients - C#
>Affects Versions: 1.4.1, 4.0
> Environment: Windows 7
>Reporter: Adam Estrada
>
> This is an odd oneI am trying to index RSS feeds and have come across
> several issues. Some are more pressing than others. Referring to SOLR-2286 ;-)
> Anyway, the CDC has a list of RSS feeds that the Solr dataimporter can't work
> with
> Home page:
> http://emergency.cdc.gov/rss/
> Page to Index:
> http://www2a.cdc.gov/podcasts/createrss.asp?t=r&c=19
> The console reports the following and as you can see it's because it does not
> like the param "c". Any ideas on how to fix this?
> INFO: Processing configuration from solrconfig.xml:
> {config=./solr/conf/dataimpo
> rthandler/rss.xml}
> [Fatal Error] :18:63: The reference to entity "c" must end with the ';'
> delimite
> r.
> Dec 28, 2010 2:39:46 PM org.apache.solr.handler.dataimport.DataImportHandler
> inf
> orm
> SEVERE: Exception while loading DataImporter
> org.apache.solr.handler.dataimport.DataImportHandlerException: Exception
> occurre
> d while initializing context
> at
> org.apache.solr.handler.dataimport.DataImporter.loadDataConfig(DataIm
> porter.java:193)
> at
> org.apache.solr.handler.dataimport.DataImporter.(DataImporter.j
> ava:100)
> at
> org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImpor
> tHandler.java:112)
> at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.jav
> a:539)
> at org.apache.solr.core.SolrCore.(SolrCore.java:596)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:660)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:412)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:294)
> at
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContain
> er.java:243)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (SOLR-2301) RSS Feed URL Breaking
[
https://issues.apache.org/jira/browse/SOLR-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976333#action_12976333
]
Adam Estrada edited comment on SOLR-2301 at 12/31/10 1:58 PM:
--
Hoss,
You are correct! When I replaced "&" with &
everything worked correctly. I hope that others find this issue useful!
v/r,
Adam
was (Author: adamestrada):
Hoss,
You are correct! When I replaced "&" with & amp; everything worked
correctly. I hope that others find this issue useful!
v/r,
Adam
> RSS Feed URL Breaking
> -
>
> Key: SOLR-2301
> URL: https://issues.apache.org/jira/browse/SOLR-2301
> Project: Solr
> Issue Type: Bug
> Components: clients - C#
>Affects Versions: 1.4.1, 4.0
> Environment: Windows 7
>Reporter: Adam Estrada
>
> This is an odd oneI am trying to index RSS feeds and have come across
> several issues. Some are more pressing than others. Referring to SOLR-2286 ;-)
> Anyway, the CDC has a list of RSS feeds that the Solr dataimporter can't work
> with
> Home page:
> http://emergency.cdc.gov/rss/
> Page to Index:
> http://www2a.cdc.gov/podcasts/createrss.asp?t=r&c=19
> The console reports the following and as you can see it's because it does not
> like the param "c". Any ideas on how to fix this?
> INFO: Processing configuration from solrconfig.xml:
> {config=./solr/conf/dataimpo
> rthandler/rss.xml}
> [Fatal Error] :18:63: The reference to entity "c" must end with the ';'
> delimite
> r.
> Dec 28, 2010 2:39:46 PM org.apache.solr.handler.dataimport.DataImportHandler
> inf
> orm
> SEVERE: Exception while loading DataImporter
> org.apache.solr.handler.dataimport.DataImportHandlerException: Exception
> occurre
> d while initializing context
> at
> org.apache.solr.handler.dataimport.DataImporter.loadDataConfig(DataIm
> porter.java:193)
> at
> org.apache.solr.handler.dataimport.DataImporter.(DataImporter.j
> ava:100)
> at
> org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImpor
> tHandler.java:112)
> at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.jav
> a:539)
> at org.apache.solr.core.SolrCore.(SolrCore.java:596)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:660)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:412)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:294)
> at
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContain
> er.java:243)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Reopened: (SOLR-2301) RSS Feed URL Breaking
[
https://issues.apache.org/jira/browse/SOLR-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Estrada reopened SOLR-2301:
Hoss,
You are correct! When I replaced "&" with "&" everything worked correctly.
I hope that others find this issue useful!
v/r,
Adam
> RSS Feed URL Breaking
> -
>
> Key: SOLR-2301
> URL: https://issues.apache.org/jira/browse/SOLR-2301
> Project: Solr
> Issue Type: Bug
> Components: clients - C#
>Affects Versions: 1.4.1, 4.0
> Environment: Windows 7
>Reporter: Adam Estrada
>
> This is an odd oneI am trying to index RSS feeds and have come across
> several issues. Some are more pressing than others. Referring to SOLR-2286 ;-)
> Anyway, the CDC has a list of RSS feeds that the Solr dataimporter can't work
> with
> Home page:
> http://emergency.cdc.gov/rss/
> Page to Index:
> http://www2a.cdc.gov/podcasts/createrss.asp?t=r&c=19
> The console reports the following and as you can see it's because it does not
> like the param "c". Any ideas on how to fix this?
> INFO: Processing configuration from solrconfig.xml:
> {config=./solr/conf/dataimpo
> rthandler/rss.xml}
> [Fatal Error] :18:63: The reference to entity "c" must end with the ';'
> delimite
> r.
> Dec 28, 2010 2:39:46 PM org.apache.solr.handler.dataimport.DataImportHandler
> inf
> orm
> SEVERE: Exception while loading DataImporter
> org.apache.solr.handler.dataimport.DataImportHandlerException: Exception
> occurre
> d while initializing context
> at
> org.apache.solr.handler.dataimport.DataImporter.loadDataConfig(DataIm
> porter.java:193)
> at
> org.apache.solr.handler.dataimport.DataImporter.(DataImporter.j
> ava:100)
> at
> org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImpor
> tHandler.java:112)
> at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.jav
> a:539)
> at org.apache.solr.core.SolrCore.(SolrCore.java:596)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:660)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:412)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:294)
> at
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContain
> er.java:243)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (SOLR-2301) RSS Feed URL Breaking
[
https://issues.apache.org/jira/browse/SOLR-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976333#action_12976333
]
Adam Estrada edited comment on SOLR-2301 at 12/31/10 1:58 PM:
--
Hoss,
You are correct! When I replaced "&" with & amp; everything worked
correctly. I hope that others find this issue useful!
v/r,
Adam
was (Author: adamestrada):
Hoss,
You are correct! When I replaced "&" with "& amp;" everything worked correctly.
I hope that others find this issue useful!
v/r,
Adam
> RSS Feed URL Breaking
> -
>
> Key: SOLR-2301
> URL: https://issues.apache.org/jira/browse/SOLR-2301
> Project: Solr
> Issue Type: Bug
> Components: clients - C#
>Affects Versions: 1.4.1, 4.0
> Environment: Windows 7
>Reporter: Adam Estrada
>
> This is an odd oneI am trying to index RSS feeds and have come across
> several issues. Some are more pressing than others. Referring to SOLR-2286 ;-)
> Anyway, the CDC has a list of RSS feeds that the Solr dataimporter can't work
> with
> Home page:
> http://emergency.cdc.gov/rss/
> Page to Index:
> http://www2a.cdc.gov/podcasts/createrss.asp?t=r&c=19
> The console reports the following and as you can see it's because it does not
> like the param "c". Any ideas on how to fix this?
> INFO: Processing configuration from solrconfig.xml:
> {config=./solr/conf/dataimpo
> rthandler/rss.xml}
> [Fatal Error] :18:63: The reference to entity "c" must end with the ';'
> delimite
> r.
> Dec 28, 2010 2:39:46 PM org.apache.solr.handler.dataimport.DataImportHandler
> inf
> orm
> SEVERE: Exception while loading DataImporter
> org.apache.solr.handler.dataimport.DataImportHandlerException: Exception
> occurre
> d while initializing context
> at
> org.apache.solr.handler.dataimport.DataImporter.loadDataConfig(DataIm
> porter.java:193)
> at
> org.apache.solr.handler.dataimport.DataImporter.(DataImporter.j
> ava:100)
> at
> org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImpor
> tHandler.java:112)
> at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.jav
> a:539)
> at org.apache.solr.core.SolrCore.(SolrCore.java:596)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:660)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:412)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:294)
> at
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContain
> er.java:243)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (SOLR-2301) RSS Feed URL Breaking
[
https://issues.apache.org/jira/browse/SOLR-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976333#action_12976333
]
Adam Estrada edited comment on SOLR-2301 at 12/31/10 1:57 PM:
--
Hoss,
You are correct! When I replaced "&" with "& amp;" everything worked correctly.
I hope that others find this issue useful!
v/r,
Adam
was (Author: adamestrada):
Hoss,
You are correct! When I replaced "&" with "&" everything worked correctly.
I hope that others find this issue useful!
v/r,
Adam
> RSS Feed URL Breaking
> -
>
> Key: SOLR-2301
> URL: https://issues.apache.org/jira/browse/SOLR-2301
> Project: Solr
> Issue Type: Bug
> Components: clients - C#
>Affects Versions: 1.4.1, 4.0
> Environment: Windows 7
>Reporter: Adam Estrada
>
> This is an odd oneI am trying to index RSS feeds and have come across
> several issues. Some are more pressing than others. Referring to SOLR-2286 ;-)
> Anyway, the CDC has a list of RSS feeds that the Solr dataimporter can't work
> with
> Home page:
> http://emergency.cdc.gov/rss/
> Page to Index:
> http://www2a.cdc.gov/podcasts/createrss.asp?t=r&c=19
> The console reports the following and as you can see it's because it does not
> like the param "c". Any ideas on how to fix this?
> INFO: Processing configuration from solrconfig.xml:
> {config=./solr/conf/dataimpo
> rthandler/rss.xml}
> [Fatal Error] :18:63: The reference to entity "c" must end with the ';'
> delimite
> r.
> Dec 28, 2010 2:39:46 PM org.apache.solr.handler.dataimport.DataImportHandler
> inf
> orm
> SEVERE: Exception while loading DataImporter
> org.apache.solr.handler.dataimport.DataImportHandlerException: Exception
> occurre
> d while initializing context
> at
> org.apache.solr.handler.dataimport.DataImporter.loadDataConfig(DataIm
> porter.java:193)
> at
> org.apache.solr.handler.dataimport.DataImporter.(DataImporter.j
> ava:100)
> at
> org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImpor
> tHandler.java:112)
> at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.jav
> a:539)
> at org.apache.solr.core.SolrCore.(SolrCore.java:596)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:660)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:412)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:294)
> at
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContain
> er.java:243)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2304) MoreLikeThis: Apply field level boosts before query terms are selected
[ https://issues.apache.org/jira/browse/SOLR-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Mattozzi updated SOLR-2304: Attachment: SOLR-2304.patch Patch to lucene trunk to apply field level boosts before query terms are selected in MoreLikeThis. > MoreLikeThis: Apply field level boosts before query terms are selected > -- > > Key: SOLR-2304 > URL: https://issues.apache.org/jira/browse/SOLR-2304 > Project: Solr > Issue Type: Improvement > Components: MoreLikeThis >Affects Versions: 1.4.2 >Reporter: Mike Mattozzi >Priority: Minor > Fix For: 1.4.2 > > Attachments: SOLR-2304.patch > > > MoreLikeThis provides the ability to set field level boosts to weight the > importance of fields in selecting similar documents. Currently, in trunk, > these field level boosts are applied after the query terms have been selected > from the priority queue of interesting terms in MoreLIkeThis. This can give > unexpected results when used in combination with mlt.maxqt to limit the > number of query terms. For example, if you use fields fieldA and fieldB and > boost them "fieldA^0.5 fieldB^2.0" with a maxqt parameter of 20, if the terms > in fieldA have relatively higher tf-idf scores than fieldB, only 20 fieldA > terms will be selected as the basis for the MoreLikeThis query... even if > after boosting, there are terms in fieldB with a higher overall score. > I encountered this while using document descriptive text and document tags > (comedy, action, etc) as the basis for MoreLIkeThis. I wanted to boost the > tags higher, however the less common document text terms were always selected > as the query terms while the more common tag terms were eliminated by the > maxqt parameter before their scores were boosted. > I believe the code was originally written as it was so that the bulk of the > work could be done in the MoreLikeThisHandler without modifying the > MoreLikeThis class in the lucene project. Now that the projects are merged, I > think this modification makes sense. I will be attaching a simple patch to > trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (SOLR-2304) MoreLikeThis: Apply field level boosts before query terms are selected
MoreLikeThis: Apply field level boosts before query terms are selected -- Key: SOLR-2304 URL: https://issues.apache.org/jira/browse/SOLR-2304 Project: Solr Issue Type: Improvement Components: MoreLikeThis Affects Versions: 1.4.2 Reporter: Mike Mattozzi Priority: Minor Fix For: 1.4.2 MoreLikeThis provides the ability to set field level boosts to weight the importance of fields in selecting similar documents. Currently, in trunk, these field level boosts are applied after the query terms have been selected from the priority queue of interesting terms in MoreLIkeThis. This can give unexpected results when used in combination with mlt.maxqt to limit the number of query terms. For example, if you use fields fieldA and fieldB and boost them "fieldA^0.5 fieldB^2.0" with a maxqt parameter of 20, if the terms in fieldA have relatively higher tf-idf scores than fieldB, only 20 fieldA terms will be selected as the basis for the MoreLikeThis query... even if after boosting, there are terms in fieldB with a higher overall score. I encountered this while using document descriptive text and document tags (comedy, action, etc) as the basis for MoreLIkeThis. I wanted to boost the tags higher, however the less common document text terms were always selected as the query terms while the more common tag terms were eliminated by the maxqt parameter before their scores were boosted. I believe the code was originally written as it was so that the bulk of the work could be done in the MoreLikeThisHandler without modifying the MoreLikeThis class in the lucene project. Now that the projects are merged, I think this modification makes sense. I will be attaching a simple patch to trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2611) IntelliJ IDEA and Eclipse setup
[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976315#action_12976315
]
Robert Muir commented on LUCENE-2611:
-
I have the core tests working... the main reason it is taking so long, is that
I am fixing our ant build to be like lucene's
and copy test resources to the classpath.. this way it won't break once I am
finished.
I have the solr contrib tests working in another checkout but its hackish...
just trying to get that part reasonable too.
Hope to get this resolved today!
> IntelliJ IDEA and Eclipse setup
> ---
>
> Key: LUCENE-2611
> URL: https://issues.apache.org/jira/browse/LUCENE-2611
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Build
>Affects Versions: 3.1, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611_eclipse.patch, LUCENE-2611_mkdir.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test.patch, LUCENE-2611_test.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test_2.patch
>
>
> Setting up Lucene/Solr in IntelliJ IDEA or Eclipse can be time-consuming.
> The attached patches add a new top level directory {{dev-tools/}} with
> sub-dirs {{idea/}} and {{eclipse/}} containing basic setup files for trunk,
> as well as top-level ant targets named "idea" and "eclipse" that copy these
> files into the proper locations. This arrangement avoids the messiness
> attendant to in-place project configuration files directly checked into
> source control.
> The IDEA configuration includes modules for Lucene and Solr, each Lucene and
> Solr contrib, and each analysis module. A JUnit run configuration per module
> is included.
> The Eclipse configuration includes a source entry for each
> source/test/resource location and classpath setup: a library entry for each
> jar.
> For IDEA, once {{ant idea}} has been run, the only configuration that must be
> performed manually is configuring the project-level JDK. For Eclipse, once
> {{ant eclipse}} has been run, the user has to refresh the project
> (right-click on the project and choose Refresh).
> If these patches is committed, Subversion svn:ignore properties should be
> added/modified to ignore the destination IDEA and Eclipse configuration
> locations.
> Iam Jambour has written up on the Lucene wiki a detailed set of instructions
> for applying the 3.X branch patch for IDEA:
> http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2611) IntelliJ IDEA and Eclipse setup
[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976311#action_12976311
]
Steven Rowe commented on LUCENE-2611:
-
Hi Adeel,
bq. will there be new instructions in HowToContrib section for eclipse and idea
Yes, I've added a link from both Solr's and Lucene's HowToContribute to
[HowtoConfigureIntelliJ|http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ]
Robert Muir is working on getting all Lucene/Solr tests to run under Eclipse.
Once he's got them running, I believe he plans on committing the Eclipse patch
on this issue. The Eclipse instructions on the wiki should be cleaned up at
that point too.
bq. i am not able to run individual tests and i have tried all the possible
ways pointed out in solr wiki (e.g. ant -DtestCase )
That should be {{ant -Dtestcase }} - note that the "c" in "testcase" is
lowercase. Have you seen
[RunningTests|http://wiki.apache.org/lucene-java/RunningTests]?
bq. just thought ill make the voice of people, who want to contribute but just
cant get past the initial setting things up obstacle, heard.
Thanks for your feedback!
> IntelliJ IDEA and Eclipse setup
> ---
>
> Key: LUCENE-2611
> URL: https://issues.apache.org/jira/browse/LUCENE-2611
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Build
>Affects Versions: 3.1, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611_eclipse.patch, LUCENE-2611_mkdir.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test.patch, LUCENE-2611_test.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test_2.patch
>
>
> Setting up Lucene/Solr in IntelliJ IDEA or Eclipse can be time-consuming.
> The attached patches add a new top level directory {{dev-tools/}} with
> sub-dirs {{idea/}} and {{eclipse/}} containing basic setup files for trunk,
> as well as top-level ant targets named "idea" and "eclipse" that copy these
> files into the proper locations. This arrangement avoids the messiness
> attendant to in-place project configuration files directly checked into
> source control.
> The IDEA configuration includes modules for Lucene and Solr, each Lucene and
> Solr contrib, and each analysis module. A JUnit run configuration per module
> is included.
> The Eclipse configuration includes a source entry for each
> source/test/resource location and classpath setup: a library entry for each
> jar.
> For IDEA, once {{ant idea}} has been run, the only configuration that must be
> performed manually is configuring the project-level JDK. For Eclipse, once
> {{ant eclipse}} has been run, the user has to refresh the project
> (right-click on the project and choose Refresh).
> If these patches is committed, Subversion svn:ignore properties should be
> added/modified to ignore the destination IDEA and Eclipse configuration
> locations.
> Iam Jambour has written up on the Lucene wiki a detailed set of instructions
> for applying the 3.X branch patch for IDEA:
> http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2611) IntelliJ IDEA and Eclipse setup
[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976299#action_12976299
]
Adeel Qureshi commented on LUCENE-2611:
---
i recently tried setting up solr dev environment in my eclipse and i am really
glad to see Robert Muir's comments regarding how difficult it is to get it all
setup and working in these ide's because it took me about 3-4 redo everything
attempts and about a week to get it all setup simply to be able to run ant test
and even then some tests still failed (very few). i also had all kinds of
problems in running specific tests instead of every single test. so anyways
with all these new updates you guys have made .. did all that made anything
easier. will there be new instructions in HowToContrib section for eclipse and
idea .. also another thing to mention .. i setup mine on eclipse 3.5 but from
HowToContrib i had to do steps mentioned for eclipse 3.6 as well .. also as i
mentioned before i am not able to run individual tests and i have tried all the
possible ways pointed out in solr wiki (e.g. ant -DtestCase ) ..
just thought ill make the voice of people, who want to contribute but just cant
get past the initial setting things up obstacle, heard.
Thanks
Adeel
> IntelliJ IDEA and Eclipse setup
> ---
>
> Key: LUCENE-2611
> URL: https://issues.apache.org/jira/browse/LUCENE-2611
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Build
>Affects Versions: 3.1, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611_eclipse.patch, LUCENE-2611_mkdir.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test.patch, LUCENE-2611_test.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test_2.patch
>
>
> Setting up Lucene/Solr in IntelliJ IDEA or Eclipse can be time-consuming.
> The attached patches add a new top level directory {{dev-tools/}} with
> sub-dirs {{idea/}} and {{eclipse/}} containing basic setup files for trunk,
> as well as top-level ant targets named "idea" and "eclipse" that copy these
> files into the proper locations. This arrangement avoids the messiness
> attendant to in-place project configuration files directly checked into
> source control.
> The IDEA configuration includes modules for Lucene and Solr, each Lucene and
> Solr contrib, and each analysis module. A JUnit run configuration per module
> is included.
> The Eclipse configuration includes a source entry for each
> source/test/resource location and classpath setup: a library entry for each
> jar.
> For IDEA, once {{ant idea}} has been run, the only configuration that must be
> performed manually is configuring the project-level JDK. For Eclipse, once
> {{ant eclipse}} has been run, the user has to refresh the project
> (right-click on the project and choose Refresh).
> If these patches is committed, Subversion svn:ignore properties should be
> added/modified to ignore the destination IDEA and Eclipse configuration
> locations.
> Iam Jambour has written up on the Lucene wiki a detailed set of instructions
> for applying the 3.X branch patch for IDEA:
> http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] Commented: (LUCENE-2611) IntelliJ IDEA and Eclipse setup
i recently tried setting up solr dev environment in my eclipse and i am
really glad to see Robert Muir's comments regarding how difficult it is to
get it all setup and working in these ide's because it took me about 3-4
redo everything attempts and about a week to get it all setup simply to be
able to run ant test and even then some tests still failed (very few). i
also had all kinds of problems in running specific tests instead of every
single test. so anyways with all these new updates you guys have made .. did
all that made anything easier. will there be new instructions in
HowToContrib section for eclipse and idea .. also another thing to mention
.. i setup mine on eclipse 3.5 but from HowToContrib i had to do steps
mentioned for eclipse 3.6 as well .. also as i mentioned before i am not
able to run individual tests and i have tried all the possible ways pointed
out in solr wiki (e.g. ant -DtestCase ) ..
just thought ill make the voice of people, who want to contribute but just
cant get past the initial setting things up obstacle, heard.
Thanks
Adeel
On Fri, Dec 31, 2010 at 9:58 AM, JIRA j...@apache.org [via Lucene] <
ml-node+2172952-1460728692-19...@n3.nabble.com
> wrote:
>
> [
> https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976284#action_12976284
> ]
>
>
> Steven Rowe commented on LUCENE-2611:
> -
>
> Hi Erick,
>
> {quote}
> I just tried this on my Windows box and it works perfectly, even to running
> tests. The only thing I had to do was open the project from IntelliJ and set
> the compiler, just as expected. Well, and wait for IntelliJ to finish
> indexing things ...
>
> Sweet!
>
> I really think this will make it MUCH easier for people to contribute, I
> always dread setting up any IDE for a new project since it usually takes
> seemingly forever. Nice work!
> {quote}
>
> Thanks. The key, of course, is keeping it in synch with the project
> structure. I plan on writing up maintenance instructions the next time this
> is required, so that others can more easily contribute to the effort.
>
> bq. I'll try it on my Mac just for yucks...
>
> Cool, let me know if you notice anything amiss.
>
>
> > IntelliJ IDEA and Eclipse setup
> > ---
> >
> > Key: LUCENE-2611
> > URL: https://issues.apache.org/jira/browse/LUCENE-2611
> > Project: Lucene - Java
> > Issue Type: New Feature
> > Components: Build
> >Affects Versions: 3.1, 4.0
> >Reporter: Steven Rowe
> >Priority: Minor
> > Fix For: 3.1, 4.0
> >
> > Attachments: LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611_eclipse.patch, LUCENE-2611_mkdir.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test.patch, LUCENE-2611_test.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test_2.patch
> >
> >
> > Setting up Lucene/Solr in IntelliJ IDEA or Eclipse can be time-consuming.
>
> > The attached patches add a new top level directory {{dev-tools/}} with
> sub-dirs {{idea/}} and {{eclipse/}} containing basic setup files for trunk,
> as well as top-level ant targets named "idea" and "eclipse" that copy these
> files into the proper locations. This arrangement avoids the messiness
> attendant to in-place project configuration files directly checked into
> source control.
> > The IDEA configuration includes modules for Lucene and Solr, each Lucene
> and Solr contrib, and each analysis module. A JUnit run configuration per
> module is included.
> > The Eclipse configuration includes a source entry for each
> source/test/resource location and classpath setup: a library entry for each
> jar.
> > For IDEA, once {{ant idea}} has been run, the only configuration that
> must be performed manually is configuring the project-level JDK. For
> Eclipse, once {{ant eclipse}} has been run, the user has to refresh the
> project (right-click on the project and choose Refresh).
> > If these patches is committed, Subversion svn:ignore properties should be
> added/modified to ignore the destination IDEA and Eclipse configuration
> locations.
> > Iam Jambour has written up on the Lucene wiki a detailed set of
> instructions for applying the 3.X branch patch for IDEA:
> http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> -
> To unsubscribe, e-mail: [hidden
> email]
> For additional commands, e-mail
[jira] Commented: (LUCENE-2611) IntelliJ IDEA and Eclipse setup
[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976284#action_12976284
]
Steven Rowe commented on LUCENE-2611:
-
Hi Erick,
{quote}
I just tried this on my Windows box and it works perfectly, even to running
tests. The only thing I had to do was open the project from IntelliJ and set
the compiler, just as expected. Well, and wait for IntelliJ to finish indexing
things ...
Sweet!
I really think this will make it MUCH easier for people to contribute, I always
dread setting up any IDE for a new project since it usually takes seemingly
forever. Nice work!
{quote}
Thanks. The key, of course, is keeping it in synch with the project structure.
I plan on writing up maintenance instructions the next time this is required,
so that others can more easily contribute to the effort.
bq. I'll try it on my Mac just for yucks...
Cool, let me know if you notice anything amiss.
> IntelliJ IDEA and Eclipse setup
> ---
>
> Key: LUCENE-2611
> URL: https://issues.apache.org/jira/browse/LUCENE-2611
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Build
>Affects Versions: 3.1, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611_eclipse.patch, LUCENE-2611_mkdir.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test.patch, LUCENE-2611_test.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test_2.patch
>
>
> Setting up Lucene/Solr in IntelliJ IDEA or Eclipse can be time-consuming.
> The attached patches add a new top level directory {{dev-tools/}} with
> sub-dirs {{idea/}} and {{eclipse/}} containing basic setup files for trunk,
> as well as top-level ant targets named "idea" and "eclipse" that copy these
> files into the proper locations. This arrangement avoids the messiness
> attendant to in-place project configuration files directly checked into
> source control.
> The IDEA configuration includes modules for Lucene and Solr, each Lucene and
> Solr contrib, and each analysis module. A JUnit run configuration per module
> is included.
> The Eclipse configuration includes a source entry for each
> source/test/resource location and classpath setup: a library entry for each
> jar.
> For IDEA, once {{ant idea}} has been run, the only configuration that must be
> performed manually is configuring the project-level JDK. For Eclipse, once
> {{ant eclipse}} has been run, the user has to refresh the project
> (right-click on the project and choose Refresh).
> If these patches is committed, Subversion svn:ignore properties should be
> added/modified to ignore the destination IDEA and Eclipse configuration
> locations.
> Iam Jambour has written up on the Lucene wiki a detailed set of instructions
> for applying the 3.X branch patch for IDEA:
> http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2611) IntelliJ IDEA and Eclipse setup
[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976265#action_12976265
]
Erick Erickson commented on LUCENE-2611:
Steven:
I just tried this on my Windows box and it works perfectly, even to running
tests. The only thing I had to do was open the project from IntelliJ and set
the compiler, just as expected. Well, and wait for IntelliJ to finish indexing
things ...
Sweet!
I really think this will make it MUCH easier for people to contribute, I always
dread setting up any IDE for a new project since it usually takes seemingly
forever. Nice work! I'll try it on my Mac just for yucks...
Erick
> IntelliJ IDEA and Eclipse setup
> ---
>
> Key: LUCENE-2611
> URL: https://issues.apache.org/jira/browse/LUCENE-2611
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Build
>Affects Versions: 3.1, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch,
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch,
> LUCENE-2611_eclipse.patch, LUCENE-2611_mkdir.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test.patch, LUCENE-2611_test.patch, LUCENE-2611_test.patch,
> LUCENE-2611_test_2.patch
>
>
> Setting up Lucene/Solr in IntelliJ IDEA or Eclipse can be time-consuming.
> The attached patches add a new top level directory {{dev-tools/}} with
> sub-dirs {{idea/}} and {{eclipse/}} containing basic setup files for trunk,
> as well as top-level ant targets named "idea" and "eclipse" that copy these
> files into the proper locations. This arrangement avoids the messiness
> attendant to in-place project configuration files directly checked into
> source control.
> The IDEA configuration includes modules for Lucene and Solr, each Lucene and
> Solr contrib, and each analysis module. A JUnit run configuration per module
> is included.
> The Eclipse configuration includes a source entry for each
> source/test/resource location and classpath setup: a library entry for each
> jar.
> For IDEA, once {{ant idea}} has been run, the only configuration that must be
> performed manually is configuring the project-level JDK. For Eclipse, once
> {{ant eclipse}} has been run, the user has to refresh the project
> (right-click on the project and choose Refresh).
> If these patches is committed, Subversion svn:ignore properties should be
> added/modified to ignore the destination IDEA and Eclipse configuration
> locations.
> Iam Jambour has written up on the Lucene wiki a detailed set of instructions
> for applying the 3.X branch patch for IDEA:
> http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Solr-trunk - Build # 1359 - Failure
Build: https://hudson.apache.org/hudson/job/Solr-trunk/1359/ All tests passed Build Log (for compile errors): [...truncated 16169 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
