Re: 2.4.0
+1 here as well. I cannot use a version in our enterprise project development unless it's an official release. I assume there are much more fixes and enhancements from 2.1 to 2.3.2 then from 2.3.2 to 2.4.0. Thanks, Eran. On Tue, Dec 9, 2008 at 10:04 PM, TJ Kolev [EMAIL PROTECTED] wrote: I second for a stable release. I've also been waiting for one to integrate into our product for several months now. Thank you. tjk :) On Tue, Dec 9, 2008 at 11:07 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Good remark. Recently I had the same situation. The lack of up-to-date stable release was the reason not to use Lucene.NET for a new project. Andrei Johnson, Scott ?: Please do commit 2.3.2 as a release that one can just download. I have seen multiple cases where the lack of a more up-to-date stable release of Lucene.NET has slowed corporate adoption and introduced needless version incompatibilities. This release would help push our development partners and toolkit vendors towards using the latest technology. Thanks, Scott -Original Message- From: Digy [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2008 6:54 PM To: lucene-net-dev@incubator.apache.org Subject: RE: 2.4.0 Hi Doug, The bug(LUCENENET-106) carried over from v2.1 to v2.3.1 and v2.3.2, a newly discovered one(LUCENENET-164)and an improvement(LUCENENET-160 - since there are a lot of exceptions while checking whether a string is a real-number or not) are waiting to be fixed. And there is also no stable release for Lucene.Net community after v2.0.0.4 where one can just download and use Lucene.Net without searching the JIRA issues and applying some patches(like I do). Therefore, I would prefer,first, to commit a version ready-to-release(2.3.2) and then, while dealing with the apache-release-process, continue with the development of the v2.4 In the mean time, try to keep yourself alive J DIGY. -Original Message- From: Doug Sale [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 11:19 PM To: lucene-net-dev@incubator.apache.org Subject: 2.4.0 Folks, I've been converting the 2.3.2 code to 2.4.0 and anticipate having a clean build by Monday AM. There will be bugs, I'm sure. Also, there are some new classes that I've only stubbed out, and some issues I've identified that would be best hashed out (by the community) prior to addressing. I am curious how we should proceed to work on the 2.4.0 conversion. Should we tag 2.3.2 and have the 2.4.0 code be HEAD? Is there a better-suited approach? I would like to get this code into SVN *somewhere* (in case I get hit by a bus, laptop in hand). Honestly, I want to preserve our momentum and be prepared to work on the Lucene.Net 3.0 version as it becomes available (or sooner...). Please respond with any thoughts/ideas? Thanks, Doug
Re: API Inconsistency
The locking is done in .NET inside the method by using the lock(this) operation surrounding all the method implementation. This is exactly equivalent to synchronized at the method level in java. As long as all the methods that have synchronized in Java are implemented using lock(this) in .NET then it's the same. Eran. On Sun, May 3, 2009 at 2:57 PM, Andrew Psaltis apsal...@ideapivot.comwrote: While looking at the latest MEAP edition of Lucene in Action and trying to port Listing 10.2 from the Java to .NET, I noticed an inconsistency in the DecRef and IncRef API of the IndexReader. The java version have the following signature: public synchronized void incRef() public synchronized void decRef() However, the .NET version (latest source fron SVN as of Thursday -4/30/2009) has the following signatures: protected internal virtual void IncRef() protected internal virtual void DecRef() Is this an acceptable deviation? Thanks, Andrew
New SpanAndQuery implementation
Hello all, Currently the only way to simulate a SpanAndQuery was to use SpanNearQuery with a large enough slop. The problem with this method is that the returned span contains all the positions between the AND clauses. This makes it not effective for highlighting or for knowing what was the original terms that were used in the query. Also there is the issue of order which shouldn't matter for AND queries. I've created a new SpanAndQuery implementation and would like to contribute it. My solution returns each matched hit as a different span. For example: doc1: a b c d doc2: a d b c a a span near query for ( a NEAR c) will result in two spans: doc1:a b c and doc2:a d b c with the new span and query the result will be: doc1: a c, doc2: a c a (with the correct positions of each span). How should contribute it? I know that Lucene.Net only follows the jave Lucene project but if someone is interested in my implementation they can import it to java and add it to the java version (although changes are probably required because of the versions differences between java and .Net). Thanks, Eran.
Re: [VOTE] Graduate Lucene.Net as a subproject under Apache Lucene
+1 On Thu, Sep 17, 2009 at 3:49 AM, George Aroush geo...@aroush.net wrote: Hi Folks, This vote calls to graduate the Lucene.Net project (http://incubator.apache.org/lucene.net/) as a sub-project under Apache Lucene. Everyone in the Lucene.Net community is welcome to vote. The goal is to see no -1 and all the committers must cast a +1 before we can move on for a final vote by the Apache IPMC. The rationale for graduation is: * Lucene.Net has been under incubation since April 2006 (3 1/2 years now). * During incubation, Lucene.Net has: - Made, 1 official release (Incubating-Apache-Lucene.Net-2.0-004-11Mar07). - Released, as SVN tag, 18 ports of Java Lucene (from 1.9 to 2.4.0). - Released, as SVN tag, port of WordNet.Net 2.0, SpellChecker.Net 2.0, Snowball.Net 2.0, and Highlighter.Net 2.0. - Released, MSDN style documentation for the above release. - Accepted, two new committers: Isik YIGIT (DIGY) digydigy @ gmail.com and Doug Sale dsale @ myspace-inc.com were added in November 2008 (George Aroush george @ aroush.net is the original committer). - The community has grown, with a healthy followers. - Is being used by well established companies in production (I'm not sure what's the legality to mention their names here, or even if I have the complete list). - Is being used by Beagle project. If this graduation is approved, Lucene.Net will be officially called Apache Lucene.Net Please cast your votes: [ ] +1 Graduate Lucene.Net as a sub-project under Apache Lucene. [ ] 0 I don't care. [ ] -1 Lucene.Net is not ready to graduate as a sub-project under Apache Lucene, because ... This vote will close on September 21st, 2009. Regards, -- George
port of contrib packages from java
Hi, Is there any thought to port all the contrib packages from java lucene after the porting of core 2.9.1 version is complete? Currently there are 23 packages in java contrib compared to only 7 packages in .net contrib. Thanks, Eran.
Re: port of contrib packages from java
Although some contrib packages might not be in use by any lucene .net user at the moment, I think we should port them all in accordance with the java version (it shouldn't be as hard as the core classes although I'm not sure there are any tests for them). When and if we'll diverge from the core java implementation in order to take benefit of .net and apply each patch as it comes, we can do the same for contrib which also sees much less traffic anyway. Eran On Mon, Nov 23, 2009 at 8:27 PM, Digy digyd...@gmail.com wrote: I don't know whether there is such a preference for contribs or not, but diverging from Java makes life harder for further ports. Will someone be able to easily port the next release after your state of art work following .NET best practices? Or a new port from scratch? DIGY -Original Message- From: Nicholas Paldino [.NET/C# MVP] [mailto:casper...@caspershouse.com] Sent: Monday, November 23, 2009 7:11 PM To: lucene-net-dev@incubator.apache.org Subject: RE: port of contrib packages from java On a somewhat related note, these ports, do they adhere to the tenants applied to the main trunk, or can they better follow .NET best practices if one wants to apply them? - Nick -Original Message- From: Eran Sevi [mailto:erans...@gmail.com] Sent: Monday, November 23, 2009 8:45 AM To: lucene-net-dev@incubator.apache.org Subject: Re: port of contrib packages from java Thanks, I'm more into the queries package. If no one will beat me to it, I hope I can help and add it myself. How did you do the port? manually or using some conversion tools? Eran. On Mon, Nov 23, 2009 at 3:34 PM, Roger Chapman ro...@stormid.com wrote: I've done a first pass port of the Spatial Contrib project : https://issues.apache.org/jira/browse/LUCENENET-199 Roger. -Original Message- From: Eran Sevi [mailto:erans...@gmail.com] Sent: 23 November 2009 13:17 To: lucene-net-dev@incubator.apache.org Subject: port of contrib packages from java Hi, Is there any thought to port all the contrib packages from java lucene after the porting of core 2.9.1 version is complete? Currently there are 23 packages in java contrib compared to only 7 packages in .net contrib. Thanks, Eran.
[jira] Created: (LUCENENET-310) SegmentInfos class is not equatable
SegmentInfos class is not equatable --- Key: LUCENENET-310 URL: https://issues.apache.org/jira/browse/LUCENENET-310 Project: Lucene.Net Issue Type: Bug Reporter: Eran Sevi SegmentInfos class currently inherits from ArrayList which fails equations checks on this class. Test scenario: 1. Open an IndexWriter on an existing index. 2. get reader from IndexWriter by calling IndexWriter.GetReader(). 2. run reader.IsCurrent() Results: IsCurrent method returns false although the reader is indeed current. This is caused because IsCurrent() calls IndexWriter.NrtIsCurrent() which tries to match two equal SegmentInfos lists using the Equals method. The method returns false although the lists are identical. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LUCENENET-310) SegmentInfos class is not equatable
[ https://issues.apache.org/jira/browse/LUCENENET-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eran Sevi updated LUCENENET-310: Attachment: SegmentInfos.patch Attached patch. Fixed the issue by inheriting from SupportClass.EquatableListSegmentInfo instead of ArrayList. This also required adding virtual modifier to EquatableList.Clone() method. Eran. SegmentInfos class is not equatable --- Key: LUCENENET-310 URL: https://issues.apache.org/jira/browse/LUCENENET-310 Project: Lucene.Net Issue Type: Bug Reporter: Eran Sevi Attachments: SegmentInfos.patch SegmentInfos class currently inherits from ArrayList which fails equations checks on this class. Test scenario: 1. Open an IndexWriter on an existing index. 2. get reader from IndexWriter by calling IndexWriter.GetReader(). 2. run reader.IsCurrent() Results: IsCurrent method returns false although the reader is indeed current. This is caused because IsCurrent() calls IndexWriter.NrtIsCurrent() which tries to match two equal SegmentInfos lists using the Equals method. The method returns false although the lists are identical. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LUCENENET-310) SegmentInfos class is not equatable
[ https://issues.apache.org/jira/browse/LUCENENET-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eran Sevi closed LUCENENET-310. --- Resolution: Duplicate Duplicate from LUCENENET-287. Sorry I missed this issue. SegmentInfos class is not equatable --- Key: LUCENENET-310 URL: https://issues.apache.org/jira/browse/LUCENENET-310 Project: Lucene.Net Issue Type: Bug Reporter: Eran Sevi Attachments: SegmentInfos.patch SegmentInfos class currently inherits from ArrayList which fails equations checks on this class. Test scenario: 1. Open an IndexWriter on an existing index. 2. get reader from IndexWriter by calling IndexWriter.GetReader(). 2. run reader.IsCurrent() Results: IsCurrent method returns false although the reader is indeed current. This is caused because IsCurrent() calls IndexWriter.NrtIsCurrent() which tries to match two equal SegmentInfos lists using the Equals method. The method returns false although the lists are identical. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LUCENENET-287) TestIndexWriterReader.TestUpdateDocument
[ https://issues.apache.org/jira/browse/LUCENENET-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eran Sevi updated LUCENENET-287: Attachment: SegmentInfos3.patch Added SegmentInfos3.patch. All TestIndexWriterReader tests passed. For now I left the inheritance from ArrayList and implemented a simple override of the Equals method from ArrayList. A better solution might increase performance or be more elegant. Eran. TestIndexWriterReader.TestUpdateDocument -- Key: LUCENENET-287 URL: https://issues.apache.org/jira/browse/LUCENENET-287 Project: Lucene.Net Issue Type: Bug Reporter: Andrei Iliev Attachments: SegmentInfos.patch, SegmentInfos2.patch, SegmentInfos3.patch SegmentInfos is derived from ArrayList. So Equals and GetHashCode should behave as java ArrayList (see LUCENENET-284). After that patch TestIndexWriterReader.TestUpdateDocument is passed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LUCENENET-287) TestIndexWriterReader.TestUpdateDocument
[ https://issues.apache.org/jira/browse/LUCENENET-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eran Sevi updated LUCENENET-287: Attachment: SegmentInfos4.patch Added new patch with both fixes suggested above (casting and hash code). Eran. TestIndexWriterReader.TestUpdateDocument -- Key: LUCENENET-287 URL: https://issues.apache.org/jira/browse/LUCENENET-287 Project: Lucene.Net Issue Type: Bug Reporter: Andrei Iliev Attachments: SegmentInfos.patch, SegmentInfos2.patch, SegmentInfos3.patch, SegmentInfos4.patch SegmentInfos is derived from ArrayList. So Equals and GetHashCode should behave as java ArrayList (see LUCENENET-284). After that patch TestIndexWriterReader.TestUpdateDocument is passed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LUCENENET-314) Excluded files from project
[
https://issues.apache.org/jira/browse/LUCENENET-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eran Sevi updated LUCENENET-314:
Attachment: LUCENENET-314.patch
There files are no longer even included in the project - They were removed
completly from the java version, and probably left in the .net project by
mistake.
Usually in many other cases, methods do get marked as deprecated/obsolete, but
I guess in these cases it was decided not to do so - thus breaking backward
compatibility on purpose.
I saw that in some cases (like spans), there's no point in keeping the removed
files since in order to use them you'll need to modify a lot of other files as
well.
Anyway, I attached the patch that remove these files, in case we'll go for
removing them.
Eran.
Excluded files from project
---
Key: LUCENENET-314
URL: https://issues.apache.org/jira/browse/LUCENENET-314
Project: Lucene.Net
Issue Type: Improvement
Reporter: Digy
Priority: Minor
Attachments: LUCENENET-314.patch
Creating this issue on behalf of Eran Sevi
DIGY
{quote}
Hi,
There are many files that are maintained in the svn but are not included in
the Lucene.Net csproj.
Probably these files are leftovers from previous releases since the project
compiles and runs without a problem. If not, they should be included in the
project.
I think we should include a patch that removes all these files.
Here's the list of the files I found that are not used:
Index\DirectoryIndexReader.cs
Index\MultiSegmentReader.cs
Index\ReadOnlyMultiSegmentReader.cs
Index\StoredFieldsWriterPerField.cs
Index\StoredFieldWriterPerThread.cs
Search\ExtendedFieldCacheImpl.cs
Search\NonMatchingScorer.cs
Search\RemoteCachingWrapperFilter.cs
Search\RemoteSearchable.cs
Search\Spans\NearSpans.cs
Search\Spans\PayloadSpans.cs
Thanks,
Eran.
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
