[jira] Created: (LUCENE-816) Manage dependencies in the build with ivy
Manage dependencies in the build with ivy - Key: LUCENE-816 URL: https://issues.apache.org/jira/browse/LUCENE-816 Project: Lucene - Java Issue Type: New Feature Components: Analysis Affects Versions: 2.1 Reporter: Nicolas Lalevée Attachments: common-build.tar.gz There were issues about making the 2.1 release : http://www.nabble.com/-VOTE--release-Lucene-2.1-tf3228536.html#a8994721 Then the discussion started to talk about maven, and also about ivy. I propose here a draft, a proof of concept of an ant + ivy build. I made this build parallel to the actual one, so people can evaluate it. Note that I have only ivy-ified the core, the demo and the contrib/benchmark. The other contrib projects can be ivy-ified quite easily. The build system is in the common-build directory. In this directory we have : * common-build.xml : the main common build which handle dependencies with ivy * common-build-project.xml : build a java project, core, demo, or a contrib one * common-build-webapp.xml : extend common-build-project and have some tasks about building a war * common-build-modules.xml : allow to build sevral projects, just using some subant task * common-build-gcj.xml : build with gcj. It work once, need to be fixed * ivyconf.xml, ivyconf.properties : ivy configuration * build.xml : a little task to generate the ivyconf.xml to use with the eclipse ivy plugin * eclipse directory : contains some XSL/XML to generate .classpath and .project To test it and see how ivy is cool : cd contrib/benchmark ant -f build-ivy.xml buildeep and look at the new local-libs directory at the root of the lucene directory ! -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-816) Manage dependencies in the build with ivy
[ https://issues.apache.org/jira/browse/LUCENE-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Lalevée updated LUCENE-816: --- Attachment: common-build.tar.gz > Manage dependencies in the build with ivy > - > > Key: LUCENE-816 > URL: https://issues.apache.org/jira/browse/LUCENE-816 > Project: Lucene - Java > Issue Type: New Feature > Components: Analysis >Affects Versions: 2.1 >Reporter: Nicolas Lalevée > Attachments: common-build.tar.gz > > > There were issues about making the 2.1 release : > http://www.nabble.com/-VOTE--release-Lucene-2.1-tf3228536.html#a8994721 > Then the discussion started to talk about maven, and also about ivy. > I propose here a draft, a proof of concept of an ant + ivy build. I made this > build parallel to the actual one, so people can evaluate it. > Note that I have only ivy-ified the core, the demo and the contrib/benchmark. > The other contrib projects can be ivy-ified quite easily. > The build system is in the common-build directory. In this directory we have : > * common-build.xml : the main common build which handle dependencies with ivy > * common-build-project.xml : build a java project, core, demo, or a contrib > one > * common-build-webapp.xml : extend common-build-project and have some tasks > about building a war > * common-build-modules.xml : allow to build sevral projects, just using some > subant task > * common-build-gcj.xml : build with gcj. It work once, need to be fixed > * ivyconf.xml, ivyconf.properties : ivy configuration > * build.xml : a little task to generate the ivyconf.xml to use with the > eclipse ivy plugin > * eclipse directory : contains some XSL/XML to generate .classpath and > .project > To test it and see how ivy is cool : > cd contrib/benchmark > ant -f build-ivy.xml buildeep > and look at the new local-libs directory at the root of the lucene directory ! -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-816) Manage dependencies in the build with ivy
[ https://issues.apache.org/jira/browse/LUCENE-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Lalevée updated LUCENE-816: --- Attachment: ivy-build.patch > Manage dependencies in the build with ivy > - > > Key: LUCENE-816 > URL: https://issues.apache.org/jira/browse/LUCENE-816 > Project: Lucene - Java > Issue Type: New Feature > Components: Analysis >Affects Versions: 2.1 >Reporter: Nicolas Lalevée > Attachments: common-build.tar.gz, ivy-build.patch > > > There were issues about making the 2.1 release : > http://www.nabble.com/-VOTE--release-Lucene-2.1-tf3228536.html#a8994721 > Then the discussion started to talk about maven, and also about ivy. > I propose here a draft, a proof of concept of an ant + ivy build. I made this > build parallel to the actual one, so people can evaluate it. > Note that I have only ivy-ified the core, the demo and the contrib/benchmark. > The other contrib projects can be ivy-ified quite easily. > The build system is in the common-build directory. In this directory we have : > * common-build.xml : the main common build which handle dependencies with ivy > * common-build-project.xml : build a java project, core, demo, or a contrib > one > * common-build-webapp.xml : extend common-build-project and have some tasks > about building a war > * common-build-modules.xml : allow to build sevral projects, just using some > subant task > * common-build-gcj.xml : build with gcj. It work once, need to be fixed > * ivyconf.xml, ivyconf.properties : ivy configuration > * build.xml : a little task to generate the ivyconf.xml to use with the > eclipse ivy plugin > * eclipse directory : contains some XSL/XML to generate .classpath and > .project > To test it and see how ivy is cool : > cd contrib/benchmark > ant -f build-ivy.xml buildeep > and look at the new local-libs directory at the root of the lucene directory ! -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-817) Manage dependencies in the build with ivy
Manage dependencies in the build with ivy - Key: LUCENE-817 URL: https://issues.apache.org/jira/browse/LUCENE-817 Project: Lucene - Java Issue Type: New Feature Components: Build Affects Versions: 2.1 Reporter: Nicolas Lalevée There were issues about making the 2.1 release : http://www.nabble.com/-VOTE--release-Lucene-2.1-tf3228536.html#a8994721 Then the discussion started to talk about maven, and also about ivy. I propose here a draft, a proof of concept of an ant + ivy build. I made this build parallel to the actual one, so people can evaluate it. Note that I have only ivy-ified the core, the demo and the contrib/benchmark. The other contrib projects can be ivy-ified quite easily. The build system is in the common-build directory. In this directory we have : * common-build.xml : the main common build which handle dependencies with ivy * common-build-project.xml : build a java project, core, demo, or a contrib one * common-build-webapp.xml : extend common-build-project and have some tasks about building a war * common-build-modules.xml : allow to build sevral projects, just using some subant task * common-build-gcj.xml : build with gcj. It work once, need to be fixed * ivyconf.xml, ivyconf.properties : ivy configuration * build.xml : a little task to generate the ivyconf.xml to use with the eclipse ivy plugin * eclipse directory : contains some XSL/XML to generate .classpath and .project To test it and see how ivy is cool :) : cd contrib/benchmark ant -f build-ivy.xml buildeep and look at the new local-libs directory at the root of the lucene directory ! -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-817) Manage dependencies in the build with ivy
[ https://issues.apache.org/jira/browse/LUCENE-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Lalevée resolved LUCENE-817. Resolution: Duplicate Lucene Fields: [New, Patch Available] (was: [Patch Available, New]) jira not responding, retrying, and then a duplicate issue... > Manage dependencies in the build with ivy > - > > Key: LUCENE-817 > URL: https://issues.apache.org/jira/browse/LUCENE-817 > Project: Lucene - Java > Issue Type: New Feature > Components: Build >Affects Versions: 2.1 >Reporter: Nicolas Lalevée > > There were issues about making the 2.1 release : > http://www.nabble.com/-VOTE--release-Lucene-2.1-tf3228536.html#a8994721 > Then the discussion started to talk about maven, and also about ivy. > I propose here a draft, a proof of concept of an ant + ivy build. I made this > build parallel to the actual one, so people can evaluate it. > Note that I have only ivy-ified the core, the demo and the contrib/benchmark. > The other contrib projects can be ivy-ified quite easily. > The build system is in the common-build directory. In this directory we have : > * common-build.xml : the main common build which handle dependencies with ivy > * common-build-project.xml : build a java project, core, demo, or a contrib > one > * common-build-webapp.xml : extend common-build-project and have some tasks > about building a war > * common-build-modules.xml : allow to build sevral projects, just using some > subant task > * common-build-gcj.xml : build with gcj. It work once, need to be fixed > * ivyconf.xml, ivyconf.properties : ivy configuration > * build.xml : a little task to generate the ivyconf.xml to use with the > eclipse ivy plugin > * eclipse directory : contains some XSL/XML to generate .classpath and > .project > To test it and see how ivy is cool :) : > cd contrib/benchmark > ant -f build-ivy.xml buildeep > and look at the new local-libs directory at the root of the lucene directory ! -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-816) Manage dependencies in the build with ivy
[ https://issues.apache.org/jira/browse/LUCENE-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Lalevée updated LUCENE-816: --- Attachment: external-libs.tar.gz > Manage dependencies in the build with ivy > - > > Key: LUCENE-816 > URL: https://issues.apache.org/jira/browse/LUCENE-816 > Project: Lucene - Java > Issue Type: New Feature > Components: Analysis >Affects Versions: 2.1 >Reporter: Nicolas Lalevée > Attachments: common-build.tar.gz, external-libs.tar.gz, > ivy-build.patch > > > There were issues about making the 2.1 release : > http://www.nabble.com/-VOTE--release-Lucene-2.1-tf3228536.html#a8994721 > Then the discussion started to talk about maven, and also about ivy. > I propose here a draft, a proof of concept of an ant + ivy build. I made this > build parallel to the actual one, so people can evaluate it. > Note that I have only ivy-ified the core, the demo and the contrib/benchmark. > The other contrib projects can be ivy-ified quite easily. > The build system is in the common-build directory. In this directory we have : > * common-build.xml : the main common build which handle dependencies with ivy > * common-build-project.xml : build a java project, core, demo, or a contrib > one > * common-build-webapp.xml : extend common-build-project and have some tasks > about building a war > * common-build-modules.xml : allow to build sevral projects, just using some > subant task > * common-build-gcj.xml : build with gcj. It work once, need to be fixed > * ivyconf.xml, ivyconf.properties : ivy configuration > * build.xml : a little task to generate the ivyconf.xml to use with the > eclipse ivy plugin > * eclipse directory : contains some XSL/XML to generate .classpath and > .project > To test it and see how ivy is cool : > cd contrib/benchmark > ant -f build-ivy.xml buildeep > and look at the new local-libs directory at the root of the lucene directory ! -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-815) contrib/benchmark libraries are not packaged in 2.1.0 release
[ https://issues.apache.org/jira/browse/LUCENE-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475930 ] Doron Cohen commented on LUCENE-815: I believe this was fixed by LUCENE-804, but only for source dist, not for binary dist. Do you think it should be also included in the binary dist? Since common-build.xml and contrib's build.xml files are not included, not sure these jars would be useful with the binary dist. (?) Doron > contrib/benchmark libraries are not packaged in 2.1.0 release > - > > Key: LUCENE-815 > URL: https://issues.apache.org/jira/browse/LUCENE-815 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Grant Ingersoll >Priority: Minor > > The lib directory for contrib/benchmark is not included in the 2.1.0 release. > All libraries used are Apache libraries so I think they should be fine for > inclusion. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-812) Unable to set LockFactory implementation via ${org.apache.lucene.store.FSDirectoryLockFactoryClass}
[
https://issues.apache.org/jira/browse/LUCENE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475937
]
Michael McCandless commented on LUCENE-812:
---
One of the original motivations of this property was the ability to
also choose LockFactory implementations external to Lucene (the
original issue had a lock factory that used MySQL for locking). So
the property is still useful for that use-case.
Unfortunately we can't deprecate this (there is no compiler/runtime
support for deprecating a random property?). I guess we could remove
support for it (in 2.2 or 2.1.1?) and throw an exception if we see
that the property is set (to catch users who had started using it) but
that seems rather harsh.
So ... I think we should in fact support it (but in the future we
should not add any more new System properties to Lucene, I think).
I plan to modify Simple/NativeFSLockFactory to have no arg constructor
that sets their lockDir to null, and then add logic to
FSDirectory.getDirectory to set its own dir as the lockDirName if it
sees that the incoming LockFactory is one of these two instances with
a null lockDir.
The other 2 builtin LockFactory implementations already have no-arg
constructors so they work fine through this property.
> Unable to set LockFactory implementation via
> ${org.apache.lucene.store.FSDirectoryLockFactoryClass}
> ---
>
> Key: LUCENE-812
> URL: https://issues.apache.org/jira/browse/LUCENE-812
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.1
>Reporter: Matthias Kerkhoff
> Assigned To: Michael McCandless
>
> While trying to move from Lucene 2.0 to Lucene 2.1 I noticed a problem with
> the LockFactory instantiation code.
> During previous tests we successfully specified the LockFactory
> implementation by setting the property
> ${org.apache.lucene.store.FSDirectoryLockFactoryClass} to
> "org.apache.lucene.store.NativeFSLockFactory".
> This does no longer work due to a bug in the FSDirectory class. The problem
> is caused from the fact that this
> class tries to invoke the default constructor of the specified LockFactory
> class. However neither NativeFSLockFactory
> nor SimpleFSLockFactory do have a default constructor.
> FSDirectory, Line 285:
> try {
> lockFactory = (LockFactory) c.newInstance();
> } catch (IllegalAccessException e) {
> throw new IOException("IllegalAccessException when instantiating
> LockClass " + lockClassName);
> } catch (InstantiationException e) {
> throw new IOException("InstantiationException when instantiating
> LockClass " + lockClassName);
> } catch (ClassCastException e) {
> throw new IOException("unable to cast LockClass " + lockClassName
> + " instance to a LockFactory");
> }
> A possible workaround is to not set the property at all and call
> FSDirectory.setLockFactory(...) instead.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
commiting changes to index
Hi, I have a Lucene index and I modified some docs in my index using Luke (deleting and editing both). I can close the index and reopen and I see the change but the current changes are not in effect. When I try to optimize the index, it rolls-back to the orignal index. How can I commit changes to my index and make index with new changes searchable? Thanks for your help.
[jira] Closed: (LUCENE-815) contrib/benchmark libraries are not packaged in 2.1.0 release
[ https://issues.apache.org/jira/browse/LUCENE-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll closed LUCENE-815. -- Resolution: Duplicate > contrib/benchmark libraries are not packaged in 2.1.0 release > - > > Key: LUCENE-815 > URL: https://issues.apache.org/jira/browse/LUCENE-815 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Grant Ingersoll >Priority: Minor > > The lib directory for contrib/benchmark is not included in the 2.1.0 release. > All libraries used are Apache libraries so I think they should be fine for > inclusion. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commiting changes to index
Hi, Questions on using Lucene belong to the java-user list - better chances to get a rapid reply there. To your question, first try Lucene FAQ - especially "Why am I getting no hits / incorrect hits?" Regards, Doron "eddie fahy" <[EMAIL PROTECTED]> wrote on 26/02/2007 10:36:12: > Hi, > I have a Lucene index and I modified some docs in my index using Luke > (deleting and editing both). I can close the index and reopen and I see the > change but the current changes are not in effect. When I try to optimize the > index, it rolls-back to the orignal index. How can I commit changes to my > index and make index with new changes searchable? > > Thanks for your help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-813) leading wildcard's don't work with trailing wildcard
[ https://issues.apache.org/jira/browse/LUCENE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475963 ] Doron Cohen commented on LUCENE-813: Now working for Antony - http://www.nabble.com/forum/ViewPost.jtp?post=9094319&framed=y I will commit this if there are no other comments. Doron > leading wildcard's don't work with trailing wildcard > > > Key: LUCENE-813 > URL: https://issues.apache.org/jira/browse/LUCENE-813 > Project: Lucene - Java > Issue Type: Bug >Reporter: Hoss Man > Assigned To: Doron Cohen > Attachments: 813.fix.lead.wildcard.patch, qp-leading-wildcard.patch > > > As reported by Antony Bowesman, leading wildcards don't work when there is a > trailing wildcard character -- instead a PrefixQuery is constructed. > http://www.nabble.com/QueryParser-bug--tf3270956.html -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-818) IndexWriter should detect when it's used after being closed
IndexWriter should detect when it's used after being closed --- Key: LUCENE-818 URL: https://issues.apache.org/jira/browse/LUCENE-818 Project: Lucene - Java Issue Type: Bug Components: Index Affects Versions: 2.1 Reporter: Michael McCandless Assigned To: Michael McCandless Priority: Minor Spinoff from this thread on java-user: http://www.gossamer-threads.com/lists/lucene/java-user/45986 If you call addDocument on IndexWriter after it's closed you'll hit a hard-to-explain NullPointerException (because the RAMDirectory was closed). Before 2.1, apparently you won't hit any exception and the IndexWrite will keep running but will have released it's write lock (I think). I plan to fix IndexWriter methods to throw an IllegalStateException if it has been closed. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-812) Unable to set LockFactory implementation via ${org.apache.lucene.store.FSDirectoryLockFactoryClass}
[
https://issues.apache.org/jira/browse/LUCENE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-812:
--
Attachment: LUCENE-812.patch
Attached proposed patch.
OK I made the no-argument constructors package-private since you would
not normally do this. I also added package-private "setLockDir()".
FSDirectory uses setLockDir to set itself when it instantiates a
Simple/NativeFSLockFactory using that System property. I also
extended TestLockFactory test case to test that all 4 builtin
LockFactory implementations can be set.
> Unable to set LockFactory implementation via
> ${org.apache.lucene.store.FSDirectoryLockFactoryClass}
> ---
>
> Key: LUCENE-812
> URL: https://issues.apache.org/jira/browse/LUCENE-812
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.1
>Reporter: Matthias Kerkhoff
> Assigned To: Michael McCandless
> Attachments: LUCENE-812.patch
>
>
> While trying to move from Lucene 2.0 to Lucene 2.1 I noticed a problem with
> the LockFactory instantiation code.
> During previous tests we successfully specified the LockFactory
> implementation by setting the property
> ${org.apache.lucene.store.FSDirectoryLockFactoryClass} to
> "org.apache.lucene.store.NativeFSLockFactory".
> This does no longer work due to a bug in the FSDirectory class. The problem
> is caused from the fact that this
> class tries to invoke the default constructor of the specified LockFactory
> class. However neither NativeFSLockFactory
> nor SimpleFSLockFactory do have a default constructor.
> FSDirectory, Line 285:
> try {
> lockFactory = (LockFactory) c.newInstance();
> } catch (IllegalAccessException e) {
> throw new IOException("IllegalAccessException when instantiating
> LockClass " + lockClassName);
> } catch (InstantiationException e) {
> throw new IOException("InstantiationException when instantiating
> LockClass " + lockClassName);
> } catch (ClassCastException e) {
> throw new IOException("unable to cast LockClass " + lockClassName
> + " instance to a LockFactory");
> }
> A possible workaround is to not set the property at all and call
> FSDirectory.setLockFactory(...) instead.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-584) Decouple Filter from BitSet
[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Elschot updated LUCENE-584:
Attachment: Matcher20070226.patch
As 2.1 is out, here is a new patch to try and revive this.
This replaces the pevious Matchermmdd.patch one of 2006
> Decouple Filter from BitSet
> ---
>
> Key: LUCENE-584
> URL: https://issues.apache.org/jira/browse/LUCENE-584
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
>Affects Versions: 2.0.1
>Reporter: Peter Schäfer
>Priority: Minor
> Attachments: BitsMatcher.java, Filter-20060628.patch,
> HitCollector-20060628.patch, IndexSearcher-20060628.patch,
> MatchCollector.java, Matcher.java, Matcher20060830b.patch,
> Matcher20070226.patch, Scorer-20060628.patch, Searchable-20060628.patch,
> Searcher-20060628.patch, Some Matchers.zip, SortedVIntList.java,
> TestSortedVIntList.java
>
>
> {code}
> package org.apache.lucene.search;
> public abstract class Filter implements java.io.Serializable
> {
> public abstract AbstractBitSet bits(IndexReader reader) throws IOException;
> }
> public interface AbstractBitSet
> {
> public boolean get(int index);
> }
> {code}
> It would be useful if the method =Filter.bits()= returned an abstract
> interface, instead of =java.util.BitSet=.
> Use case: there is a very large index, and, depending on the user's
> privileges, only a small portion of the index is actually visible.
> Sparsely populated =java.util.BitSet=s are not efficient and waste lots of
> memory. It would be desirable to have an alternative BitSet implementation
> with smaller memory footprint.
> Though it _is_ possibly to derive classes from =java.util.BitSet=, it was
> obviously not designed for that purpose.
> That's why I propose to use an interface instead. The default implementation
> could still delegate to =java.util.BitSet=.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-584) Decouple Filter from BitSet
[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Elschot updated LUCENE-584:
Attachment: (was: Matcher20060830b.patch)
> Decouple Filter from BitSet
> ---
>
> Key: LUCENE-584
> URL: https://issues.apache.org/jira/browse/LUCENE-584
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
>Affects Versions: 2.0.1
>Reporter: Peter Schäfer
>Priority: Minor
> Attachments: BitsMatcher.java, Filter-20060628.patch,
> HitCollector-20060628.patch, IndexSearcher-20060628.patch,
> MatchCollector.java, Matcher.java, Matcher20070226.patch,
> Scorer-20060628.patch, Searchable-20060628.patch, Searcher-20060628.patch,
> Some Matchers.zip, SortedVIntList.java, TestSortedVIntList.java
>
>
> {code}
> package org.apache.lucene.search;
> public abstract class Filter implements java.io.Serializable
> {
> public abstract AbstractBitSet bits(IndexReader reader) throws IOException;
> }
> public interface AbstractBitSet
> {
> public boolean get(int index);
> }
> {code}
> It would be useful if the method =Filter.bits()= returned an abstract
> interface, instead of =java.util.BitSet=.
> Use case: there is a very large index, and, depending on the user's
> privileges, only a small portion of the index is actually visible.
> Sparsely populated =java.util.BitSet=s are not efficient and waste lots of
> memory. It would be desirable to have an alternative BitSet implementation
> with smaller memory footprint.
> Though it _is_ possibly to derive classes from =java.util.BitSet=, it was
> obviously not designed for that purpose.
> That's why I propose to use an interface instead. The default implementation
> could still delegate to =java.util.BitSet=.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-818) IndexWriter should detect when it's used after being closed
[
https://issues.apache.org/jira/browse/LUCENE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475987
]
Doron Cohen commented on LUCENE-818:
I looked at Java IO as a reference for acceptable behavior in this regard.
If you close a file system object and try to use it,
- RandomAccessFile will throw IOException with: "No such file or directory"
- FileWriter will throw IOException with "Stream closed"
- FileOutputStream will throw IOException with "Stream closed"
So you could say that Java did not go all the way with a well defined
illegalState exception.
Databases on the other hand would give you a well definied error code.
I don't have a strong opinion if this is a must for Lucene or not.
But if this is to be added, one way to do it is to define a Closable interface
{ close(); isOpen() }, implement this interface in all public classes that need
to check open state (IndexWriter, IndexReader, etc.), add a single static
ensureOpen(Closable) method in a utils class that would throw the IllegalState
exception, and just call this method from every (public?) open-state open
dependent method. I think this would keep the 'noise' in the code to minimum.
> IndexWriter should detect when it's used after being closed
> ---
>
> Key: LUCENE-818
> URL: https://issues.apache.org/jira/browse/LUCENE-818
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
>Affects Versions: 2.1
>Reporter: Michael McCandless
> Assigned To: Michael McCandless
>Priority: Minor
>
> Spinoff from this thread on java-user:
> http://www.gossamer-threads.com/lists/lucene/java-user/45986
> If you call addDocument on IndexWriter after it's closed you'll hit a
> hard-to-explain NullPointerException (because the RAMDirectory was
> closed). Before 2.1, apparently you won't hit any exception and the
> IndexWrite will keep running but will have released it's write lock (I
> think).
> I plan to fix IndexWriter methods to throw an IllegalStateException if
> it has been closed.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Distributed index
I'm trying to tailor lucene into support a simple distributed index
for searching.
Currently I have created a simple class that generates an distributed
stats index file(if used upon a FSDirectory) (which i principle
contains a) total numDoc b) updated TermInfo for all terms in a index
partition.
Then I have Implemented a simple FilteredIndexReader
(DistributedIndexReader) that overwrites
public int numDoc(){
}
public int termFreq(Term t){
}
to look-up values in the stats index file.
now instantiating a Searchable upon the the DistributedIndexReader in
principle will score docs as if the doc had been in the full index ???
of cause updating such an index introduce a level of complexity
compared to a regular index, but that could be handled by creating a
DistributingIndexWriter (indexing to an array of Directory). adding an
init method taking an additional int setting the level of redundancy
in the index, thereby making the final index fault tolerant by
duplicating docs from one partial index to the other partial indexes).
Coupling this with a MasterDistSearcher which only function would be
dispatching a query to all nodes, merge results and remove duplicates.
Any thoughts about this setup - any pitfalls I have missed?
What I hope to accomplish is to be able to run fairly large (>100GB
(and fairly) static indexes on 'cheap' equipment - preferably having
the index running in RAMDirectory.
Cheers
Hans Lund
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-816) Manage dependencies in the build with ivy
[ https://issues.apache.org/jira/browse/LUCENE-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476022 ] Stephane Bailliez commented on LUCENE-816: -- I see some very deep similarities with some known build here... > Manage dependencies in the build with ivy > - > > Key: LUCENE-816 > URL: https://issues.apache.org/jira/browse/LUCENE-816 > Project: Lucene - Java > Issue Type: New Feature > Components: Analysis >Affects Versions: 2.1 >Reporter: Nicolas Lalevée > Attachments: common-build.tar.gz, external-libs.tar.gz, > ivy-build.patch > > > There were issues about making the 2.1 release : > http://www.nabble.com/-VOTE--release-Lucene-2.1-tf3228536.html#a8994721 > Then the discussion started to talk about maven, and also about ivy. > I propose here a draft, a proof of concept of an ant + ivy build. I made this > build parallel to the actual one, so people can evaluate it. > Note that I have only ivy-ified the core, the demo and the contrib/benchmark. > The other contrib projects can be ivy-ified quite easily. > The build system is in the common-build directory. In this directory we have : > * common-build.xml : the main common build which handle dependencies with ivy > * common-build-project.xml : build a java project, core, demo, or a contrib > one > * common-build-webapp.xml : extend common-build-project and have some tasks > about building a war > * common-build-modules.xml : allow to build sevral projects, just using some > subant task > * common-build-gcj.xml : build with gcj. It work once, need to be fixed > * ivyconf.xml, ivyconf.properties : ivy configuration > * build.xml : a little task to generate the ivyconf.xml to use with the > eclipse ivy plugin > * eclipse directory : contains some XSL/XML to generate .classpath and > .project > To test it and see how ivy is cool : > cd contrib/benchmark > ant -f build-ivy.xml buildeep > and look at the new local-libs directory at the root of the lucene directory ! -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-814) javacc on Win32 (cygwin) creates wrong line endings - fix them with 'ant replace'
[ https://issues.apache.org/jira/browse/LUCENE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476030 ] Doron Cohen commented on LUCENE-814: Hoss is right about both: 1) "ant fixcrlf" is much simpler to use,and does the job. I wish I have discovered that task before fighting with the replace tasks. 2) QueryParser.jj has svn:eol-style native and hence when extracted under DOS, has Windows eols. There, "ant javacc" which runs as a Win app, would create Windows eols, all dandy. But if Cygwin is used for checkout, jj has Unix eols, however here "ant javacc" still runs as Win app, and the result file is a mix of eol styles. I think there is no fixed (non native) setting for jj that would sattisfy all situations. Also, I think this is why Eclipse svn plugin (subclipse) sometimes shows a file as entirely modified (comparing to repository head) - may be related to checkout with cygwin while Eclipse runs as Win app. So I see three options: 1 - leave as is (do not fix) 2 - add target to build.xml to allow easily fixing eol (what one can do with sed) 3 - fix eol-style to be the same as that of the jj file (worth the effort?) Preferences? > javacc on Win32 (cygwin) creates wrong line endings - fix them with 'ant > replace' > - > > Key: LUCENE-814 > URL: https://issues.apache.org/jira/browse/LUCENE-814 > Project: Lucene - Java > Issue Type: Task > Components: Build > Environment: Windows, Cygwin >Reporter: Doron Cohen > Assigned To: Doron Cohen >Priority: Minor > Fix For: 2.1 > > Attachments: 814.javacc.line.ends.patch > > > "ant javacc" in Windows/Cygwin generates files with wrong line endings (\r > or \r\n instead of *Nix's \n). > I managed to get rid of those usingperl -p -e 's/(\r\n|\n|\r)/\n/g' > Some useful info on line ending issues is in > http://en.wikipedia.org/wiki/Newline > After wasting some time to get rid of those, I modified javacc-QueryParser > build.xml task to take care of that. > So now QueryParser files created with "ant javacc" are fixed (if required) to > have \n as line ends. > Should probably do that also for the other javacc targets: javacc-HTMLParser > and javacc-StandardAnalyzer(?) -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-818) IndexWriter should detect when it's used after being closed
[ https://issues.apache.org/jira/browse/LUCENE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476044 ] Michael McCandless commented on LUCENE-818: --- That approach seems a little overkill to me. I would need to create a new Closeable interface, and then a static "ensureOpen" method somewhere else. These would probably live in util, so then this is all public: users see that these classes implement Closeable, yet, it's not really a publicly useful feature, so it adds noise to the javadocs. I was planning instead on just adding a private "ensureOpen()" to IndexWriter (and I agree I should do IndexReader as well) that throws IllegalStateException if it's closed. I think noise is kept to the same minimum (?) because all public methods that require this just have an added ensureOpen() call at the top. This is how IndexModifier works today. Hmm, IndexReader already throws IOException in certain cases if it's already closed. So I think I will make a new exception (AlreadyClosedException?) that subclasses IOException and throw that. > IndexWriter should detect when it's used after being closed > --- > > Key: LUCENE-818 > URL: https://issues.apache.org/jira/browse/LUCENE-818 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 2.1 >Reporter: Michael McCandless > Assigned To: Michael McCandless >Priority: Minor > > Spinoff from this thread on java-user: > http://www.gossamer-threads.com/lists/lucene/java-user/45986 > If you call addDocument on IndexWriter after it's closed you'll hit a > hard-to-explain NullPointerException (because the RAMDirectory was > closed). Before 2.1, apparently you won't hit any exception and the > IndexWrite will keep running but will have released it's write lock (I > think). > I plan to fix IndexWriter methods to throw an IllegalStateException if > it has been closed. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-813) leading wildcard's don't work with trailing wildcard
[ https://issues.apache.org/jira/browse/LUCENE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476055 ] Michael Busch commented on LUCENE-813: -- I tried it out, Doron. It works fine and all tests pass. I like the new tests in TestWildcard. > leading wildcard's don't work with trailing wildcard > > > Key: LUCENE-813 > URL: https://issues.apache.org/jira/browse/LUCENE-813 > Project: Lucene - Java > Issue Type: Bug >Reporter: Hoss Man > Assigned To: Doron Cohen > Attachments: 813.fix.lead.wildcard.patch, qp-leading-wildcard.patch > > > As reported by Antony Bowesman, leading wildcards don't work when there is a > trailing wildcard character -- instead a PrefixQuery is constructed. > http://www.nabble.com/QueryParser-bug--tf3270956.html -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-707) Lucene Java Site docs
[ https://issues.apache.org/jira/browse/LUCENE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Aroush updated LUCENE-707: - Attachment: lucene.apache.org.patch Hi Dough, Attached is a patch to add Lucene.Net to TLP of Lucene site. Thanks. -- George Aroush > Lucene Java Site docs > - > > Key: LUCENE-707 > URL: https://issues.apache.org/jira/browse/LUCENE-707 > Project: Lucene - Java > Issue Type: Improvement > Components: Website > Environment: N/A >Reporter: Grant Ingersoll > Assigned To: Grant Ingersoll >Priority: Minor > Attachments: lucene.apache.org.patch > > > It would be really nice if the Java site docs where consistent with the rest > of the Lucene family (namely, with navigation tabs, etc.) so that one can > easily go between Nutch, Hadoop, etc. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LUCENE-549) Sort bug with ParallelMultiSearcher
[ https://issues.apache.org/jira/browse/LUCENE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch closed LUCENE-549. Resolution: Duplicate This is a duplicate of LUCENE-548 > Sort bug with ParallelMultiSearcher > --- > > Key: LUCENE-549 > URL: https://issues.apache.org/jira/browse/LUCENE-549 > Project: Lucene - Java > Issue Type: Bug > Components: Search >Affects Versions: 1.9 > Environment: FC2 Java 1.4.9 >Reporter: dan >Priority: Minor > > > Output: > java.lang.ClassCastException: java.lang.String > at > org.apache.lucene.search.FieldDocSortedHitQueue.lessThan(FieldDocSortedHitQueue.java:119) > at org.apache.lucene.util.PriorityQueue.insert(PriorityQueue.java:61) > at > org.apache.lucene.search.MultiSearcherThread.run(ParallelMultiSearcher.java:271) > > Input: > - This only occurs when searching more than one index using > ParallelMultiSearcher > - I use the signature new Sort( "date", true) > - The values in dates are strings in the form 20060419 > - The call to getType in FieldDocSortedHitQueue misinterprets the value as an > INT, then the exception is thrown > > Available workaround > - I use the the signature new Sort(new SortField( "date", SortField.STRING, > true)) and the problem goes away. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
