You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Prescott Nasser <ge...@hotmail.com> on 2013/06/06 20:38:04 UTC
Lucene 4.0
Hey guys -
I know I've been MIA a little while. We have a board report due soon - I think it prudent that we advise them that we seem to have stalled somewhat. We've got a few low hanging items out of of jira and have been responsive on the mailing list to community questions, but I don't think we've done anything to move forward with 4.0.
To that end - I'd like to *try* and start us back up moving forward. What is the best way to accomplish this? If we took the java lucene 4.0 code and committed that java to our branch and then just let people pull that down and being changing / modifying is that one way to maybe make some forward progress?
~P
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Athrun Saga was working on the TestFramework assembly this weekend, he
might be able to give an update there. I had just started porting some of
it but didn't finish. I haven't finished any test assemblies. He brought up
the point about the tests assembly missing a reference to testframework as
well and was going to correct that in a pull request.
I mainly have been using Lucene.Net.All, again without running any tests.
And I only build the projects that will compile, which right now is Core,
Analyzers (since i've excluded the old ones), and QueryParser (which is
incomplete, only the classic queryparser is ported).
While my trivial "hello lucene" app worked fine with the new code, I hit an
"already finished" exception in the FST code when I tried using my domain's
indexer code. I'm going to try to isolate this to a failing test case and
see if some of the Java guys that worked on the FST code could help out, as
I have no clue what's going on there.
I am throwing a little conference this weekend (
http://www.codeonthebeach.com/) so I will be pretty preoccupied this week,
next week I should be able to hack more on it.
Paul
On Mon, Aug 12, 2013 at 2:36 AM, Simon Svensson <si...@devhost.se> wrote:
> Hi,
>
> I took a look into porting the Hunspell part of Contrib.Analyzers (mostly
> because I initiated the port from java some time ago) but ran into some
> problems.
>
> 1) BaseTokenStreamTestCase (in Lucene.Net.TestFramework) references a
> missing RandomIndexWriter, and wont compile. Is this something that's
> missed in a commit, or something we need to port?
>
> 2) What solution file are you using to open everything, including the test
> projects? Lucene.Net.All does not contain any test projects, and the
> Contrib.All.Tests is missing a referece to Lucene.Net.TestFramework.
>
> // Simon
>
>
> On 2013-08-09 15:08, Paul Irwin wrote:
>
>> We mostly ported the code manually, copying and pasting the java method by
>> method and fixing the differences, since C# and Java are so similar. That
>> allowed us to see areas where using C# conventions would be better, such
>> as
>> properties and mild LINQ to Objects, and usage of IEnumerable<T>, etc..
>> However, there were a few bits of code that were too intense to port
>> manually, such as the BulkOperationPacked* classes under Util.Packed, and
>> the scanner code in StandardAnalyzer and ClassicAnalyzer, so I wrote a
>> quick one-off C# app in each case to do some regexes and whatnot to make
>> it
>> port easier.
>>
>> If you speak a language other than english, porting that language's
>> Analyzer classes would be helpful. Also we didn't port the javadoc
>> comments
>> as that was tedious, so those need to be done, and the unit tests need to
>> be ported. I'm currently trying to figure out why QueryParser didn't port
>> successfully. If I can get that to work, I'll probably move on to
>> EnglishAnalyzer.
>>
>> Paul
>>
>> On Thu, Aug 8, 2013 at 11:04 PM, Simon Svensson <si...@devhost.se> wrote:
>>
>> Hi,
>>>
>>> I'm unsure how the porting is done. Are you using any tools to convert
>>> java to c#, or is it done manually by just showing both code
>>> side-by-side?
>>>
>>> I can squeeze out a few coding hours this weekend, where do you want me
>>> to
>>> start?
>>>
>>> // Simon
>>>
>>>
>>> On 2013-08-08 21:31, Paul Irwin wrote:
>>>
>>> Is this mailing list dead?! If anyone is interested in releasing an
>>>> up-to-date build of Lucene.net, please write back! If you didn't read my
>>>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>>>> compatibility thanks to the help of my colleagues. We just need to round
>>>> out the contrib modules, unit tests, and documentation as a community
>>>> and
>>>> we can push Lucene.net forward almost 3 years in time -- Lucene java
>>>> 3.0.3
>>>> was packaged in December 2010!
>>>>
>>>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer,
>>>> SimpleAnalyzer,
>>>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>>>> (where they now live in Lucene java, they were moved from core) and
>>>> their
>>>> associated filters and tokenizers. I've briefly tested each and they
>>>> seem
>>>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>>>> language analyzers until we can forward-port them. So now the Analyzers
>>>> DLL
>>>> compiles with those analyzers only. Also, I fixed the bug that was
>>>> causing
>>>> NumericRangeQuery to not work.
>>>>
>>>> Next on my list is the QueryParsers contrib library (QueryParser was
>>>> moved
>>>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>>>> test a pretty common real-world use case (the prototypical "hello
>>>> lucene"
>>>> tutorial). After that, it might be worth forward-porting what we have so
>>>> far to 4.4 and use that as the latest point to finish out the port. The
>>>> changes shouldn't be too dramatic to core from what I can tell.
>>>>
>>>> My fork/branch: https://github.com/paulirwin/****<https://github.com/paulirwin/**>
>>>> lucene.net/tree/lucene_4_3_0<h**ttps://github.com/paulirwin/**
>>>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>>> >
>>>>
>>>>
>>>> I'll keep updating as I go, but if anyone wants to jump in, there's not
>>>> a
>>>> better time than now...
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> I made a dumb mistake... I have worked with StandardAnalyzer so long
>>>> that
>>>>
>>>>> I forgot that KeywordAnalyzer is not what I needed to be using, I
>>>>> needed
>>>>> to
>>>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces...
>>>>> duh.
>>>>>
>>>>> Now it works after re-indexing with a quick, dirty implementation of
>>>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1
>>>>> can
>>>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move
>>>>> on
>>>>> to
>>>>> find out why NumericRangeQuery isn't working.
>>>>>
>>>>> Sorry for the blast of emails, but I wanted to prevent people from
>>>>> spending time hunting down my mistake!
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong.
>>>>> Java's
>>>>>
>>>>>> byte being signed is a pain.
>>>>>>
>>>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>>>> results. It doesn't find any terms when scanning for them. I also
>>>>>> tried
>>>>>> a
>>>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and
>>>>>> it
>>>>>> didn't find any results that way either. So right now only
>>>>>> MatchAllDocsQuery seems to work.
>>>>>>
>>>>>> If anyone would like to do a Google Hangout or anything sometime to
>>>>>> look
>>>>>> into it, let me know.
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>>>> wrote:
>>>>>>
>>>>>> I realized after I sent that email last night that I could do as you
>>>>>>
>>>>>>> described. When you've been debugging through
>>>>>>> CorruptedIndexExceptions, you
>>>>>>> get a little bit of tunnel vision... haha
>>>>>>>
>>>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>>>> .ToString()'ing
>>>>>>> the matching documents prints the fields to the console, so it's
>>>>>>> loading in
>>>>>>> the stored fields data correctly.
>>>>>>>
>>>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>>>> that
>>>>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>>>> operations
>>>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>>>> looking, but if someone could grab my fork/branch and help me look
>>>>>>> that
>>>>>>> would be great. Here's example index writing and then reading code
>>>>>>> (also
>>>>>>> included is a quick port of KeywordAnalyzer):
>>>>>>> https://gist.github.com/****anonymous/6174164<https://gist.github.com/**anonymous/6174164>
>>>>>>> <https://**gist.github.com/anonymous/**6174164<https://gist.github.com/anonymous/6174164>
>>>>>>> >
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>
Re: Lucene 4.0
Posted by Simon Svensson <si...@devhost.se>.
Hi,
I took a look into porting the Hunspell part of Contrib.Analyzers
(mostly because I initiated the port from java some time ago) but ran
into some problems.
1) BaseTokenStreamTestCase (in Lucene.Net.TestFramework) references a
missing RandomIndexWriter, and wont compile. Is this something that's
missed in a commit, or something we need to port?
2) What solution file are you using to open everything, including the
test projects? Lucene.Net.All does not contain any test projects, and
the Contrib.All.Tests is missing a referece to Lucene.Net.TestFramework.
// Simon
On 2013-08-09 15:08, Paul Irwin wrote:
> We mostly ported the code manually, copying and pasting the java method by
> method and fixing the differences, since C# and Java are so similar. That
> allowed us to see areas where using C# conventions would be better, such as
> properties and mild LINQ to Objects, and usage of IEnumerable<T>, etc..
> However, there were a few bits of code that were too intense to port
> manually, such as the BulkOperationPacked* classes under Util.Packed, and
> the scanner code in StandardAnalyzer and ClassicAnalyzer, so I wrote a
> quick one-off C# app in each case to do some regexes and whatnot to make it
> port easier.
>
> If you speak a language other than english, porting that language's
> Analyzer classes would be helpful. Also we didn't port the javadoc comments
> as that was tedious, so those need to be done, and the unit tests need to
> be ported. I'm currently trying to figure out why QueryParser didn't port
> successfully. If I can get that to work, I'll probably move on to
> EnglishAnalyzer.
>
> Paul
>
> On Thu, Aug 8, 2013 at 11:04 PM, Simon Svensson <si...@devhost.se> wrote:
>
>> Hi,
>>
>> I'm unsure how the porting is done. Are you using any tools to convert
>> java to c#, or is it done manually by just showing both code side-by-side?
>>
>> I can squeeze out a few coding hours this weekend, where do you want me to
>> start?
>>
>> // Simon
>>
>>
>> On 2013-08-08 21:31, Paul Irwin wrote:
>>
>>> Is this mailing list dead?! If anyone is interested in releasing an
>>> up-to-date build of Lucene.net, please write back! If you didn't read my
>>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>>> compatibility thanks to the help of my colleagues. We just need to round
>>> out the contrib modules, unit tests, and documentation as a community and
>>> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>>> was packaged in December 2010!
>>>
>>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>>> (where they now live in Lucene java, they were moved from core) and their
>>> associated filters and tokenizers. I've briefly tested each and they seem
>>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>>> language analyzers until we can forward-port them. So now the Analyzers
>>> DLL
>>> compiles with those analyzers only. Also, I fixed the bug that was causing
>>> NumericRangeQuery to not work.
>>>
>>> Next on my list is the QueryParsers contrib library (QueryParser was moved
>>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>>> test a pretty common real-world use case (the prototypical "hello lucene"
>>> tutorial). After that, it might be worth forward-porting what we have so
>>> far to 4.4 and use that as the latest point to finish out the port. The
>>> changes shouldn't be too dramatic to core from what I can tell.
>>>
>>> My fork/branch: https://github.com/paulirwin/**
>>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>>
>>> I'll keep updating as I go, but if anyone wants to jump in, there's not a
>>> better time than now...
>>>
>>>
>>>
>>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>>>
>>> I made a dumb mistake... I have worked with StandardAnalyzer so long that
>>>> I forgot that KeywordAnalyzer is not what I needed to be using, I needed
>>>> to
>>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>>>
>>>> Now it works after re-indexing with a quick, dirty implementation of
>>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
>>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on
>>>> to
>>>> find out why NumericRangeQuery isn't working.
>>>>
>>>> Sorry for the blast of emails, but I wanted to prevent people from
>>>> spending time hunting down my mistake!
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>>>>> byte being signed is a pain.
>>>>>
>>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>>> results. It doesn't find any terms when scanning for them. I also tried
>>>>> a
>>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>>>>> didn't find any results that way either. So right now only
>>>>> MatchAllDocsQuery seems to work.
>>>>>
>>>>> If anyone would like to do a Google Hangout or anything sometime to look
>>>>> into it, let me know.
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> I realized after I sent that email last night that I could do as you
>>>>>> described. When you've been debugging through
>>>>>> CorruptedIndexExceptions, you
>>>>>> get a little bit of tunnel vision... haha
>>>>>>
>>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>>> .ToString()'ing
>>>>>> the matching documents prints the fields to the console, so it's
>>>>>> loading in
>>>>>> the stored fields data correctly.
>>>>>>
>>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>>> that
>>>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>>> operations
>>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>>> looking, but if someone could grab my fork/branch and help me look that
>>>>>> would be great. Here's example index writing and then reading code
>>>>>> (also
>>>>>> included is a quick port of KeywordAnalyzer):
>>>>>> https://gist.github.com/**anonymous/6174164<https://gist.github.com/anonymous/6174164>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
While it works for a simple "hello lucene" index for me, I tried using it
with my existing domain indexer app and I get an exception saying "already
finished" inside FST.cs when IndexWriter.Commit is called. I really don't
understand when debugging through it what the FSTs are doing exactly... If
anyone understands this concept and can help hunt down the bug, that would
be great. Or let me know if you don't encounter the same exception.
http://blog.mikemccandless.com/2010/12/using-finite-state-transducers-in.html
On Fri, Aug 9, 2013 at 2:39 PM, Paul Irwin <pi...@feature23.com> wrote:
> QueryParser is now working. Java's octal literals and that Reader.Read
> returns -1 at EOF bit me. It's now working, so the prototypical "hello
> lucene" now works in Lucene.net 4.3.1. Please grab it and let me know if
> you have any issues.
>
>
> On Fri, Aug 9, 2013 at 9:08 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> We mostly ported the code manually, copying and pasting the java method
>> by method and fixing the differences, since C# and Java are so similar.
>> That allowed us to see areas where using C# conventions would be better,
>> such as properties and mild LINQ to Objects, and usage of IEnumerable<T>,
>> etc.. However, there were a few bits of code that were too intense to port
>> manually, such as the BulkOperationPacked* classes under Util.Packed, and
>> the scanner code in StandardAnalyzer and ClassicAnalyzer, so I wrote a
>> quick one-off C# app in each case to do some regexes and whatnot to make it
>> port easier.
>>
>> If you speak a language other than english, porting that language's
>> Analyzer classes would be helpful. Also we didn't port the javadoc comments
>> as that was tedious, so those need to be done, and the unit tests need to
>> be ported. I'm currently trying to figure out why QueryParser didn't port
>> successfully. If I can get that to work, I'll probably move on to
>> EnglishAnalyzer.
>>
>> Paul
>>
>>
>> On Thu, Aug 8, 2013 at 11:04 PM, Simon Svensson <si...@devhost.se> wrote:
>>
>>> Hi,
>>>
>>> I'm unsure how the porting is done. Are you using any tools to convert
>>> java to c#, or is it done manually by just showing both code side-by-side?
>>>
>>> I can squeeze out a few coding hours this weekend, where do you want me
>>> to start?
>>>
>>> // Simon
>>>
>>>
>>> On 2013-08-08 21:31, Paul Irwin wrote:
>>>
>>>> Is this mailing list dead?! If anyone is interested in releasing an
>>>> up-to-date build of Lucene.net, please write back! If you didn't read my
>>>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>>>> compatibility thanks to the help of my colleagues. We just need to round
>>>> out the contrib modules, unit tests, and documentation as a community
>>>> and
>>>> we can push Lucene.net forward almost 3 years in time -- Lucene java
>>>> 3.0.3
>>>> was packaged in December 2010!
>>>>
>>>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer,
>>>> SimpleAnalyzer,
>>>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>>>> (where they now live in Lucene java, they were moved from core) and
>>>> their
>>>> associated filters and tokenizers. I've briefly tested each and they
>>>> seem
>>>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>>>> language analyzers until we can forward-port them. So now the Analyzers
>>>> DLL
>>>> compiles with those analyzers only. Also, I fixed the bug that was
>>>> causing
>>>> NumericRangeQuery to not work.
>>>>
>>>> Next on my list is the QueryParsers contrib library (QueryParser was
>>>> moved
>>>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>>>> test a pretty common real-world use case (the prototypical "hello
>>>> lucene"
>>>> tutorial). After that, it might be worth forward-porting what we have so
>>>> far to 4.4 and use that as the latest point to finish out the port. The
>>>> changes shouldn't be too dramatic to core from what I can tell.
>>>>
>>>> My fork/branch: https://github.com/paulirwin/**
>>>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>>>
>>>> I'll keep updating as I go, but if anyone wants to jump in, there's not
>>>> a
>>>> better time than now...
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> I made a dumb mistake... I have worked with StandardAnalyzer so long
>>>>> that
>>>>> I forgot that KeywordAnalyzer is not what I needed to be using, I
>>>>> needed to
>>>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces...
>>>>> duh.
>>>>>
>>>>> Now it works after re-indexing with a quick, dirty implementation of
>>>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1
>>>>> can
>>>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move
>>>>> on to
>>>>> find out why NumericRangeQuery isn't working.
>>>>>
>>>>> Sorry for the blast of emails, but I wanted to prevent people from
>>>>> spending time hunting down my mistake!
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong.
>>>>>> Java's
>>>>>> byte being signed is a pain.
>>>>>>
>>>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>>>> results. It doesn't find any terms when scanning for them. I also
>>>>>> tried a
>>>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and
>>>>>> it
>>>>>> didn't find any results that way either. So right now only
>>>>>> MatchAllDocsQuery seems to work.
>>>>>>
>>>>>> If anyone would like to do a Google Hangout or anything sometime to
>>>>>> look
>>>>>> into it, let me know.
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>>>> wrote:
>>>>>>
>>>>>> I realized after I sent that email last night that I could do as you
>>>>>>> described. When you've been debugging through
>>>>>>> CorruptedIndexExceptions, you
>>>>>>> get a little bit of tunnel vision... haha
>>>>>>>
>>>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>>>> .ToString()'ing
>>>>>>> the matching documents prints the fields to the console, so it's
>>>>>>> loading in
>>>>>>> the stored fields data correctly.
>>>>>>>
>>>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>>>> that
>>>>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>>>> operations
>>>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>>>> looking, but if someone could grab my fork/branch and help me look
>>>>>>> that
>>>>>>> would be great. Here's example index writing and then reading code
>>>>>>> (also
>>>>>>> included is a quick port of KeywordAnalyzer):
>>>>>>> https://gist.github.com/**anonymous/6174164<https://gist.github.com/anonymous/6174164>
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
QueryParser is now working. Java's octal literals and that Reader.Read
returns -1 at EOF bit me. It's now working, so the prototypical "hello
lucene" now works in Lucene.net 4.3.1. Please grab it and let me know if
you have any issues.
On Fri, Aug 9, 2013 at 9:08 AM, Paul Irwin <pi...@feature23.com> wrote:
> We mostly ported the code manually, copying and pasting the java method by
> method and fixing the differences, since C# and Java are so similar. That
> allowed us to see areas where using C# conventions would be better, such as
> properties and mild LINQ to Objects, and usage of IEnumerable<T>, etc..
> However, there were a few bits of code that were too intense to port
> manually, such as the BulkOperationPacked* classes under Util.Packed, and
> the scanner code in StandardAnalyzer and ClassicAnalyzer, so I wrote a
> quick one-off C# app in each case to do some regexes and whatnot to make it
> port easier.
>
> If you speak a language other than english, porting that language's
> Analyzer classes would be helpful. Also we didn't port the javadoc comments
> as that was tedious, so those need to be done, and the unit tests need to
> be ported. I'm currently trying to figure out why QueryParser didn't port
> successfully. If I can get that to work, I'll probably move on to
> EnglishAnalyzer.
>
> Paul
>
>
> On Thu, Aug 8, 2013 at 11:04 PM, Simon Svensson <si...@devhost.se> wrote:
>
>> Hi,
>>
>> I'm unsure how the porting is done. Are you using any tools to convert
>> java to c#, or is it done manually by just showing both code side-by-side?
>>
>> I can squeeze out a few coding hours this weekend, where do you want me
>> to start?
>>
>> // Simon
>>
>>
>> On 2013-08-08 21:31, Paul Irwin wrote:
>>
>>> Is this mailing list dead?! If anyone is interested in releasing an
>>> up-to-date build of Lucene.net, please write back! If you didn't read my
>>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>>> compatibility thanks to the help of my colleagues. We just need to round
>>> out the contrib modules, unit tests, and documentation as a community and
>>> we can push Lucene.net forward almost 3 years in time -- Lucene java
>>> 3.0.3
>>> was packaged in December 2010!
>>>
>>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer,
>>> SimpleAnalyzer,
>>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>>> (where they now live in Lucene java, they were moved from core) and their
>>> associated filters and tokenizers. I've briefly tested each and they seem
>>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>>> language analyzers until we can forward-port them. So now the Analyzers
>>> DLL
>>> compiles with those analyzers only. Also, I fixed the bug that was
>>> causing
>>> NumericRangeQuery to not work.
>>>
>>> Next on my list is the QueryParsers contrib library (QueryParser was
>>> moved
>>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>>> test a pretty common real-world use case (the prototypical "hello lucene"
>>> tutorial). After that, it might be worth forward-porting what we have so
>>> far to 4.4 and use that as the latest point to finish out the port. The
>>> changes shouldn't be too dramatic to core from what I can tell.
>>>
>>> My fork/branch: https://github.com/paulirwin/**
>>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>>
>>> I'll keep updating as I go, but if anyone wants to jump in, there's not a
>>> better time than now...
>>>
>>>
>>>
>>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com>
>>> wrote:
>>>
>>> I made a dumb mistake... I have worked with StandardAnalyzer so long
>>>> that
>>>> I forgot that KeywordAnalyzer is not what I needed to be using, I
>>>> needed to
>>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>>>
>>>> Now it works after re-indexing with a quick, dirty implementation of
>>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1
>>>> can
>>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move
>>>> on to
>>>> find out why NumericRangeQuery isn't working.
>>>>
>>>> Sorry for the blast of emails, but I wanted to prevent people from
>>>> spending time hunting down my mistake!
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong.
>>>>> Java's
>>>>> byte being signed is a pain.
>>>>>
>>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>>> results. It doesn't find any terms when scanning for them. I also
>>>>> tried a
>>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and
>>>>> it
>>>>> didn't find any results that way either. So right now only
>>>>> MatchAllDocsQuery seems to work.
>>>>>
>>>>> If anyone would like to do a Google Hangout or anything sometime to
>>>>> look
>>>>> into it, let me know.
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> I realized after I sent that email last night that I could do as you
>>>>>> described. When you've been debugging through
>>>>>> CorruptedIndexExceptions, you
>>>>>> get a little bit of tunnel vision... haha
>>>>>>
>>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>>> .ToString()'ing
>>>>>> the matching documents prints the fields to the console, so it's
>>>>>> loading in
>>>>>> the stored fields data correctly.
>>>>>>
>>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>>> that
>>>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>>> operations
>>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>>> looking, but if someone could grab my fork/branch and help me look
>>>>>> that
>>>>>> would be great. Here's example index writing and then reading code
>>>>>> (also
>>>>>> included is a quick port of KeywordAnalyzer):
>>>>>> https://gist.github.com/**anonymous/6174164<https://gist.github.com/anonymous/6174164>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>>
>>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
We mostly ported the code manually, copying and pasting the java method by
method and fixing the differences, since C# and Java are so similar. That
allowed us to see areas where using C# conventions would be better, such as
properties and mild LINQ to Objects, and usage of IEnumerable<T>, etc..
However, there were a few bits of code that were too intense to port
manually, such as the BulkOperationPacked* classes under Util.Packed, and
the scanner code in StandardAnalyzer and ClassicAnalyzer, so I wrote a
quick one-off C# app in each case to do some regexes and whatnot to make it
port easier.
If you speak a language other than english, porting that language's
Analyzer classes would be helpful. Also we didn't port the javadoc comments
as that was tedious, so those need to be done, and the unit tests need to
be ported. I'm currently trying to figure out why QueryParser didn't port
successfully. If I can get that to work, I'll probably move on to
EnglishAnalyzer.
Paul
On Thu, Aug 8, 2013 at 11:04 PM, Simon Svensson <si...@devhost.se> wrote:
> Hi,
>
> I'm unsure how the porting is done. Are you using any tools to convert
> java to c#, or is it done manually by just showing both code side-by-side?
>
> I can squeeze out a few coding hours this weekend, where do you want me to
> start?
>
> // Simon
>
>
> On 2013-08-08 21:31, Paul Irwin wrote:
>
>> Is this mailing list dead?! If anyone is interested in releasing an
>> up-to-date build of Lucene.net, please write back! If you didn't read my
>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>> compatibility thanks to the help of my colleagues. We just need to round
>> out the contrib modules, unit tests, and documentation as a community and
>> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>> was packaged in December 2010!
>>
>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>> (where they now live in Lucene java, they were moved from core) and their
>> associated filters and tokenizers. I've briefly tested each and they seem
>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>> language analyzers until we can forward-port them. So now the Analyzers
>> DLL
>> compiles with those analyzers only. Also, I fixed the bug that was causing
>> NumericRangeQuery to not work.
>>
>> Next on my list is the QueryParsers contrib library (QueryParser was moved
>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>> test a pretty common real-world use case (the prototypical "hello lucene"
>> tutorial). After that, it might be worth forward-porting what we have so
>> far to 4.4 and use that as the latest point to finish out the port. The
>> changes shouldn't be too dramatic to core from what I can tell.
>>
>> My fork/branch: https://github.com/paulirwin/**
>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>
>> I'll keep updating as I go, but if anyone wants to jump in, there's not a
>> better time than now...
>>
>>
>>
>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>> I made a dumb mistake... I have worked with StandardAnalyzer so long that
>>> I forgot that KeywordAnalyzer is not what I needed to be using, I needed
>>> to
>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>>
>>> Now it works after re-indexing with a quick, dirty implementation of
>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on
>>> to
>>> find out why NumericRangeQuery isn't working.
>>>
>>> Sorry for the blast of emails, but I wanted to prevent people from
>>> spending time hunting down my mistake!
>>>
>>>
>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>> wrote:
>>>
>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>>>> byte being signed is a pain.
>>>>
>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>> results. It doesn't find any terms when scanning for them. I also tried
>>>> a
>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>>>> didn't find any results that way either. So right now only
>>>> MatchAllDocsQuery seems to work.
>>>>
>>>> If anyone would like to do a Google Hangout or anything sometime to look
>>>> into it, let me know.
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> I realized after I sent that email last night that I could do as you
>>>>> described. When you've been debugging through
>>>>> CorruptedIndexExceptions, you
>>>>> get a little bit of tunnel vision... haha
>>>>>
>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>> .ToString()'ing
>>>>> the matching documents prints the fields to the console, so it's
>>>>> loading in
>>>>> the stored fields data correctly.
>>>>>
>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>> that
>>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>> operations
>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>> looking, but if someone could grab my fork/branch and help me look that
>>>>> would be great. Here's example index writing and then reading code
>>>>> (also
>>>>> included is a quick port of KeywordAnalyzer):
>>>>> https://gist.github.com/**anonymous/6174164<https://gist.github.com/anonymous/6174164>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>
Re: Lucene 4.0
Posted by Simon Svensson <si...@devhost.se>.
Hi,
I'm unsure how the porting is done. Are you using any tools to convert
java to c#, or is it done manually by just showing both code side-by-side?
I can squeeze out a few coding hours this weekend, where do you want me
to start?
// Simon
On 2013-08-08 21:31, Paul Irwin wrote:
> Is this mailing list dead?! If anyone is interested in releasing an
> up-to-date build of Lucene.net, please write back! If you didn't read my
> other messages, I have Lucene.net Core working with Lucene java 4.3.1
> compatibility thanks to the help of my colleagues. We just need to round
> out the contrib modules, unit tests, and documentation as a community and
> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
> was packaged in December 2010!
>
> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
> (where they now live in Lucene java, they were moved from core) and their
> associated filters and tokenizers. I've briefly tested each and they seem
> to work correctly. I've purposefully "Exclude[d] from Project" the other
> language analyzers until we can forward-port them. So now the Analyzers DLL
> compiles with those analyzers only. Also, I fixed the bug that was causing
> NumericRangeQuery to not work.
>
> Next on my list is the QueryParsers contrib library (QueryParser was moved
> out of Lucene java core) so that, combined with StandardAnalyzer, we can
> test a pretty common real-world use case (the prototypical "hello lucene"
> tutorial). After that, it might be worth forward-porting what we have so
> far to 4.4 and use that as the latest point to finish out the port. The
> changes shouldn't be too dramatic to core from what I can tell.
>
> My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
> I'll keep updating as I go, but if anyone wants to jump in, there's not a
> better time than now...
>
>
>
> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> I made a dumb mistake... I have worked with StandardAnalyzer so long that
>> I forgot that KeywordAnalyzer is not what I needed to be using, I needed to
>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>
>> Now it works after re-indexing with a quick, dirty implementation of
>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on to
>> find out why NumericRangeQuery isn't working.
>>
>> Sorry for the blast of emails, but I wanted to prevent people from
>> spending time hunting down my mistake!
>>
>>
>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>>> byte being signed is a pain.
>>>
>>> Now there's no exception doing a TermQuery, but I also don't get any
>>> results. It doesn't find any terms when scanning for them. I also tried a
>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>>> didn't find any results that way either. So right now only
>>> MatchAllDocsQuery seems to work.
>>>
>>> If anyone would like to do a Google Hangout or anything sometime to look
>>> into it, let me know.
>>>
>>>
>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com> wrote:
>>>
>>>> I realized after I sent that email last night that I could do as you
>>>> described. When you've been debugging through CorruptedIndexExceptions, you
>>>> get a little bit of tunnel vision... haha
>>>>
>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
>>>> the matching documents prints the fields to the console, so it's loading in
>>>> the stored fields data correctly.
>>>>
>>>> I tried doing a TermQuery and now I get a "read past EOF" exception that
>>>> I can't figure out. There's a whole bunch of buffered byte array operations
>>>> going on and I can't determine where the issue came from. I'll keep
>>>> looking, but if someone could grab my fork/branch and help me look that
>>>> would be great. Here's example index writing and then reading code (also
>>>> included is a quick port of KeywordAnalyzer):
>>>> https://gist.github.com/anonymous/6174164
>>>>
>>>> Thanks!
>>>>
>>>>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
This has been ported in my fork/branch, but has not been tested. Please
test away!
Also, I got the classic QueryParser from 4.3 to compile in the new
Contrib.QueryParsers DLL, but it gets stuck in an infinite loop when using
the default field and exceptions when specifying a field in the query.
Anyone with experience with scanners/lexers should debug into this and take
a look. I have a feeling the bug is in the complex scanner code of
QueryParser or QueryParserTokenManager.
On Thu, Aug 8, 2013 at 8:53 PM, Michael Mitiaguin <
mitiaguinm@optusnet.com.au> wrote:
> Paul,
>
> I am greatly interested in trying Lucene 4.0 FuzzyQuery
>
> http://blog.mikemccandless.**com/2011/03/lucenes-**
> fuzzyquery-is-100-times-**faster.html<http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html>
> Any plans to port this part ?
>
>
> On 8/9/2013 5:31 AM, Paul Irwin wrote:
>
>> Is this mailing list dead?! If anyone is interested in releasing an
>> up-to-date build of Lucene.net, please write back! If you didn't read my
>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>> compatibility thanks to the help of my colleagues. We just need to round
>> out the contrib modules, unit tests, and documentation as a community and
>> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>> was packaged in December 2010!
>>
>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>> (where they now live in Lucene java, they were moved from core) and their
>> associated filters and tokenizers. I've briefly tested each and they seem
>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>> language analyzers until we can forward-port them. So now the Analyzers
>> DLL
>> compiles with those analyzers only. Also, I fixed the bug that was causing
>> NumericRangeQuery to not work.
>>
>> Next on my list is the QueryParsers contrib library (QueryParser was moved
>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>> test a pretty common real-world use case (the prototypical "hello lucene"
>> tutorial). After that, it might be worth forward-porting what we have so
>> far to 4.4 and use that as the latest point to finish out the port. The
>> changes shouldn't be too dramatic to core from what I can tell.
>>
>> My fork/branch: https://github.com/paulirwin/**
>> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
>>
>> I'll keep updating as I go, but if anyone wants to jump in, there's not a
>> better time than now...
>>
>>
>>
>>
>>
>
RE: Lucene 4.0
Posted by Prescott Nasser <ge...@hotmail.com>.
Hey Paul -
If you can help us out by filling out the ICLA (http://www.apache.org/licenses/icla.txt). This will allow us to pull this into the official repo.
I also can't thank you enough for taking the initiative to being the port - hopefully we can all pitch in and finish it.
~Prescott
> Date: Thu, 8 Aug 2013 21:02:00 -0400
> Subject: Re: Lucene 4.0
> From: pirwin@feature23.com
> To: dev@lucenenet.apache.org
>
> This has been ported in my fork/branch, but has not been tested. Please
> test away!
>
> Also, I got the classic QueryParser from 4.3 to compile in the new
> Contrib.QueryParsers DLL, but it gets stuck in an infinite loop when using
> the default field and exceptions when specifying a field in the query.
> Anyone with experience with scanners/lexers should debug into this and take
> a look. I have a feeling the bug is in the complex scanner code of
> QueryParser or QueryParserTokenManager.
>
>
> On Thu, Aug 8, 2013 at 8:53 PM, Michael Mitiaguin <
> mitiaguinm@optusnet.com.au> wrote:
>
> > Paul,
> >
> > I am greatly interested in trying Lucene 4.0 FuzzyQuery
> >
> > http://blog.mikemccandless.**com/2011/03/lucenes-**
> > fuzzyquery-is-100-times-**faster.html<http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html>
> > Any plans to port this part ?
> >
> >
> > On 8/9/2013 5:31 AM, Paul Irwin wrote:
> >
> >> Is this mailing list dead?! If anyone is interested in releasing an
> >> up-to-date build of Lucene.net, please write back! If you didn't read my
> >> other messages, I have Lucene.net Core working with Lucene java 4.3.1
> >> compatibility thanks to the help of my colleagues. We just need to round
> >> out the contrib modules, unit tests, and documentation as a community and
> >> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
> >> was packaged in December 2010!
> >>
> >> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
> >> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
> >> (where they now live in Lucene java, they were moved from core) and their
> >> associated filters and tokenizers. I've briefly tested each and they seem
> >> to work correctly. I've purposefully "Exclude[d] from Project" the other
> >> language analyzers until we can forward-port them. So now the Analyzers
> >> DLL
> >> compiles with those analyzers only. Also, I fixed the bug that was causing
> >> NumericRangeQuery to not work.
> >>
> >> Next on my list is the QueryParsers contrib library (QueryParser was moved
> >> out of Lucene java core) so that, combined with StandardAnalyzer, we can
> >> test a pretty common real-world use case (the prototypical "hello lucene"
> >> tutorial). After that, it might be worth forward-porting what we have so
> >> far to 4.4 and use that as the latest point to finish out the port. The
> >> changes shouldn't be too dramatic to core from what I can tell.
> >>
> >> My fork/branch: https://github.com/paulirwin/**
> >> lucene.net/tree/lucene_4_3_0<https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0>
> >>
> >> I'll keep updating as I go, but if anyone wants to jump in, there's not a
> >> better time than now...
> >>
> >>
> >>
> >>
> >>
> >
Re: Lucene 4.0
Posted by Michael Mitiaguin <mi...@optusnet.com.au>.
Paul,
I am greatly interested in trying Lucene 4.0 FuzzyQuery
http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html
Any plans to port this part ?
On 8/9/2013 5:31 AM, Paul Irwin wrote:
> Is this mailing list dead?! If anyone is interested in releasing an
> up-to-date build of Lucene.net, please write back! If you didn't read my
> other messages, I have Lucene.net Core working with Lucene java 4.3.1
> compatibility thanks to the help of my colleagues. We just need to round
> out the contrib modules, unit tests, and documentation as a community and
> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
> was packaged in December 2010!
>
> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
> (where they now live in Lucene java, they were moved from core) and their
> associated filters and tokenizers. I've briefly tested each and they seem
> to work correctly. I've purposefully "Exclude[d] from Project" the other
> language analyzers until we can forward-port them. So now the Analyzers DLL
> compiles with those analyzers only. Also, I fixed the bug that was causing
> NumericRangeQuery to not work.
>
> Next on my list is the QueryParsers contrib library (QueryParser was moved
> out of Lucene java core) so that, combined with StandardAnalyzer, we can
> test a pretty common real-world use case (the prototypical "hello lucene"
> tutorial). After that, it might be worth forward-porting what we have so
> far to 4.4 and use that as the latest point to finish out the port. The
> changes shouldn't be too dramatic to core from what I can tell.
>
> My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
> I'll keep updating as I go, but if anyone wants to jump in, there's not a
> better time than now...
>
>
>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Athrun,
You can do what I did before you become an "official" contributor, which is
to fork the lucene.net repo on Github at
https://github.com/apache/lucene.net, or if you want to work off of my
latest changes before it's pulled into the main repo, you can pull from
here: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
If you speak Chinese, you could jump in and help port the ChineseAnalyzer
in Contrib.Analyzers. When referencing the Java source, we're currently
referencing the code in the lucene_solr_4_3 branch as when we started, 4.4
wasn't out yet. Don't reference trunk/master, as that's where 5.0 dev is
taking place if i'm not mistaken.
On Fri, Aug 9, 2013 at 12:08 AM, 许鹏 <xu...@188.com> wrote:
> Hi Paul,
>
>
> I am a developer from China, I currently using Solr 4.3.0 to construct our
> own
> data system for search and analysis. I am very interested in the work that
> porting
> Lucene java 4.3.1, and I want to join this team to work on this. But I
> have never
> been involved in open source projects, Can you give me some suggestion to
> join
> the team and start contributing.
> Additional, I am not good at English writing, but reading is ok. Also, I
> am now learning English,
> I believe it will be more smooth communication.
>
>
>
>
> Athrun Saga
> 8/9/2013
>
>
>
>
>
>
> At 2013-08-09 03:31:47,"Paul Irwin" <pi...@feature23.com> wrote:
>
> >Is this mailing list dead?! If anyone is interested in releasing an
> >up-to-date build of Lucene.net, please write back! If you didn't read my
> >other messages, I have Lucene.net Core working with Lucene java 4.3.1
> >compatibility thanks to the help of my colleagues. We just need to round
> >out the contrib modules, unit tests, and documentation as a community and
> >we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
> >was packaged in December 2010!
> >
> >I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
> >ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
> >(where they now live in Lucene java, they were moved from core) and their
> >associated filters and tokenizers. I've briefly tested each and they seem
> >to work correctly. I've purposefully "Exclude[d] from Project" the other
> >language analyzers until we can forward-port them. So now the Analyzers
> DLL
> >compiles with those analyzers only. Also, I fixed the bug that was causing
> >NumericRangeQuery to not work.
> >
> >Next on my list is the QueryParsers contrib library (QueryParser was moved
> >out of Lucene java core) so that, combined with StandardAnalyzer, we can
> >test a pretty common real-world use case (the prototypical "hello lucene"
> >tutorial). After that, it might be worth forward-porting what we have so
> >far to 4.4 and use that as the latest point to finish out the port. The
> >changes shouldn't be too dramatic to core from what I can tell.
> >
> >My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >
> >I'll keep updating as I go, but if anyone wants to jump in, there's not a
> >better time than now...
> >
> >
> >
> >On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
> >
> >> I made a dumb mistake... I have worked with StandardAnalyzer so long
> that
> >> I forgot that KeywordAnalyzer is not what I needed to be using, I
> needed to
> >> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
> >>
> >> Now it works after re-indexing with a quick, dirty implementation of
> >> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1
> can
> >> also be read and searched by Java Lucene 4.3.1. Now I'm going to move
> on to
> >> find out why NumericRangeQuery isn't working.
> >>
> >> Sorry for the blast of emails, but I wanted to prevent people from
> >> spending time hunting down my mistake!
> >>
> >>
> >> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >>
> >>> I was able to resolve the EOF issue by fixing a bug in ReadVLong.
> Java's
> >>> byte being signed is a pain.
> >>>
> >>> Now there's no exception doing a TermQuery, but I also don't get any
> >>> results. It doesn't find any terms when scanning for them. I also
> tried a
> >>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and
> it
> >>> didn't find any results that way either. So right now only
> >>> MatchAllDocsQuery seems to work.
> >>>
> >>> If anyone would like to do a Google Hangout or anything sometime to
> look
> >>> into it, let me know.
> >>>
> >>>
> >>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >>>
> >>>> I realized after I sent that email last night that I could do as you
> >>>> described. When you've been debugging through
> CorruptedIndexExceptions, you
> >>>> get a little bit of tunnel vision... haha
> >>>>
> >>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
> >>>> IndexSearcher and TopScoreDocsCollector and get hits! And
> .ToString()'ing
> >>>> the matching documents prints the fields to the console, so it's
> loading in
> >>>> the stored fields data correctly.
> >>>>
> >>>> I tried doing a TermQuery and now I get a "read past EOF" exception
> that
> >>>> I can't figure out. There's a whole bunch of buffered byte array
> operations
> >>>> going on and I can't determine where the issue came from. I'll keep
> >>>> looking, but if someone could grab my fork/branch and help me look
> that
> >>>> would be great. Here's example index writing and then reading code
> (also
> >>>> included is a quick port of KeywordAnalyzer):
> >>>> https://gist.github.com/anonymous/6174164
> >>>>
> >>>> Thanks!
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <
> itamar@code972.com>wrote:
> >>>>
> >>>>> Great
> >>>>>
> >>>>> You can build you Query objects on your own to execute a search, you
> >>>>> don't
> >>>>> actually have to use QueryParser for that
> >>>>>
> >>>>>
> >>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
> >>>>> wrote:
> >>>>>
> >>>>> > Hey all, sorry it's been a little while, but I wanted to let you
> know
> >>>>> that
> >>>>> > although I took a few weeks off from it, I now have a 4.3.1
> equivalent
> >>>>> > Lucene.net core building and able to write a simple index in Lucene
> >>>>> 4.2
> >>>>> > codec and read in things like the number of documents and whatnot.
> >>>>> Since
> >>>>> > QueryParser has been moved to a separate module in Lucene Java
> 4.x, I
> >>>>> > haven't ported that yet so I haven't done a real search, and I only
> >>>>> built
> >>>>> > the index using a quick port of KeywordAnalyzer which all those
> >>>>> analyzers
> >>>>> > have also moved to another module. But this is definitely good
> >>>>> progress and
> >>>>> > should be a launch point for finishing a 4.3/4.4 port.
> >>>>> >
> >>>>> > You can see my fork/branch here:
> >>>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
> >>>>> like I
> >>>>> > said, only core builds now, no modules/tests build, so only open
> the
> >>>>> > Lucene.Net.Core.sln)
> >>>>> >
> >>>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
> >>>>> the
> >>>>> > community into finishing the 4.3/4.4 port. Let me know if you have
> any
> >>>>> > questions, thanks!
> >>>>> >
> >>>>> >
> >>>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
> >>>>> itamar@code972.com
> >>>>> > >wrote:
> >>>>> >
> >>>>> > > Paul, that's awesome. I will need some more time to go over this
> >>>>> thread
> >>>>> > and
> >>>>> > > your work to give actual feedback, SUPER busy at the moment
> >>>>> > >
> >>>>> > >
> >>>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <
> pirwin@feature23.com>
> >>>>> > wrote:
> >>>>> > >
> >>>>> > > > All,
> >>>>> > > >
> >>>>> > > > My colleagues and I have made good progress on porting Lucene
> >>>>> 4.3's
> >>>>> > core
> >>>>> > > > library before, during, and after the hackathon last week. We
> now
> >>>>> only
> >>>>> > > have
> >>>>> > > > some remaining items in Search, Index, and Codecs namespaces
> >>>>> (plus a
> >>>>> > few
> >>>>> > > > other minor ones here and there). I expect to be done by the
> end
> >>>>> of the
> >>>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
> >>>>> Packed),
> >>>>> > > and
> >>>>> > > > the root Codecs and Codecs.PerField namespaces are all now
> "done".
> >>>>> > > >
> >>>>> > > > Again, my goal is to only get a buildable, experimental build
> of
> >>>>> > > Lucene.net
> >>>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
> >>>>> porting
> >>>>> > > new
> >>>>> > > > javadoc comments or unit tests right now, due to the vast
> amount
> >>>>> of
> >>>>> > code
> >>>>> > > > that needs to be written just to get it to compile. If this
> work
> >>>>> ends
> >>>>> > up
> >>>>> > > > becoming a pull request, great, otherwise it should help
> >>>>> accelerate a
> >>>>> > > port
> >>>>> > > > of 4.3.x since the bulk of the work on core will already be
> done
> >>>>> and
> >>>>> > > > contributors can use it as a reference. And again, we're taking
> >>>>> the
> >>>>> > > > pragmatic approach of porting class-by-class,
> >>>>> namespace-by-namespace,
> >>>>> > > with
> >>>>> > > > the understanding that until we're done the project won't
> build.
> >>>>> > > >
> >>>>> > > > Once complete, I also will work on updating the Analyzers
> contrib
> >>>>> > module
> >>>>> > > > and porting the QueryParsers contrib module, which I feel
> should
> >>>>> be
> >>>>> > > > included in the core NuGet package for Lucene.net as the core
> >>>>> library
> >>>>> > is
> >>>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
> >>>>> without
> >>>>> > > them.
> >>>>> > > > You can check out the code on my fork/branch here:
> >>>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >>>>> > > >
> >>>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
> >>>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
> >>>>> For the
> >>>>> > > MMap
> >>>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
> >>>>> > > > MemoryMappedFile support which should emulate the Java nio
> stuff
> >>>>> pretty
> >>>>> > > > well, but required some creative shuffling of the code to make
> it
> >>>>> work
> >>>>> > > due
> >>>>> > > > to lifecycle management.
> >>>>> > > >
> >>>>> > > > I'll update again this weekend or next week, when we should
> have
> >>>>> > wrapped
> >>>>> > > up
> >>>>> > > > most of the main hacking on porting the core code.
> >>>>> > > >
> >>>>> > > > Paul
> >>>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <
> pirwin@feature23.com
> >>>>> >
> >>>>> > > wrote:
> >>>>> > > >
> >>>>> > > > > Marcos,
> >>>>> > > > >
> >>>>> > > > > That would be helpful. As far as I can tell, the 3.0 java
> code
> >>>>> is
> >>>>> > only
> >>>>> > > on
> >>>>> > > > > SVN here, before the lucene and solr projects were bundled
> >>>>> together:
> >>>>> > > > >
> >>>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> >>>>> > > > >
> >>>>> > > > > The SVN for 4.3 java is here:
> >>>>> > > > >
> >>>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> >>>>> > > > > And the GitHub for 4.3 java is here:
> >>>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> >>>>> > > > >
> >>>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
> >>>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> >>>>> > > > >
> >>>>> > > > > My fork is the "upstream" fork for my team members, and i'm
> >>>>> remote
> >>>>> > > > merging
> >>>>> > > > > their changes in from their forks while they fetch/merge from
> >>>>> mine to
> >>>>> > > get
> >>>>> > > > > everyone else's changes, rather than using pull requests.
> James
> >>>>> and I
> >>>>> > > > have
> >>>>> > > > > been working the past few days on the Util namespace ahead of
> >>>>> > tonight's
> >>>>> > > > > hackathon since that namespace is in common with the rest of
> the
> >>>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know
> of
> >>>>> > hacking
> >>>>> > > on
> >>>>> > > > > porting 4.3, each with a different namespace or part of a
> >>>>> namespace.
> >>>>> > > > Since
> >>>>> > > > > we're going class-by-class, namespace-by-namespace, the
> project
> >>>>> does
> >>>>> > > not
> >>>>> > > > > build as it is. Once we finish doing a translation of each
> >>>>> file, then
> >>>>> > > > we'll
> >>>>> > > > > hammer out any remaining issues and get it to build again.
> I'm
> >>>>> hoping
> >>>>> > > > that
> >>>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
> >>>>> > > > >
> >>>>> > > > > But one thing to keep in mind is it looks like much
> >>>>> functionality has
> >>>>> > > > been
> >>>>> > > > > moved out of core into the contrib modules, especially around
> >>>>> > analysis,
> >>>>> > > > for
> >>>>> > > > > 4.0+. For example, there are no built-in analyzers in core
> >>>>> anymore.
> >>>>> > So
> >>>>> > > > when
> >>>>> > > > > this is all done, we may want to include at least the
> analysis
> >>>>> > contrib
> >>>>> > > > > module in with the standard core NuGet package, because
> >>>>> otherwise
> >>>>> > it's
> >>>>> > > > > practically useless unless you roll your own analyzer.
> >>>>> > > > >
> >>>>> > > > > Paul
> >>>>> > > > >
> >>>>> > > > >
> >>>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
> >>>>> > marcoslimagon@gmail.com
> >>>>> > > > >wrote:
> >>>>> > > > >
> >>>>> > > > >> Hi everyone!
> >>>>> > > > >>
> >>>>> > > > >> Does someone know where can I find the 3.0.3 release from
> >>>>> > > Lucene(java)?
> >>>>> > > > >>
> >>>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
> >>>>> 4.3.0 and
> >>>>> > > > make
> >>>>> > > > >> the diff between then and get all changes between
> releases... I
> >>>>> > gonna
> >>>>> > > > >> publish it here soon. (If you think there is another
> important
> >>>>> > > release,
> >>>>> > > > >> let
> >>>>> > > > >> me know)
> >>>>> > > > >>
> >>>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry)
> >>>>> with
> >>>>> > 4.3.0
> >>>>> > > > >> port
> >>>>> > > > >> for .Net on github (last email)?
> >>>>> > > > >>
> >>>>> > > > >> See you,
> >>>>> > > > >>
> >>>>> > > > >>
> >>>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> >>>>> > > > >>
> >>>>> > > > >> > Thanks for the discussion points, Michael.
> >>>>> > > > >> >
> >>>>> > > > >> > I would vote for not worrying about trying to achieve
> >>>>> portable
> >>>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to
> 4.3+
> >>>>> is
> >>>>> > > > >> completed.
> >>>>> > > > >> > Otherwise it may delay the project and stall it further.
> >>>>> That's
> >>>>> > just
> >>>>> > > > my
> >>>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x
> features.
> >>>>> > > > >> >
> >>>>> > > > >> > I have started porting the changes from the core library
> >>>>> (from the
> >>>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
> >>>>> separate
> >>>>> > > > branch.
> >>>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
> >>>>> port
> >>>>> > > until
> >>>>> > > > >> > there's changes to pull from upstream to work from. Also
> due
> >>>>> to my
> >>>>> > > > time
> >>>>> > > > >> > constraints, I am not fully documenting new methods that
> I'm
> >>>>> > adding.
> >>>>> > > > >> But if
> >>>>> > > > >> > anyone wants to pull/copy/reference my changes while
> porting,
> >>>>> > that's
> >>>>> > > > >> > awesome. My branch currently does not build as I'm
> primarily
> >>>>> going
> >>>>> > > > >> > class-by-class, starting with the util namespace. Once we
> >>>>> get the
> >>>>> > > ball
> >>>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
> >>>>> join
> >>>>> > in.
> >>>>> > > > But
> >>>>> > > > >> > hopefully my work will be useful to someone, if not as a
> pull
> >>>>> > > request
> >>>>> > > > >> then
> >>>>> > > > >> > as a reference. I'm also going to be holding a hackathon
> >>>>> this week
> >>>>> > > > with
> >>>>> > > > >> my
> >>>>> > > > >> > colleagues where we're all going to work on the port. I'm
> >>>>> > comparing
> >>>>> > > > >> files
> >>>>> > > > >> > and making changes as necessary, rather than starting from
> >>>>> > scratch.
> >>>>> > > My
> >>>>> > > > >> > repo/branch is here:
> >>>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >>>>> > > > >> >
> >>>>> > > > >> > Paul
> >>>>> > > > >> >
> >>>>> > > > >> >
> >>>>> > > > >> >
> >>>>> > > > >> >
> >>>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> >>>>> > > > >> > mherndon@michaelherndon.com> wrote:
> >>>>> > > > >> >
> >>>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
> >>>>> apache
> >>>>> > > > >> > maintains.
> >>>>> > > > >> > >
> >>>>> > > > >> > > The was some work at one time to move the official svn
> >>>>> > repository
> >>>>> > > to
> >>>>> > > > >> > start
> >>>>> > > > >> > > using git one instead. Was that actually finalized or
> not?
> >>>>> > > > >> > >
> >>>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch
> to
> >>>>> see
> >>>>> > > what
> >>>>> > > > >> kind
> >>>>> > > > >> > of
> >>>>> > > > >> > > work was involved using a portable libraries project.
> Some
> >>>>> of it
> >>>>> > > can
> >>>>> > > > >> > still
> >>>>> > > > >> > > be used but will need to be validated against the
> current
> >>>>> > version
> >>>>> > > of
> >>>>> > > > >> > Java's
> >>>>> > > > >> > > Lucene. It was also using .net 4.
> >>>>> > > > >> > >
> >>>>> > > > >> > > clean branch vs current. Its going to depend on
> what we
> >>>>> > > support.
> >>>>> > > > >> If
> >>>>> > > > >> > you
> >>>>> > > > >> > > support windows mobile 8, win RT, then the current code
> in
> >>>>> trunk
> >>>>> > > > will
> >>>>> > > > >> not
> >>>>> > > > >> > > compile against those versions of the framework which
> >>>>> would a
> >>>>> > > > >> frustrating
> >>>>> > > > >> > > starting point, then you couldn't even run tests, which
> >>>>> would
> >>>>> > make
> >>>>> > > > >> taking
> >>>>> > > > >> > > patches very difficult. Supporting those can almost
> mean
> >>>>> larger
> >>>>> > > > gaps
> >>>>> > > > >> in
> >>>>> > > > >> > > design between Lucene.Net and its parent project.
> >>>>> > > > >> > >
> >>>>> > > > >> > > Also the structure has changed significantly between
> the
> >>>>> > branches
> >>>>> > > > and
> >>>>> > > > >> > the
> >>>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java
> 6,
> >>>>> and
> >>>>> > > seems
> >>>>> > > > >> > > significantly different. That doesn't mean you can't
> >>>>> cherry
> >>>>> > pick
> >>>>> > > > >> stuff
> >>>>> > > > >> > > from the other tags/branches that would still work as
> is.
> >>>>> A
> >>>>> > clean
> >>>>> > > > >> branch
> >>>>> > > > >> > > would also make it easier to get our build / tool chain
> in
> >>>>> order
> >>>>> > > as
> >>>>> > > > >> you
> >>>>> > > > >> > can
> >>>>> > > > >> > > then do them incrementally versus having to do all the
> >>>>> stuff
> >>>>> > that
> >>>>> > > I
> >>>>> > > > >> did
> >>>>> > > > >> > for
> >>>>> > > > >> > > the 3x branch which saps energy and desire to code. It
> >>>>> could
> >>>>> > > also
> >>>>> > > > >> make
> >>>>> > > > >> > it
> >>>>> > > > >> > > easier to see which classes have been ported or not.
> >>>>> > > > >> > >
> >>>>> > > > >> > > The major downside to a clean branch is extra work it
> >>>>> requires
> >>>>> > and
> >>>>> > > > the
> >>>>> > > > >> > > start up cost in time and energy of getting it in order,
> >>>>> which
> >>>>> > can
> >>>>> > > > be
> >>>>> > > > >> > > daunting / intimidating and lower morale. And generally
> >>>>> you want
> >>>>> > > to
> >>>>> > > > >> use
> >>>>> > > > >> > > take your legacy code and refactor instead of in
> someways
> >>>>> > starting
> >>>>> > > > >> over.
> >>>>> > > > >> > >
> >>>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
> >>>>> > something
> >>>>> > > > >> similar
> >>>>> > > > >> > > to
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> >
> >>>>> > > > >>
> >>>>> > > >
> >>>>> > >
> >>>>> >
> >>>>>
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> >>>>> > > > >> > > where it tracks what needs to get ported / what has been
> >>>>> ported.
> >>>>> > > > >> > >
> >>>>> > > > >> > > What are we going to support in the next version?
> >>>>> > > > >> > >
> >>>>> > > > >> > > Who is going to work on the next version?
> >>>>> > > > >> > >
> >>>>> > > > >> > > What would make the most sense and what would invigorate
> >>>>> the
> >>>>> > > > >> community to
> >>>>> > > > >> > > get involved more and lower the barrier to entry?
> >>>>> > > > >> > >
> >>>>> > > > >> > > I think those are the questions that would make a lot of
> >>>>> the
> >>>>> > > > decisions
> >>>>> > > > >> > for
> >>>>> > > > >> > > us so that we can get back to work on lucene.net.
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > >
> >>>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> >>>>> > > > marcoslimagon@gmail.com
> >>>>> > > > >> > > >wrote:
> >>>>> > > > >> > >
> >>>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
> >>>>> projects...
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> >>>>> > > > >> > > > https://github.com/apache/lucene.net points to the
> same
> >>>>> > > > repository?
> >>>>> > > > >> > > (This
> >>>>> > > > >> > > > is new for me, pretty good) Which of them do you
> >>>>> recommend
> >>>>> > (i'm
> >>>>> > > > used
> >>>>> > > > >> > with
> >>>>> > > > >> > > > SVN and its patterns).
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > I'm checking the subversion right now.
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is
> a
> >>>>> old
> >>>>> > > > branch,
> >>>>> > > > >> i`m
> >>>>> > > > >> > > not
> >>>>> > > > >> > > > sure about its current status.
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > Will we wipe the current solution from /trunk and
> start
> >>>>> a new
> >>>>> > > one?
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > Thanks,
> >>>>> > > > >> > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > 2013/6/6 mherndon michael <
> mherndon@michaelherndon.com>
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > > We may be forced to start with a clean/empty branch
> if
> >>>>> > people
> >>>>> > > > >> still
> >>>>> > > > >> > > want
> >>>>> > > > >> > > > to
> >>>>> > > > >> > > > > attempt supporting lucene.net for mobile devices,
> win
> >>>>> RT,
> >>>>> > > etc.
> >>>>> > > > >> The
> >>>>> > > > >> > are
> >>>>> > > > >> > > > > many
> >>>>> > > > >> > > > > classes that Lucene.net uses from the full framework
> >>>>> that
> >>>>> > > would
> >>>>> > > > >> not
> >>>>> > > > >> > be
> >>>>> > > > >> > > > > accessible in other versions of the .NET Framework.
> >>>>> It also
> >>>>> > > > might
> >>>>> > > > >> > > > require
> >>>>> > > > >> > > > > a design that differs even more from its parent
> >>>>> project.
> >>>>> > > > >> > > > >
> >>>>> > > > >> > > > > It might be wise to poll what users most desire in
> the
> >>>>> next
> >>>>> > > > >> version
> >>>>> > > > >> > > > through
> >>>>> > > > >> > > > > jira or user voice.
> >>>>> > > > >> > > > >
> >>>>> > > > >> > > > >
> >>>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> >>>>> > > > >> > itamar@code972.com
> >>>>> > > > >> > > > > >wrote:
> >>>>> > > > >> > > > >
> >>>>> > > > >> > > > > > inline
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> >>>>> > > > >> pirwin@feature23.com>
> >>>>> > > > >> > > > wrote:
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've
> been
> >>>>> a TFS
> >>>>> > > guy
> >>>>> > > > >> for
> >>>>> > > > >> > so
> >>>>> > > > >> > > > > long
> >>>>> > > > >> > > > > > > :-)
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
> >>>>> patches
> >>>>> > or
> >>>>> > > > >> > anything
> >>>>> > > > >> > > > to
> >>>>> > > > >> > > > > > the
> >>>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we
> will
> >>>>> > branch
> >>>>> > > > from
> >>>>> > > > >> > for
> >>>>> > > > >> > > 4x
> >>>>> > > > >> > > > > > dev.
> >>>>> > > > >> > > > > > > Correct?
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
> >>>>> anyone
> >>>>> > > will
> >>>>> > > > >> be
> >>>>> > > > >> > > > > > interested in that
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the
> deal
> >>>>> with
> >>>>> > > the
> >>>>> > > > >> > github
> >>>>> > > > >> > > > > sync?
> >>>>> > > > >> > > > > > > Who could diagnose that?
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the
> >>>>> apache
> >>>>> > repo
> >>>>> > > > for
> >>>>> > > > >> now
> >>>>> > > > >> > > > while
> >>>>> > > > >> > > > > > we get that sorted out.
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar
> Syn-Hershko
> >>>>> <
> >>>>> > > > >> > > > itamar@code972.com
> >>>>> > > > >> > > > > > > >wrote:
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it
> >>>>> then for
> >>>>> > > 3.x
> >>>>> > > > >> > > > > development.
> >>>>> > > > >> > > > > > > WRT
> >>>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on
> >>>>> whatever
> >>>>> > > branch.
> >>>>> > > > >> When
> >>>>> > > > >> > > you
> >>>>> > > > >> > > > > > send
> >>>>> > > > >> > > > > > > us
> >>>>> > > > >> > > > > > > > PRs we will merge either to master or to a
> >>>>> dedicated
> >>>>> > > repo.
> >>>>> > > > >> For
> >>>>> > > > >> > > now
> >>>>> > > > >> > > > it
> >>>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of
> git.
> >>>>> > > > >> > > > > > > >
> >>>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see
> >>>>> it on
> >>>>> > the
> >>>>> > > > >> apache
> >>>>> > > > >> > > > > servers
> >>>>> > > > >> > > > > > > > (github sync seems to be off)
> >>>>> > > > >> > > > > > > >
> >>>>> > > > >> > > > > > > >
> >>>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> >>>>> > > > >> > > pirwin@feature23.com>
> >>>>> > > > >> > > > > > > wrote:
> >>>>> > > > >> > > > > > > >
> >>>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on
> >>>>> 4.3
> >>>>> > > version
> >>>>> > > > >> of
> >>>>> > > > >> > the
> >>>>> > > > >> > > > > > > Analysis
> >>>>> > > > >> > > > > > > > > namespace.
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > > Not sure the checkout command is what you
> >>>>> intended
> >>>>> > --
> >>>>> > > > you
> >>>>> > > > >> > might
> >>>>> > > > >> > > > > have
> >>>>> > > > >> > > > > > > > meant
> >>>>> > > > >> > > > > > > > > trunk instead of master, and that would
> create
> >>>>> a new
> >>>>> > > > "3x"
> >>>>> > > > >> > > branch,
> >>>>> > > > >> > > > > > when
> >>>>> > > > >> > > > > > > > > there's already a "branch_3x" and that
> would be
> >>>>> > > > >> misnamed...
> >>>>> > > > >> > so
> >>>>> > > > >> > > > > maybe
> >>>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
> >>>>> aiming
> >>>>> > for
> >>>>> > > > >> lucene
> >>>>> > > > >> > > > 4.3.x
> >>>>> > > > >> > > > > > > > > compatibility?
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
> >>>>> > upstream
> >>>>> > > > >> want to
> >>>>> > > > >> > > > > create
> >>>>> > > > >> > > > > > > the
> >>>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're
> >>>>> not all
> >>>>> > > > >> trying to
> >>>>> > > > >> > > > > create
> >>>>> > > > >> > > > > > > them
> >>>>> > > > >> > > > > > > > > and dealing with a merge?
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > > Paul
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
> >>>>> Syn-Hershko <
> >>>>> > > > >> > > > > > itamar@code972.com
> >>>>> > > > >> > > > > > > > > >wrote:
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > > > > Unless people here have a specific reason
> to
> >>>>> use
> >>>>> > > > 3.6.2 I
> >>>>> > > > >> > > would
> >>>>> > > > >> > > > > > highly
> >>>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
> >>>>> towards v4
> >>>>> > > > >> > otherwise
> >>>>> > > > >> > > we
> >>>>> > > > >> > > > > > will
> >>>>> > > > >> > > > > > > > > never
> >>>>> > > > >> > > > > > > > > > make it...
> >>>>> > > > >> > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > Fork the repo from apache servers or
> github
> >>>>> (same
> >>>>> > > > repo,
> >>>>> > > > >> > > > different
> >>>>> > > > >> > > > > > > > > remotes)
> >>>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
> >>>>> should
> >>>>> > > work
> >>>>> > > > >> > > > > > > > > >
> >>>>> > > > >> > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul
> Irwin <
> >>>>> > > > >> > > > > pirwin@feature23.com>
> >>>>> > > > >> > > > > > > > > wrote:
> >>>>> > > > >> > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > Itamar,
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > I agree that from scratch is not the
> best
> >>>>> way to
> >>>>> > > do
> >>>>> > > > >> it, I
> >>>>> > > > >> > > > just
> >>>>> > > > >> > > > > > > > thought
> >>>>> > > > >> > > > > > > > > > that
> >>>>> > > > >> > > > > > > > > > > was the "decision" that was made from
> the
> >>>>> > > discussion
> >>>>> > > > >> > > > previously
> >>>>> > > > >> > > > > > for
> >>>>> > > > >> > > > > > > > the
> >>>>> > > > >> > > > > > > > > > 4.x
> >>>>> > > > >> > > > > > > > > > > work. An incremental approach will be
> much
> >>>>> > better.
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
> >>>>> branch on
> >>>>> > > my
> >>>>> > > > >> fork
> >>>>> > > > >> > > and
> >>>>> > > > >> > > > > will
> >>>>> > > > >> > > > > > > > begin
> >>>>> > > > >> > > > > > > > > > > working on bringing the Analysis
> namespace
> >>>>> up to
> >>>>> > > > >> speed to
> >>>>> > > > >> > > > > 3.6.2.
> >>>>> > > > >> > > > > > If
> >>>>> > > > >> > > > > > > > > > anyone
> >>>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts
> once
> >>>>> I'm
> >>>>> > > done,
> >>>>> > > > >> have
> >>>>> > > > >> > at
> >>>>> > > > >> > > > it.
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
> >>>>> branch_3x
> >>>>> > > > branch,
> >>>>> > > > >> > > please
> >>>>> > > > >> > > > > let
> >>>>> > > > >> > > > > > > me
> >>>>> > > > >> > > > > > > > > know
> >>>>> > > > >> > > > > > > > > > > what I should have branched from
> (trunk?)
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > Paul
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
> >>>>> > > Syn-Hershko <
> >>>>> > > > >> > > > > > > > itamar@code972.com
> >>>>> > > > >> > > > > > > > > > > >wrote:
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
> >>>>> again :)
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
> >>>>> know
> >>>>> > what
> >>>>> > > > it
> >>>>> > > > >> > would
> >>>>> > > > >> > > > > take
> >>>>> > > > >> > > > > > > > until
> >>>>> > > > >> > > > > > > > > > they
> >>>>> > > > >> > > > > > > > > > > > have deep dived into the work, and
> even
> >>>>> then
> >>>>> > > > >> decisions
> >>>>> > > > >> > > > could
> >>>>> > > > >> > > > > > and
> >>>>> > > > >> > > > > > > > will
> >>>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
> >>>>> > starting
> >>>>> > > > from
> >>>>> > > > >> > > > scratch,
> >>>>> > > > >> > > > > > > > > although
> >>>>> > > > >> > > > > > > > > > I
> >>>>> > > > >> > > > > > > > > > > do
> >>>>> > > > >> > > > > > > > > > > > think a lot in the current structure
> >>>>> should
> >>>>> > > > change,
> >>>>> > > > >> but
> >>>>> > > > >> > > its
> >>>>> > > > >> > > > > > going
> >>>>> > > > >> > > > > > > > to
> >>>>> > > > >> > > > > > > > > be
> >>>>> > > > >> > > > > > > > > > > > much easier to change it in place,
> >>>>> refactoring
> >>>>> > > > where
> >>>>> > > > >> > > > needed,
> >>>>> > > > >> > > > > > than
> >>>>> > > > >> > > > > > > > > > > starting
> >>>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this
> off I
> >>>>> > > > personally
> >>>>> > > > >> > will
> >>>>> > > > >> > > > be
> >>>>> > > > >> > > > > > > happy
> >>>>> > > > >> > > > > > > > > with
> >>>>> > > > >> > > > > > > > > > > you
> >>>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
> >>>>> porting
> >>>>> > > it,
> >>>>> > > > >> its
> >>>>> > > > >> > > > pretty
> >>>>> > > > >> > > > > > > much
> >>>>> > > > >> > > > > > > > > self
> >>>>> > > > >> > > > > > > > > > > > contained.
> >>>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that
> on
> >>>>> a fork
> >>>>> > > and
> >>>>> > > > >> send
> >>>>> > > > >> > > us
> >>>>> > > > >> > > > > PRs,
> >>>>> > > > >> > > > > > > its
> >>>>> > > > >> > > > > > > > > > much
> >>>>> > > > >> > > > > > > > > > > > more straight forward than the v4
> upgrade
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
> >>>>> fastest
> >>>>> > > way
> >>>>> > > > >> to do
> >>>>> > > > >> > > > this,
> >>>>> > > > >> > > > > > we
> >>>>> > > > >> > > > > > > > can
> >>>>> > > > >> > > > > > > > > > then
> >>>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and
> optimizing
> >>>>> using
> >>>>> > > > .NET
> >>>>> > > > >> > > > > constructs.
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
> >>>>> create a
> >>>>> > > > branch
> >>>>> > > > >> out
> >>>>> > > > >> > > of
> >>>>> > > > >> > > > > the
> >>>>> > > > >> > > > > > > > > current
> >>>>> > > > >> > > > > > > > > > > git
> >>>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and
> start
> >>>>> > > working
> >>>>> > > > on
> >>>>> > > > >> > > master
> >>>>> > > > >> > > > > > > > towards a
> >>>>> > > > >> > > > > > > > > > 4.3
> >>>>> > > > >> > > > > > > > > > > > compatible version. The actual port
> >>>>> should be
> >>>>> > > > using
> >>>>> > > > >> a
> >>>>> > > > >> > > > process
> >>>>> > > > >> > > > > > > that
> >>>>> > > > >> > > > > > > > > > > ensures
> >>>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
> >>>>> tests,
> >>>>> > > and
> >>>>> > > > >> that
> >>>>> > > > >> > > > those
> >>>>> > > > >> > > > > > > tests
> >>>>> > > > >> > > > > > > > > > pass -
> >>>>> > > > >> > > > > > > > > > > > but I'm against committing any Java
> code
> >>>>> to
> >>>>> > our
> >>>>> > > > >> > > > repositories.
> >>>>> > > > >> > > > > > The
> >>>>> > > > >> > > > > > > > > > process
> >>>>> > > > >> > > > > > > > > > > > should probably be working on classes
> in
> >>>>> some
> >>>>> > > > order
> >>>>> > > > >> > > > > > > > (alphabetically,
> >>>>> > > > >> > > > > > > > > or
> >>>>> > > > >> > > > > > > > > > > > core classes first) and getting each
> >>>>> class to
> >>>>> > > > >> compile
> >>>>> > > > >> > > > before
> >>>>> > > > >> > > > > > > moving
> >>>>> > > > >> > > > > > > > > > > > forward. I don't mind about the
> project
> >>>>> not
> >>>>> > > being
> >>>>> > > > >> > > > compilable
> >>>>> > > > >> > > > > > for
> >>>>> > > > >> > > > > > > a
> >>>>> > > > >> > > > > > > > > > month
> >>>>> > > > >> > > > > > > > > > > or
> >>>>> > > > >> > > > > > > > > > > > two.
> >>>>> > > > >> > > > > > > > > > > > Once this is done a process of
> >>>>> .NETifying and
> >>>>> > > > >> proofing
> >>>>> > > > >> > > the
> >>>>> > > > >> > > > > code
> >>>>> > > > >> > > > > > > can
> >>>>> > > > >> > > > > > > > > be
> >>>>> > > > >> > > > > > > > > > > > started, at which point we will
> already
> >>>>> have a
> >>>>> > > > >> working
> >>>>> > > > >> > v4
> >>>>> > > > >> > > > > > version
> >>>>> > > > >> > > > > > > > so
> >>>>> > > > >> > > > > > > > > it
> >>>>> > > > >> > > > > > > > > > > > will be easier to keep up with the
> Java
> >>>>> > project.
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
> >>>>> test
> >>>>> > > suite
> >>>>> > > > so
> >>>>> > > > >> > > tests
> >>>>> > > > >> > > > > > could
> >>>>> > > > >> > > > > > > > more
> >>>>> > > > >> > > > > > > > > > or
> >>>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
> >>>>> implementing
> >>>>> > > > >> Java-like
> >>>>> > > > >> > > > > > > assertEquals
> >>>>> > > > >> > > > > > > > > > > methods
> >>>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
> >>>>> work
> >>>>> > with
> >>>>> > > > >> than
> >>>>> > > > >> > > > > NUnit). I
> >>>>> > > > >> > > > > > > > > already
> >>>>> > > > >> > > > > > > > > > > did
> >>>>> > > > >> > > > > > > > > > > > some work there but there's still a
> lot
> >>>>> to do.
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
> >>>>> myself at
> >>>>> > > this
> >>>>> > > > >> > point,
> >>>>> > > > >> > > > > but I
> >>>>> > > > >> > > > > > > > > should
> >>>>> > > > >> > > > > > > > > > be
> >>>>> > > > >> > > > > > > > > > > > back in business in August, at which
> >>>>> point I
> >>>>> > can
> >>>>> > > > >> > dedicate
> >>>>> > > > >> > > > > > several
> >>>>> > > > >> > > > > > > > > > hours a
> >>>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to
> watch
> >>>>> > closely
> >>>>> > > > and
> >>>>> > > > >> > even
> >>>>> > > > >> > > > > > > coordinate
> >>>>> > > > >> > > > > > > > > the
> >>>>> > > > >> > > > > > > > > > > > work to some extent.
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM,
> Marcos
> >>>>> Lima <
> >>>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
> >>>>> > > > >> > > > > > > > > > > > >wrote:
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this
> is a
> >>>>> kick
> >>>>> > > > start
> >>>>> > > > >> > =). I
> >>>>> > > > >> > > > > > haven't
> >>>>> > > > >> > > > > > > > > > > > contributed
> >>>>> > > > >> > > > > > > > > > > > > anything
> >>>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you
> all
> >>>>> to get
> >>>>> > > > this
> >>>>> > > > >> job
> >>>>> > > > >> > > > done.
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
> >>>>> Prescott.
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > I know that there is a high
> commitment
> >>>>> for
> >>>>> > > keep
> >>>>> > > > >> the
> >>>>> > > > >> > > > > > > > > > retrocompatibility
> >>>>> > > > >> > > > > > > > > > > on
> >>>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets
> big
> >>>>> > changes
> >>>>> > > > >> every
> >>>>> > > > >> > > > > release?
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a
> stable
> >>>>> > version
> >>>>> > > > >> from a
> >>>>> > > > >> > > > > Lucene
> >>>>> > > > >> > > > > > > > > version,
> >>>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only
> >>>>> minor
> >>>>> > > changes
> >>>>> > > > >> > every
> >>>>> > > > >> > > > > stable
> >>>>> > > > >> > > > > > > > > release
> >>>>> > > > >> > > > > > > > > > > (or
> >>>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we
> could
> >>>>> > > compare
> >>>>> > > > >> the
> >>>>> > > > >> > > > > versions,
> >>>>> > > > >> > > > > > > > check
> >>>>> > > > >> > > > > > > > > > the
> >>>>> > > > >> > > > > > > > > > > > > differences and bring them to
> >>>>> Lucene.Net.
> >>>>> > > > Again, I
> >>>>> > > > >> > > > haven't
> >>>>> > > > >> > > > > > > > > > contributed
> >>>>> > > > >> > > > > > > > > > > > with
> >>>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is
> (just an
> >>>>> > idea).
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > What's your approach for implement
> >>>>> simple
> >>>>> > > > >> performance
> >>>>> > > > >> > > > > > > > improvements
> >>>>> > > > >> > > > > > > > > > > > (without
> >>>>> > > > >> > > > > > > > > > > > > adding references or changing
> methods
> >>>>> > > > signatures)?
> >>>>> > > > >> > Does
> >>>>> > > > >> > > > it
> >>>>> > > > >> > > > > > > could
> >>>>> > > > >> > > > > > > > be
> >>>>> > > > >> > > > > > > > > > > done,
> >>>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
> >>>>> pirwin@feature23.com>
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > This is just an "outsider"
> >>>>> suggestion as I
> >>>>> > > > >> haven't
> >>>>> > > > >> > > > > > > contributed
> >>>>> > > > >> > > > > > > > > > > anything
> >>>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely
> help
> >>>>> with
> >>>>> > > the
> >>>>> > > > >> 4.x
> >>>>> > > > >> > > work
> >>>>> > > > >> > > > > as I
> >>>>> > > > >> > > > > > > > have
> >>>>> > > > >> > > > > > > > > a
> >>>>> > > > >> > > > > > > > > > > > vested
> >>>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
> >>>>> completed. I
> >>>>> > > think
> >>>>> > > > >> > there
> >>>>> > > > >> > > > > should
> >>>>> > > > >> > > > > > > be
> >>>>> > > > >> > > > > > > > > one
> >>>>> > > > >> > > > > > > > > > > > person
> >>>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
> >>>>> > structure
> >>>>> > > > and
> >>>>> > > > >> > > > workflow
> >>>>> > > > >> > > > > > will
> >>>>> > > > >> > > > > > > > > look
> >>>>> > > > >> > > > > > > > > > > like
> >>>>> > > > >> > > > > > > > > > > > > to
> >>>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is
> >>>>> going to
> >>>>> > be
> >>>>> > > > >> > starting
> >>>>> > > > >> > > > from
> >>>>> > > > >> > > > > > > > scratch
> >>>>> > > > >> > > > > > > > > > as
> >>>>> > > > >> > > > > > > > > > > a
> >>>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set
> >>>>> up the
> >>>>> > > > >> project,
> >>>>> > > > >> > > get
> >>>>> > > > >> > > > > > > > everything
> >>>>> > > > >> > > > > > > > > > > going
> >>>>> > > > >> > > > > > > > > > > > > in
> >>>>> > > > >> > > > > > > > > > > > > > source control, create the folder
> >>>>> > structure,
> >>>>> > > > >> maybe
> >>>>> > > > >> > > stub
> >>>>> > > > >> > > > > out
> >>>>> > > > >> > > > > > > > some
> >>>>> > > > >> > > > > > > > > > > > classes,
> >>>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
> >>>>> anyone
> >>>>> > > > >> interested
> >>>>> > > > >> > > in
> >>>>> > > > >> > > > > > > > > > contributing,
> >>>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the
> java
> >>>>> code
> >>>>> > in
> >>>>> > > > >> there
> >>>>> > > > >> > so
> >>>>> > > > >> > > > > it's
> >>>>> > > > >> > > > > > > easy
> >>>>> > > > >> > > > > > > > > to
> >>>>> > > > >> > > > > > > > > > > > > > reference.
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > Again, I can work on
> >>>>> Lucene.Net.Documents,
> >>>>> > > > >> > > > > > > Lucene.Net.Analysis,
> >>>>> > > > >> > > > > > > > > or
> >>>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
> >>>>> those
> >>>>> > are
> >>>>> > > > >> just
> >>>>> > > > >> > the
> >>>>> > > > >> > > > > ones
> >>>>> > > > >> > > > > > > I'm
> >>>>> > > > >> > > > > > > > > most
> >>>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
> >>>>> Tell me
> >>>>> > > what
> >>>>> > > > >> to
> >>>>> > > > >> > do
> >>>>> > > > >> > > > and
> >>>>> > > > >> > > > > > I'll
> >>>>> > > > >> > > > > > > > get
> >>>>> > > > >> > > > > > > > > > > > started
> >>>>> > > > >> > > > > > > > > > > > > > on my fork.
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > Paul Irwin
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
> >>>>> Prescott
> >>>>> > > > Nasser
> >>>>> > > > >> <
> >>>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
> >>>>> > > > >> > > > > > > > > > > > > > >wrote:
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > > > Hey guys -
> >>>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
> >>>>> while. We
> >>>>> > > > have a
> >>>>> > > > >> > > board
> >>>>> > > > >> > > > > > report
> >>>>> > > > >> > > > > > > > due
> >>>>> > > > >> > > > > > > > > > > soon
> >>>>> > > > >> > > > > > > > > > > > -
> >>>>> > > > >> > > > > > > > > > > > > I
> >>>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise
> >>>>> them
> >>>>> > that
> >>>>> > > we
> >>>>> > > > >> seem
> >>>>> > > > >> > > to
> >>>>> > > > >> > > > > have
> >>>>> > > > >> > > > > > > > > stalled
> >>>>> > > > >> > > > > > > > > > > > > > somewhat.
> >>>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging
> items
> >>>>> out of
> >>>>> > > of
> >>>>> > > > >> jira
> >>>>> > > > >> > > and
> >>>>> > > > >> > > > > have
> >>>>> > > > >> > > > > > > > been
> >>>>> > > > >> > > > > > > > > > > > > responsive
> >>>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
> >>>>> > > questions,
> >>>>> > > > >> but I
> >>>>> > > > >> > > > don't
> >>>>> > > > >> > > > > > > think
> >>>>> > > > >> > > > > > > > > > we've
> >>>>> > > > >> > > > > > > > > > > > > done
> >>>>> > > > >> > > > > > > > > > > > > > > anything to move forward with
> 4.0.
> >>>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try*
> and
> >>>>> > start
> >>>>> > > us
> >>>>> > > > >> back
> >>>>> > > > >> > > up
> >>>>> > > > >> > > > > > moving
> >>>>> > > > >> > > > > > > > > > > forward.
> >>>>> > > > >> > > > > > > > > > > > > What
> >>>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish
> >>>>> this? If
> >>>>> > we
> >>>>> > > > took
> >>>>> > > > >> > the
> >>>>> > > > >> > > > java
> >>>>> > > > >> > > > > > > > lucene
> >>>>> > > > >> > > > > > > > > > 4.0
> >>>>> > > > >> > > > > > > > > > > > code
> >>>>> > > > >> > > > > > > > > > > > > > and
> >>>>> > > > >> > > > > > > > > > > > > > > committed that java to our
> branch
> >>>>> and
> >>>>> > then
> >>>>> > > > >> just
> >>>>> > > > >> > let
> >>>>> > > > >> > > > > > people
> >>>>> > > > >> > > > > > > > pull
> >>>>> > > > >> > > > > > > > > > > that
> >>>>> > > > >> > > > > > > > > > > > > down
> >>>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying
> is
> >>>>> that
> >>>>> > one
> >>>>> > > > >> way to
> >>>>> > > > >> > > > maybe
> >>>>> > > > >> > > > > > > make
> >>>>> > > > >> > > > > > > > > some
> >>>>> > > > >> > > > > > > > > > > > > forward
> >>>>> > > > >> > > > > > > > > > > > > > > progress?
> >>>>> > > > >> > > > > > > > > > > > > > > ~P
> >>>>> > > > >> > > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > > > --
> >>>>> > > > >> > > > > > > > > > > > > --
> >>>>> > > > >> > > > > > > > > > > > > Marcos Lima
> >>>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
> >>>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
> >>>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> >>>>> > > > >> > > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > > >
> >>>>> > > > >> > > > > > > > > >
> >>>>> > > > >> > > > > > > > >
> >>>>> > > > >> > > > > > > >
> >>>>> > > > >> > > > > > >
> >>>>> > > > >> > > > > >
> >>>>> > > > >> > > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > >
> >>>>> > > > >> > > > --
> >>>>> > > > >> > > > --
> >>>>> > > > >> > > > Marcos Lima
> >>>>> > > > >> > > > Software Developer/Tech Lead
> >>>>> > > > >> > > > marcoslimagon@gmail.com
> >>>>> > > > >> > > > tel: +55 (19) 9798-9335
> >>>>> > > > >> > > >
> >>>>> > > > >> > >
> >>>>> > > > >> >
> >>>>> > > > >>
> >>>>> > > > >>
> >>>>> > > > >>
> >>>>> > > > >> --
> >>>>> > > > >> --
> >>>>> > > > >> Marcos Lima
> >>>>> > > > >> Software Developer/Tech Lead
> >>>>> > > > >> marcoslimagon@gmail.com
> >>>>> > > > >> tel: +55 (19) 9798-9335
> >>>>> > > > >>
> >>>>> > > > >
> >>>>> > > > >
> >>>>> > > >
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>>>
> >>>
> >>
>
Re: Lucene 4.0
Posted by 许鹏 <xu...@188.com>.
Hi Paul,
I am a developer from China, I currently using Solr 4.3.0 to construct our own
data system for search and analysis. I am very interested in the work that porting
Lucene java 4.3.1, and I want to join this team to work on this. But I have never
been involved in open source projects, Can you give me some suggestion to join
the team and start contributing.
Additional, I am not good at English writing, but reading is ok. Also, I am now learning English,
I believe it will be more smooth communication.
Athrun Saga
8/9/2013
At 2013-08-09 03:31:47,"Paul Irwin" <pi...@feature23.com> wrote:
>Is this mailing list dead?! If anyone is interested in releasing an
>up-to-date build of Lucene.net, please write back! If you didn't read my
>other messages, I have Lucene.net Core working with Lucene java 4.3.1
>compatibility thanks to the help of my colleagues. We just need to round
>out the contrib modules, unit tests, and documentation as a community and
>we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>was packaged in December 2010!
>
>I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>(where they now live in Lucene java, they were moved from core) and their
>associated filters and tokenizers. I've briefly tested each and they seem
>to work correctly. I've purposefully "Exclude[d] from Project" the other
>language analyzers until we can forward-port them. So now the Analyzers DLL
>compiles with those analyzers only. Also, I fixed the bug that was causing
>NumericRangeQuery to not work.
>
>Next on my list is the QueryParsers contrib library (QueryParser was moved
>out of Lucene java core) so that, combined with StandardAnalyzer, we can
>test a pretty common real-world use case (the prototypical "hello lucene"
>tutorial). After that, it might be worth forward-porting what we have so
>far to 4.4 and use that as the latest point to finish out the port. The
>changes shouldn't be too dramatic to core from what I can tell.
>
>My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
>I'll keep updating as I go, but if anyone wants to jump in, there's not a
>better time than now...
>
>
>
>On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> I made a dumb mistake... I have worked with StandardAnalyzer so long that
>> I forgot that KeywordAnalyzer is not what I needed to be using, I needed to
>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>
>> Now it works after re-indexing with a quick, dirty implementation of
>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on to
>> find out why NumericRangeQuery isn't working.
>>
>> Sorry for the blast of emails, but I wanted to prevent people from
>> spending time hunting down my mistake!
>>
>>
>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>>> byte being signed is a pain.
>>>
>>> Now there's no exception doing a TermQuery, but I also don't get any
>>> results. It doesn't find any terms when scanning for them. I also tried a
>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>>> didn't find any results that way either. So right now only
>>> MatchAllDocsQuery seems to work.
>>>
>>> If anyone would like to do a Google Hangout or anything sometime to look
>>> into it, let me know.
>>>
>>>
>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com> wrote:
>>>
>>>> I realized after I sent that email last night that I could do as you
>>>> described. When you've been debugging through CorruptedIndexExceptions, you
>>>> get a little bit of tunnel vision... haha
>>>>
>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
>>>> the matching documents prints the fields to the console, so it's loading in
>>>> the stored fields data correctly.
>>>>
>>>> I tried doing a TermQuery and now I get a "read past EOF" exception that
>>>> I can't figure out. There's a whole bunch of buffered byte array operations
>>>> going on and I can't determine where the issue came from. I'll keep
>>>> looking, but if someone could grab my fork/branch and help me look that
>>>> would be great. Here's example index writing and then reading code (also
>>>> included is a quick port of KeywordAnalyzer):
>>>> https://gist.github.com/anonymous/6174164
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <it...@code972.com>wrote:
>>>>
>>>>> Great
>>>>>
>>>>> You can build you Query objects on your own to execute a search, you
>>>>> don't
>>>>> actually have to use QueryParser for that
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> > Hey all, sorry it's been a little while, but I wanted to let you know
>>>>> that
>>>>> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
>>>>> > Lucene.net core building and able to write a simple index in Lucene
>>>>> 4.2
>>>>> > codec and read in things like the number of documents and whatnot.
>>>>> Since
>>>>> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
>>>>> > haven't ported that yet so I haven't done a real search, and I only
>>>>> built
>>>>> > the index using a quick port of KeywordAnalyzer which all those
>>>>> analyzers
>>>>> > have also moved to another module. But this is definitely good
>>>>> progress and
>>>>> > should be a launch point for finishing a 4.3/4.4 port.
>>>>> >
>>>>> > You can see my fork/branch here:
>>>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
>>>>> like I
>>>>> > said, only core builds now, no modules/tests build, so only open the
>>>>> > Lucene.Net.Core.sln)
>>>>> >
>>>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
>>>>> the
>>>>> > community into finishing the 4.3/4.4 port. Let me know if you have any
>>>>> > questions, thanks!
>>>>> >
>>>>> >
>>>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>>>> itamar@code972.com
>>>>> > >wrote:
>>>>> >
>>>>> > > Paul, that's awesome. I will need some more time to go over this
>>>>> thread
>>>>> > and
>>>>> > > your work to give actual feedback, SUPER busy at the moment
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
>>>>> > wrote:
>>>>> > >
>>>>> > > > All,
>>>>> > > >
>>>>> > > > My colleagues and I have made good progress on porting Lucene
>>>>> 4.3's
>>>>> > core
>>>>> > > > library before, during, and after the hackathon last week. We now
>>>>> only
>>>>> > > have
>>>>> > > > some remaining items in Search, Index, and Codecs namespaces
>>>>> (plus a
>>>>> > few
>>>>> > > > other minor ones here and there). I expect to be done by the end
>>>>> of the
>>>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
>>>>> Packed),
>>>>> > > and
>>>>> > > > the root Codecs and Codecs.PerField namespaces are all now "done".
>>>>> > > >
>>>>> > > > Again, my goal is to only get a buildable, experimental build of
>>>>> > > Lucene.net
>>>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>>>>> porting
>>>>> > > new
>>>>> > > > javadoc comments or unit tests right now, due to the vast amount
>>>>> of
>>>>> > code
>>>>> > > > that needs to be written just to get it to compile. If this work
>>>>> ends
>>>>> > up
>>>>> > > > becoming a pull request, great, otherwise it should help
>>>>> accelerate a
>>>>> > > port
>>>>> > > > of 4.3.x since the bulk of the work on core will already be done
>>>>> and
>>>>> > > > contributors can use it as a reference. And again, we're taking
>>>>> the
>>>>> > > > pragmatic approach of porting class-by-class,
>>>>> namespace-by-namespace,
>>>>> > > with
>>>>> > > > the understanding that until we're done the project won't build.
>>>>> > > >
>>>>> > > > Once complete, I also will work on updating the Analyzers contrib
>>>>> > module
>>>>> > > > and porting the QueryParsers contrib module, which I feel should
>>>>> be
>>>>> > > > included in the core NuGet package for Lucene.net as the core
>>>>> library
>>>>> > is
>>>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
>>>>> without
>>>>> > > them.
>>>>> > > > You can check out the code on my fork/branch here:
>>>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>> > > >
>>>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
>>>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
>>>>> For the
>>>>> > > MMap
>>>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
>>>>> > > > MemoryMappedFile support which should emulate the Java nio stuff
>>>>> pretty
>>>>> > > > well, but required some creative shuffling of the code to make it
>>>>> work
>>>>> > > due
>>>>> > > > to lifecycle management.
>>>>> > > >
>>>>> > > > I'll update again this weekend or next week, when we should have
>>>>> > wrapped
>>>>> > > up
>>>>> > > > most of the main hacking on porting the core code.
>>>>> > > >
>>>>> > > > Paul
>>>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pirwin@feature23.com
>>>>> >
>>>>> > > wrote:
>>>>> > > >
>>>>> > > > > Marcos,
>>>>> > > > >
>>>>> > > > > That would be helpful. As far as I can tell, the 3.0 java code
>>>>> is
>>>>> > only
>>>>> > > on
>>>>> > > > > SVN here, before the lucene and solr projects were bundled
>>>>> together:
>>>>> > > > >
>>>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>>>>> > > > >
>>>>> > > > > The SVN for 4.3 java is here:
>>>>> > > > >
>>>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>>>>> > > > > And the GitHub for 4.3 java is here:
>>>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>>>>> > > > >
>>>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
>>>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>>>>> > > > >
>>>>> > > > > My fork is the "upstream" fork for my team members, and i'm
>>>>> remote
>>>>> > > > merging
>>>>> > > > > their changes in from their forks while they fetch/merge from
>>>>> mine to
>>>>> > > get
>>>>> > > > > everyone else's changes, rather than using pull requests. James
>>>>> and I
>>>>> > > > have
>>>>> > > > > been working the past few days on the Util namespace ahead of
>>>>> > tonight's
>>>>> > > > > hackathon since that namespace is in common with the rest of the
>>>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
>>>>> > hacking
>>>>> > > on
>>>>> > > > > porting 4.3, each with a different namespace or part of a
>>>>> namespace.
>>>>> > > > Since
>>>>> > > > > we're going class-by-class, namespace-by-namespace, the project
>>>>> does
>>>>> > > not
>>>>> > > > > build as it is. Once we finish doing a translation of each
>>>>> file, then
>>>>> > > > we'll
>>>>> > > > > hammer out any remaining issues and get it to build again. I'm
>>>>> hoping
>>>>> > > > that
>>>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
>>>>> > > > >
>>>>> > > > > But one thing to keep in mind is it looks like much
>>>>> functionality has
>>>>> > > > been
>>>>> > > > > moved out of core into the contrib modules, especially around
>>>>> > analysis,
>>>>> > > > for
>>>>> > > > > 4.0+. For example, there are no built-in analyzers in core
>>>>> anymore.
>>>>> > So
>>>>> > > > when
>>>>> > > > > this is all done, we may want to include at least the analysis
>>>>> > contrib
>>>>> > > > > module in with the standard core NuGet package, because
>>>>> otherwise
>>>>> > it's
>>>>> > > > > practically useless unless you roll your own analyzer.
>>>>> > > > >
>>>>> > > > > Paul
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>>>>> > marcoslimagon@gmail.com
>>>>> > > > >wrote:
>>>>> > > > >
>>>>> > > > >> Hi everyone!
>>>>> > > > >>
>>>>> > > > >> Does someone know where can I find the 3.0.3 release from
>>>>> > > Lucene(java)?
>>>>> > > > >>
>>>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
>>>>> 4.3.0 and
>>>>> > > > make
>>>>> > > > >> the diff between then and get all changes between releases... I
>>>>> > gonna
>>>>> > > > >> publish it here soon. (If you think there is another important
>>>>> > > release,
>>>>> > > > >> let
>>>>> > > > >> me know)
>>>>> > > > >>
>>>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry)
>>>>> with
>>>>> > 4.3.0
>>>>> > > > >> port
>>>>> > > > >> for .Net on github (last email)?
>>>>> > > > >>
>>>>> > > > >> See you,
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>>>> > > > >>
>>>>> > > > >> > Thanks for the discussion points, Michael.
>>>>> > > > >> >
>>>>> > > > >> > I would vote for not worrying about trying to achieve
>>>>> portable
>>>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+
>>>>> is
>>>>> > > > >> completed.
>>>>> > > > >> > Otherwise it may delay the project and stall it further.
>>>>> That's
>>>>> > just
>>>>> > > > my
>>>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
>>>>> > > > >> >
>>>>> > > > >> > I have started porting the changes from the core library
>>>>> (from the
>>>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
>>>>> separate
>>>>> > > > branch.
>>>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
>>>>> port
>>>>> > > until
>>>>> > > > >> > there's changes to pull from upstream to work from. Also due
>>>>> to my
>>>>> > > > time
>>>>> > > > >> > constraints, I am not fully documenting new methods that I'm
>>>>> > adding.
>>>>> > > > >> But if
>>>>> > > > >> > anyone wants to pull/copy/reference my changes while porting,
>>>>> > that's
>>>>> > > > >> > awesome. My branch currently does not build as I'm primarily
>>>>> going
>>>>> > > > >> > class-by-class, starting with the util namespace. Once we
>>>>> get the
>>>>> > > ball
>>>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
>>>>> join
>>>>> > in.
>>>>> > > > But
>>>>> > > > >> > hopefully my work will be useful to someone, if not as a pull
>>>>> > > request
>>>>> > > > >> then
>>>>> > > > >> > as a reference. I'm also going to be holding a hackathon
>>>>> this week
>>>>> > > > with
>>>>> > > > >> my
>>>>> > > > >> > colleagues where we're all going to work on the port. I'm
>>>>> > comparing
>>>>> > > > >> files
>>>>> > > > >> > and making changes as necessary, rather than starting from
>>>>> > scratch.
>>>>> > > My
>>>>> > > > >> > repo/branch is here:
>>>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>> > > > >> >
>>>>> > > > >> > Paul
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>>>>> > > > >> > mherndon@michaelherndon.com> wrote:
>>>>> > > > >> >
>>>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
>>>>> apache
>>>>> > > > >> > maintains.
>>>>> > > > >> > >
>>>>> > > > >> > > The was some work at one time to move the official svn
>>>>> > repository
>>>>> > > to
>>>>> > > > >> > start
>>>>> > > > >> > > using git one instead. Was that actually finalized or not?
>>>>> > > > >> > >
>>>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to
>>>>> see
>>>>> > > what
>>>>> > > > >> kind
>>>>> > > > >> > of
>>>>> > > > >> > > work was involved using a portable libraries project. Some
>>>>> of it
>>>>> > > can
>>>>> > > > >> > still
>>>>> > > > >> > > be used but will need to be validated against the current
>>>>> > version
>>>>> > > of
>>>>> > > > >> > Java's
>>>>> > > > >> > > Lucene. It was also using .net 4.
>>>>> > > > >> > >
>>>>> > > > >> > > clean branch vs current. Its going to depend on what we
>>>>> > > support.
>>>>> > > > >> If
>>>>> > > > >> > you
>>>>> > > > >> > > support windows mobile 8, win RT, then the current code in
>>>>> trunk
>>>>> > > > will
>>>>> > > > >> not
>>>>> > > > >> > > compile against those versions of the framework which
>>>>> would a
>>>>> > > > >> frustrating
>>>>> > > > >> > > starting point, then you couldn't even run tests, which
>>>>> would
>>>>> > make
>>>>> > > > >> taking
>>>>> > > > >> > > patches very difficult. Supporting those can almost mean
>>>>> larger
>>>>> > > > gaps
>>>>> > > > >> in
>>>>> > > > >> > > design between Lucene.Net and its parent project.
>>>>> > > > >> > >
>>>>> > > > >> > > Also the structure has changed significantly between the
>>>>> > branches
>>>>> > > > and
>>>>> > > > >> > the
>>>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6,
>>>>> and
>>>>> > > seems
>>>>> > > > >> > > significantly different. That doesn't mean you can't
>>>>> cherry
>>>>> > pick
>>>>> > > > >> stuff
>>>>> > > > >> > > from the other tags/branches that would still work as is.
>>>>> A
>>>>> > clean
>>>>> > > > >> branch
>>>>> > > > >> > > would also make it easier to get our build / tool chain in
>>>>> order
>>>>> > > as
>>>>> > > > >> you
>>>>> > > > >> > can
>>>>> > > > >> > > then do them incrementally versus having to do all the
>>>>> stuff
>>>>> > that
>>>>> > > I
>>>>> > > > >> did
>>>>> > > > >> > for
>>>>> > > > >> > > the 3x branch which saps energy and desire to code. It
>>>>> could
>>>>> > > also
>>>>> > > > >> make
>>>>> > > > >> > it
>>>>> > > > >> > > easier to see which classes have been ported or not.
>>>>> > > > >> > >
>>>>> > > > >> > > The major downside to a clean branch is extra work it
>>>>> requires
>>>>> > and
>>>>> > > > the
>>>>> > > > >> > > start up cost in time and energy of getting it in order,
>>>>> which
>>>>> > can
>>>>> > > > be
>>>>> > > > >> > > daunting / intimidating and lower morale. And generally
>>>>> you want
>>>>> > > to
>>>>> > > > >> use
>>>>> > > > >> > > take your legacy code and refactor instead of in someways
>>>>> > starting
>>>>> > > > >> over.
>>>>> > > > >> > >
>>>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
>>>>> > something
>>>>> > > > >> similar
>>>>> > > > >> > > to
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> >
>>>>> > > > >>
>>>>> > > >
>>>>> > >
>>>>> >
>>>>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>>>>> > > > >> > > where it tracks what needs to get ported / what has been
>>>>> ported.
>>>>> > > > >> > >
>>>>> > > > >> > > What are we going to support in the next version?
>>>>> > > > >> > >
>>>>> > > > >> > > Who is going to work on the next version?
>>>>> > > > >> > >
>>>>> > > > >> > > What would make the most sense and what would invigorate
>>>>> the
>>>>> > > > >> community to
>>>>> > > > >> > > get involved more and lower the barrier to entry?
>>>>> > > > >> > >
>>>>> > > > >> > > I think those are the questions that would make a lot of
>>>>> the
>>>>> > > > decisions
>>>>> > > > >> > for
>>>>> > > > >> > > us so that we can get back to work on lucene.net.
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>>>>> > > > marcoslimagon@gmail.com
>>>>> > > > >> > > >wrote:
>>>>> > > > >> > >
>>>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
>>>>> projects...
>>>>> > > > >> > > >
>>>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>>>>> > > > >> > > > https://github.com/apache/lucene.net points to the same
>>>>> > > > repository?
>>>>> > > > >> > > (This
>>>>> > > > >> > > > is new for me, pretty good) Which of them do you
>>>>> recommend
>>>>> > (i'm
>>>>> > > > used
>>>>> > > > >> > with
>>>>> > > > >> > > > SVN and its patterns).
>>>>> > > > >> > > >
>>>>> > > > >> > > > I'm checking the subversion right now.
>>>>> > > > >> > > >
>>>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a
>>>>> old
>>>>> > > > branch,
>>>>> > > > >> i`m
>>>>> > > > >> > > not
>>>>> > > > >> > > > sure about its current status.
>>>>> > > > >> > > >
>>>>> > > > >> > > > Will we wipe the current solution from /trunk and start
>>>>> a new
>>>>> > > one?
>>>>> > > > >> > > >
>>>>> > > > >> > > > Thanks,
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
>>>>> > > > >> > > >
>>>>> > > > >> > > > > We may be forced to start with a clean/empty branch if
>>>>> > people
>>>>> > > > >> still
>>>>> > > > >> > > want
>>>>> > > > >> > > > to
>>>>> > > > >> > > > > attempt supporting lucene.net for mobile devices, win
>>>>> RT,
>>>>> > > etc.
>>>>> > > > >> The
>>>>> > > > >> > are
>>>>> > > > >> > > > > many
>>>>> > > > >> > > > > classes that Lucene.net uses from the full framework
>>>>> that
>>>>> > > would
>>>>> > > > >> not
>>>>> > > > >> > be
>>>>> > > > >> > > > > accessible in other versions of the .NET Framework.
>>>>> It also
>>>>> > > > might
>>>>> > > > >> > > > require
>>>>> > > > >> > > > > a design that differs even more from its parent
>>>>> project.
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > It might be wise to poll what users most desire in the
>>>>> next
>>>>> > > > >> version
>>>>> > > > >> > > > through
>>>>> > > > >> > > > > jira or user voice.
>>>>> > > > >> > > > >
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>>>>> > > > >> > itamar@code972.com
>>>>> > > > >> > > > > >wrote:
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > > inline
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>>>>> > > > >> pirwin@feature23.com>
>>>>> > > > >> > > > wrote:
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been
>>>>> a TFS
>>>>> > > guy
>>>>> > > > >> for
>>>>> > > > >> > so
>>>>> > > > >> > > > > long
>>>>> > > > >> > > > > > > :-)
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
>>>>> patches
>>>>> > or
>>>>> > > > >> > anything
>>>>> > > > >> > > > to
>>>>> > > > >> > > > > > the
>>>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we will
>>>>> > branch
>>>>> > > > from
>>>>> > > > >> > for
>>>>> > > > >> > > 4x
>>>>> > > > >> > > > > > dev.
>>>>> > > > >> > > > > > > Correct?
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
>>>>> anyone
>>>>> > > will
>>>>> > > > >> be
>>>>> > > > >> > > > > > interested in that
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal
>>>>> with
>>>>> > > the
>>>>> > > > >> > github
>>>>> > > > >> > > > > sync?
>>>>> > > > >> > > > > > > Who could diagnose that?
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the
>>>>> apache
>>>>> > repo
>>>>> > > > for
>>>>> > > > >> now
>>>>> > > > >> > > > while
>>>>> > > > >> > > > > > we get that sorted out.
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko
>>>>> <
>>>>> > > > >> > > > itamar@code972.com
>>>>> > > > >> > > > > > > >wrote:
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it
>>>>> then for
>>>>> > > 3.x
>>>>> > > > >> > > > > development.
>>>>> > > > >> > > > > > > WRT
>>>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on
>>>>> whatever
>>>>> > > branch.
>>>>> > > > >> When
>>>>> > > > >> > > you
>>>>> > > > >> > > > > > send
>>>>> > > > >> > > > > > > us
>>>>> > > > >> > > > > > > > PRs we will merge either to master or to a
>>>>> dedicated
>>>>> > > repo.
>>>>> > > > >> For
>>>>> > > > >> > > now
>>>>> > > > >> > > > it
>>>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see
>>>>> it on
>>>>> > the
>>>>> > > > >> apache
>>>>> > > > >> > > > > servers
>>>>> > > > >> > > > > > > > (github sync seems to be off)
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>>>>> > > > >> > > pirwin@feature23.com>
>>>>> > > > >> > > > > > > wrote:
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on
>>>>> 4.3
>>>>> > > version
>>>>> > > > >> of
>>>>> > > > >> > the
>>>>> > > > >> > > > > > > Analysis
>>>>> > > > >> > > > > > > > > namespace.
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Not sure the checkout command is what you
>>>>> intended
>>>>> > --
>>>>> > > > you
>>>>> > > > >> > might
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > meant
>>>>> > > > >> > > > > > > > > trunk instead of master, and that would create
>>>>> a new
>>>>> > > > "3x"
>>>>> > > > >> > > branch,
>>>>> > > > >> > > > > > when
>>>>> > > > >> > > > > > > > > there's already a "branch_3x" and that would be
>>>>> > > > >> misnamed...
>>>>> > > > >> > so
>>>>> > > > >> > > > > maybe
>>>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
>>>>> aiming
>>>>> > for
>>>>> > > > >> lucene
>>>>> > > > >> > > > 4.3.x
>>>>> > > > >> > > > > > > > > compatibility?
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
>>>>> > upstream
>>>>> > > > >> want to
>>>>> > > > >> > > > > create
>>>>> > > > >> > > > > > > the
>>>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're
>>>>> not all
>>>>> > > > >> trying to
>>>>> > > > >> > > > > create
>>>>> > > > >> > > > > > > them
>>>>> > > > >> > > > > > > > > and dealing with a merge?
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Paul
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>>>>> Syn-Hershko <
>>>>> > > > >> > > > > > itamar@code972.com
>>>>> > > > >> > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > > Unless people here have a specific reason to
>>>>> use
>>>>> > > > 3.6.2 I
>>>>> > > > >> > > would
>>>>> > > > >> > > > > > highly
>>>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
>>>>> towards v4
>>>>> > > > >> > otherwise
>>>>> > > > >> > > we
>>>>> > > > >> > > > > > will
>>>>> > > > >> > > > > > > > > never
>>>>> > > > >> > > > > > > > > > make it...
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > Fork the repo from apache servers or github
>>>>> (same
>>>>> > > > repo,
>>>>> > > > >> > > > different
>>>>> > > > >> > > > > > > > > remotes)
>>>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
>>>>> should
>>>>> > > work
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
>>>>> > > > >> > > > > pirwin@feature23.com>
>>>>> > > > >> > > > > > > > > wrote:
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > Itamar,
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > I agree that from scratch is not the best
>>>>> way to
>>>>> > > do
>>>>> > > > >> it, I
>>>>> > > > >> > > > just
>>>>> > > > >> > > > > > > > thought
>>>>> > > > >> > > > > > > > > > that
>>>>> > > > >> > > > > > > > > > > was the "decision" that was made from the
>>>>> > > discussion
>>>>> > > > >> > > > previously
>>>>> > > > >> > > > > > for
>>>>> > > > >> > > > > > > > the
>>>>> > > > >> > > > > > > > > > 4.x
>>>>> > > > >> > > > > > > > > > > work. An incremental approach will be much
>>>>> > better.
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
>>>>> branch on
>>>>> > > my
>>>>> > > > >> fork
>>>>> > > > >> > > and
>>>>> > > > >> > > > > will
>>>>> > > > >> > > > > > > > begin
>>>>> > > > >> > > > > > > > > > > working on bringing the Analysis namespace
>>>>> up to
>>>>> > > > >> speed to
>>>>> > > > >> > > > > 3.6.2.
>>>>> > > > >> > > > > > If
>>>>> > > > >> > > > > > > > > > anyone
>>>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once
>>>>> I'm
>>>>> > > done,
>>>>> > > > >> have
>>>>> > > > >> > at
>>>>> > > > >> > > > it.
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
>>>>> branch_3x
>>>>> > > > branch,
>>>>> > > > >> > > please
>>>>> > > > >> > > > > let
>>>>> > > > >> > > > > > > me
>>>>> > > > >> > > > > > > > > know
>>>>> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > Paul
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>>>>> > > Syn-Hershko <
>>>>> > > > >> > > > > > > > itamar@code972.com
>>>>> > > > >> > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
>>>>> again :)
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
>>>>> know
>>>>> > what
>>>>> > > > it
>>>>> > > > >> > would
>>>>> > > > >> > > > > take
>>>>> > > > >> > > > > > > > until
>>>>> > > > >> > > > > > > > > > they
>>>>> > > > >> > > > > > > > > > > > have deep dived into the work, and even
>>>>> then
>>>>> > > > >> decisions
>>>>> > > > >> > > > could
>>>>> > > > >> > > > > > and
>>>>> > > > >> > > > > > > > will
>>>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
>>>>> > starting
>>>>> > > > from
>>>>> > > > >> > > > scratch,
>>>>> > > > >> > > > > > > > > although
>>>>> > > > >> > > > > > > > > > I
>>>>> > > > >> > > > > > > > > > > do
>>>>> > > > >> > > > > > > > > > > > think a lot in the current structure
>>>>> should
>>>>> > > > change,
>>>>> > > > >> but
>>>>> > > > >> > > its
>>>>> > > > >> > > > > > going
>>>>> > > > >> > > > > > > > to
>>>>> > > > >> > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > much easier to change it in place,
>>>>> refactoring
>>>>> > > > where
>>>>> > > > >> > > > needed,
>>>>> > > > >> > > > > > than
>>>>> > > > >> > > > > > > > > > > starting
>>>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this off I
>>>>> > > > personally
>>>>> > > > >> > will
>>>>> > > > >> > > > be
>>>>> > > > >> > > > > > > happy
>>>>> > > > >> > > > > > > > > with
>>>>> > > > >> > > > > > > > > > > you
>>>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
>>>>> porting
>>>>> > > it,
>>>>> > > > >> its
>>>>> > > > >> > > > pretty
>>>>> > > > >> > > > > > > much
>>>>> > > > >> > > > > > > > > self
>>>>> > > > >> > > > > > > > > > > > contained.
>>>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on
>>>>> a fork
>>>>> > > and
>>>>> > > > >> send
>>>>> > > > >> > > us
>>>>> > > > >> > > > > PRs,
>>>>> > > > >> > > > > > > its
>>>>> > > > >> > > > > > > > > > much
>>>>> > > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
>>>>> fastest
>>>>> > > way
>>>>> > > > >> to do
>>>>> > > > >> > > > this,
>>>>> > > > >> > > > > > we
>>>>> > > > >> > > > > > > > can
>>>>> > > > >> > > > > > > > > > then
>>>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing
>>>>> using
>>>>> > > > .NET
>>>>> > > > >> > > > > constructs.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
>>>>> create a
>>>>> > > > branch
>>>>> > > > >> out
>>>>> > > > >> > > of
>>>>> > > > >> > > > > the
>>>>> > > > >> > > > > > > > > current
>>>>> > > > >> > > > > > > > > > > git
>>>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
>>>>> > > working
>>>>> > > > on
>>>>> > > > >> > > master
>>>>> > > > >> > > > > > > > towards a
>>>>> > > > >> > > > > > > > > > 4.3
>>>>> > > > >> > > > > > > > > > > > compatible version. The actual port
>>>>> should be
>>>>> > > > using
>>>>> > > > >> a
>>>>> > > > >> > > > process
>>>>> > > > >> > > > > > > that
>>>>> > > > >> > > > > > > > > > > ensures
>>>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
>>>>> tests,
>>>>> > > and
>>>>> > > > >> that
>>>>> > > > >> > > > those
>>>>> > > > >> > > > > > > tests
>>>>> > > > >> > > > > > > > > > pass -
>>>>> > > > >> > > > > > > > > > > > but I'm against committing any Java code
>>>>> to
>>>>> > our
>>>>> > > > >> > > > repositories.
>>>>> > > > >> > > > > > The
>>>>> > > > >> > > > > > > > > > process
>>>>> > > > >> > > > > > > > > > > > should probably be working on classes in
>>>>> some
>>>>> > > > order
>>>>> > > > >> > > > > > > > (alphabetically,
>>>>> > > > >> > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > core classes first) and getting each
>>>>> class to
>>>>> > > > >> compile
>>>>> > > > >> > > > before
>>>>> > > > >> > > > > > > moving
>>>>> > > > >> > > > > > > > > > > > forward. I don't mind about the project
>>>>> not
>>>>> > > being
>>>>> > > > >> > > > compilable
>>>>> > > > >> > > > > > for
>>>>> > > > >> > > > > > > a
>>>>> > > > >> > > > > > > > > > month
>>>>> > > > >> > > > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > two.
>>>>> > > > >> > > > > > > > > > > > Once this is done a process of
>>>>> .NETifying and
>>>>> > > > >> proofing
>>>>> > > > >> > > the
>>>>> > > > >> > > > > code
>>>>> > > > >> > > > > > > can
>>>>> > > > >> > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > started, at which point we will already
>>>>> have a
>>>>> > > > >> working
>>>>> > > > >> > v4
>>>>> > > > >> > > > > > version
>>>>> > > > >> > > > > > > > so
>>>>> > > > >> > > > > > > > > it
>>>>> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
>>>>> > project.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
>>>>> test
>>>>> > > suite
>>>>> > > > so
>>>>> > > > >> > > tests
>>>>> > > > >> > > > > > could
>>>>> > > > >> > > > > > > > more
>>>>> > > > >> > > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
>>>>> implementing
>>>>> > > > >> Java-like
>>>>> > > > >> > > > > > > assertEquals
>>>>> > > > >> > > > > > > > > > > methods
>>>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
>>>>> work
>>>>> > with
>>>>> > > > >> than
>>>>> > > > >> > > > > NUnit). I
>>>>> > > > >> > > > > > > > > already
>>>>> > > > >> > > > > > > > > > > did
>>>>> > > > >> > > > > > > > > > > > some work there but there's still a lot
>>>>> to do.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
>>>>> myself at
>>>>> > > this
>>>>> > > > >> > point,
>>>>> > > > >> > > > > but I
>>>>> > > > >> > > > > > > > > should
>>>>> > > > >> > > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > back in business in August, at which
>>>>> point I
>>>>> > can
>>>>> > > > >> > dedicate
>>>>> > > > >> > > > > > several
>>>>> > > > >> > > > > > > > > > hours a
>>>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
>>>>> > closely
>>>>> > > > and
>>>>> > > > >> > even
>>>>> > > > >> > > > > > > coordinate
>>>>> > > > >> > > > > > > > > the
>>>>> > > > >> > > > > > > > > > > > work to some extent.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
>>>>> Lima <
>>>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this is a
>>>>> kick
>>>>> > > > start
>>>>> > > > >> > =). I
>>>>> > > > >> > > > > > haven't
>>>>> > > > >> > > > > > > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > > > anything
>>>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you all
>>>>> to get
>>>>> > > > this
>>>>> > > > >> job
>>>>> > > > >> > > > done.
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
>>>>> Prescott.
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > I know that there is a high commitment
>>>>> for
>>>>> > > keep
>>>>> > > > >> the
>>>>> > > > >> > > > > > > > > > retrocompatibility
>>>>> > > > >> > > > > > > > > > > on
>>>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
>>>>> > changes
>>>>> > > > >> every
>>>>> > > > >> > > > > release?
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
>>>>> > version
>>>>> > > > >> from a
>>>>> > > > >> > > > > Lucene
>>>>> > > > >> > > > > > > > > version,
>>>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only
>>>>> minor
>>>>> > > changes
>>>>> > > > >> > every
>>>>> > > > >> > > > > stable
>>>>> > > > >> > > > > > > > > release
>>>>> > > > >> > > > > > > > > > > (or
>>>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we could
>>>>> > > compare
>>>>> > > > >> the
>>>>> > > > >> > > > > versions,
>>>>> > > > >> > > > > > > > check
>>>>> > > > >> > > > > > > > > > the
>>>>> > > > >> > > > > > > > > > > > > differences and bring them to
>>>>> Lucene.Net.
>>>>> > > > Again, I
>>>>> > > > >> > > > haven't
>>>>> > > > >> > > > > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > > with
>>>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
>>>>> > idea).
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > What's your approach for implement
>>>>> simple
>>>>> > > > >> performance
>>>>> > > > >> > > > > > > > improvements
>>>>> > > > >> > > > > > > > > > > > (without
>>>>> > > > >> > > > > > > > > > > > > adding references or changing methods
>>>>> > > > signatures)?
>>>>> > > > >> > Does
>>>>> > > > >> > > > it
>>>>> > > > >> > > > > > > could
>>>>> > > > >> > > > > > > > be
>>>>> > > > >> > > > > > > > > > > done,
>>>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
>>>>> pirwin@feature23.com>
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > This is just an "outsider"
>>>>> suggestion as I
>>>>> > > > >> haven't
>>>>> > > > >> > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > anything
>>>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely help
>>>>> with
>>>>> > > the
>>>>> > > > >> 4.x
>>>>> > > > >> > > work
>>>>> > > > >> > > > > as I
>>>>> > > > >> > > > > > > > have
>>>>> > > > >> > > > > > > > > a
>>>>> > > > >> > > > > > > > > > > > vested
>>>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
>>>>> completed. I
>>>>> > > think
>>>>> > > > >> > there
>>>>> > > > >> > > > > should
>>>>> > > > >> > > > > > > be
>>>>> > > > >> > > > > > > > > one
>>>>> > > > >> > > > > > > > > > > > person
>>>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
>>>>> > structure
>>>>> > > > and
>>>>> > > > >> > > > workflow
>>>>> > > > >> > > > > > will
>>>>> > > > >> > > > > > > > > look
>>>>> > > > >> > > > > > > > > > > like
>>>>> > > > >> > > > > > > > > > > > > to
>>>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is
>>>>> going to
>>>>> > be
>>>>> > > > >> > starting
>>>>> > > > >> > > > from
>>>>> > > > >> > > > > > > > scratch
>>>>> > > > >> > > > > > > > > > as
>>>>> > > > >> > > > > > > > > > > a
>>>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set
>>>>> up the
>>>>> > > > >> project,
>>>>> > > > >> > > get
>>>>> > > > >> > > > > > > > everything
>>>>> > > > >> > > > > > > > > > > going
>>>>> > > > >> > > > > > > > > > > > > in
>>>>> > > > >> > > > > > > > > > > > > > source control, create the folder
>>>>> > structure,
>>>>> > > > >> maybe
>>>>> > > > >> > > stub
>>>>> > > > >> > > > > out
>>>>> > > > >> > > > > > > > some
>>>>> > > > >> > > > > > > > > > > > classes,
>>>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
>>>>> anyone
>>>>> > > > >> interested
>>>>> > > > >> > > in
>>>>> > > > >> > > > > > > > > > contributing,
>>>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the java
>>>>> code
>>>>> > in
>>>>> > > > >> there
>>>>> > > > >> > so
>>>>> > > > >> > > > > it's
>>>>> > > > >> > > > > > > easy
>>>>> > > > >> > > > > > > > > to
>>>>> > > > >> > > > > > > > > > > > > > reference.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > Again, I can work on
>>>>> Lucene.Net.Documents,
>>>>> > > > >> > > > > > > Lucene.Net.Analysis,
>>>>> > > > >> > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
>>>>> those
>>>>> > are
>>>>> > > > >> just
>>>>> > > > >> > the
>>>>> > > > >> > > > > ones
>>>>> > > > >> > > > > > > I'm
>>>>> > > > >> > > > > > > > > most
>>>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
>>>>> Tell me
>>>>> > > what
>>>>> > > > >> to
>>>>> > > > >> > do
>>>>> > > > >> > > > and
>>>>> > > > >> > > > > > I'll
>>>>> > > > >> > > > > > > > get
>>>>> > > > >> > > > > > > > > > > > started
>>>>> > > > >> > > > > > > > > > > > > > on my fork.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > Paul Irwin
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
>>>>> Prescott
>>>>> > > > Nasser
>>>>> > > > >> <
>>>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
>>>>> > > > >> > > > > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > > Hey guys -
>>>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
>>>>> while. We
>>>>> > > > have a
>>>>> > > > >> > > board
>>>>> > > > >> > > > > > report
>>>>> > > > >> > > > > > > > due
>>>>> > > > >> > > > > > > > > > > soon
>>>>> > > > >> > > > > > > > > > > > -
>>>>> > > > >> > > > > > > > > > > > > I
>>>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise
>>>>> them
>>>>> > that
>>>>> > > we
>>>>> > > > >> seem
>>>>> > > > >> > > to
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > > stalled
>>>>> > > > >> > > > > > > > > > > > > > somewhat.
>>>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items
>>>>> out of
>>>>> > > of
>>>>> > > > >> jira
>>>>> > > > >> > > and
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > been
>>>>> > > > >> > > > > > > > > > > > > responsive
>>>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
>>>>> > > questions,
>>>>> > > > >> but I
>>>>> > > > >> > > > don't
>>>>> > > > >> > > > > > > think
>>>>> > > > >> > > > > > > > > > we've
>>>>> > > > >> > > > > > > > > > > > > done
>>>>> > > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
>>>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
>>>>> > start
>>>>> > > us
>>>>> > > > >> back
>>>>> > > > >> > > up
>>>>> > > > >> > > > > > moving
>>>>> > > > >> > > > > > > > > > > forward.
>>>>> > > > >> > > > > > > > > > > > > What
>>>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish
>>>>> this? If
>>>>> > we
>>>>> > > > took
>>>>> > > > >> > the
>>>>> > > > >> > > > java
>>>>> > > > >> > > > > > > > lucene
>>>>> > > > >> > > > > > > > > > 4.0
>>>>> > > > >> > > > > > > > > > > > code
>>>>> > > > >> > > > > > > > > > > > > > and
>>>>> > > > >> > > > > > > > > > > > > > > committed that java to our branch
>>>>> and
>>>>> > then
>>>>> > > > >> just
>>>>> > > > >> > let
>>>>> > > > >> > > > > > people
>>>>> > > > >> > > > > > > > pull
>>>>> > > > >> > > > > > > > > > > that
>>>>> > > > >> > > > > > > > > > > > > down
>>>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying is
>>>>> that
>>>>> > one
>>>>> > > > >> way to
>>>>> > > > >> > > > maybe
>>>>> > > > >> > > > > > > make
>>>>> > > > >> > > > > > > > > some
>>>>> > > > >> > > > > > > > > > > > > forward
>>>>> > > > >> > > > > > > > > > > > > > > progress?
>>>>> > > > >> > > > > > > > > > > > > > > ~P
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > --
>>>>> > > > >> > > > > > > > > > > > > --
>>>>> > > > >> > > > > > > > > > > > > Marcos Lima
>>>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
>>>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > > --
>>>>> > > > >> > > > --
>>>>> > > > >> > > > Marcos Lima
>>>>> > > > >> > > > Software Developer/Tech Lead
>>>>> > > > >> > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > tel: +55 (19) 9798-9335
>>>>> > > > >> > > >
>>>>> > > > >> > >
>>>>> > > > >> >
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> --
>>>>> > > > >> --
>>>>> > > > >> Marcos Lima
>>>>> > > > >> Software Developer/Tech Lead
>>>>> > > > >> marcoslimagon@gmail.com
>>>>> > > > >> tel: +55 (19) 9798-9335
>>>>> > > > >>
>>>>> > > > >
>>>>> > > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
Re: Lucene 4.0
Posted by Rob Vesse <rv...@dotnetrdf.org>.
Paul
You are doing great and much needed work and I look forward to eventually
being able to consume it in my projects that rely on Lucene.Net 3.0.3
currently.
I'm afraid the mailing list and more generally the project does appear to
be dead right now. I keep an eye on general goings on at Apache that I am
interested in such as Lucene.Net and I did see that the Lucene.Net project
had its board report rejected in July. I'm afraid I don't know why the
report was rejected as meetings don't become public record until the
following month when the next board meeting approves the minutes from the
previous meeting.
Rob
On 8/8/13 12:31 PM, "Paul Irwin" <pi...@feature23.com> wrote:
>Is this mailing list dead?! If anyone is interested in releasing an
>up-to-date build of Lucene.net, please write back! If you didn't read my
>other messages, I have Lucene.net Core working with Lucene java 4.3.1
>compatibility thanks to the help of my colleagues. We just need to round
>out the contrib modules, unit tests, and documentation as a community and
>we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>was packaged in December 2010!
>
>I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>(where they now live in Lucene java, they were moved from core) and their
>associated filters and tokenizers. I've briefly tested each and they seem
>to work correctly. I've purposefully "Exclude[d] from Project" the other
>language analyzers until we can forward-port them. So now the Analyzers
>DLL
>compiles with those analyzers only. Also, I fixed the bug that was causing
>NumericRangeQuery to not work.
>
>Next on my list is the QueryParsers contrib library (QueryParser was moved
>out of Lucene java core) so that, combined with StandardAnalyzer, we can
>test a pretty common real-world use case (the prototypical "hello lucene"
>tutorial). After that, it might be worth forward-porting what we have so
>far to 4.4 and use that as the latest point to finish out the port. The
>changes shouldn't be too dramatic to core from what I can tell.
>
>My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
>I'll keep updating as I go, but if anyone wants to jump in, there's not a
>better time than now...
>
>
>
>On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> I made a dumb mistake... I have worked with StandardAnalyzer so long
>>that
>> I forgot that KeywordAnalyzer is not what I needed to be using, I
>>needed to
>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>
>> Now it works after re-indexing with a quick, dirty implementation of
>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1
>>can
>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move
>>on to
>> find out why NumericRangeQuery isn't working.
>>
>> Sorry for the blast of emails, but I wanted to prevent people from
>> spending time hunting down my mistake!
>>
>>
>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>>wrote:
>>
>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong.
>>>Java's
>>> byte being signed is a pain.
>>>
>>> Now there's no exception doing a TermQuery, but I also don't get any
>>> results. It doesn't find any terms when scanning for them. I also
>>>tried a
>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and
>>>it
>>> didn't find any results that way either. So right now only
>>> MatchAllDocsQuery seems to work.
>>>
>>> If anyone would like to do a Google Hangout or anything sometime to
>>>look
>>> into it, let me know.
>>>
>>>
>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>>>wrote:
>>>
>>>> I realized after I sent that email last night that I could do as you
>>>> described. When you've been debugging through
>>>>CorruptedIndexExceptions, you
>>>> get a little bit of tunnel vision... haha
>>>>
>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>>>>.ToString()'ing
>>>> the matching documents prints the fields to the console, so it's
>>>>loading in
>>>> the stored fields data correctly.
>>>>
>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>>>>that
>>>> I can't figure out. There's a whole bunch of buffered byte array
>>>>operations
>>>> going on and I can't determine where the issue came from. I'll keep
>>>> looking, but if someone could grab my fork/branch and help me look
>>>>that
>>>> would be great. Here's example index writing and then reading code
>>>>(also
>>>> included is a quick port of KeywordAnalyzer):
>>>> https://gist.github.com/anonymous/6174164
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko
>>>><it...@code972.com>wrote:
>>>>
>>>>> Great
>>>>>
>>>>> You can build you Query objects on your own to execute a search, you
>>>>> don't
>>>>> actually have to use QueryParser for that
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
>>>>> wrote:
>>>>>
>>>>> > Hey all, sorry it's been a little while, but I wanted to let you
>>>>>know
>>>>> that
>>>>> > although I took a few weeks off from it, I now have a 4.3.1
>>>>>equivalent
>>>>> > Lucene.net core building and able to write a simple index in Lucene
>>>>> 4.2
>>>>> > codec and read in things like the number of documents and whatnot.
>>>>> Since
>>>>> > QueryParser has been moved to a separate module in Lucene Java
>>>>>4.x, I
>>>>> > haven't ported that yet so I haven't done a real search, and I only
>>>>> built
>>>>> > the index using a quick port of KeywordAnalyzer which all those
>>>>> analyzers
>>>>> > have also moved to another module. But this is definitely good
>>>>> progress and
>>>>> > should be a launch point for finishing a 4.3/4.4 port.
>>>>> >
>>>>> > You can see my fork/branch here:
>>>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
>>>>> like I
>>>>> > said, only core builds now, no modules/tests build, so only open
>>>>>the
>>>>> > Lucene.Net.Core.sln)
>>>>> >
>>>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
>>>>> the
>>>>> > community into finishing the 4.3/4.4 port. Let me know if you have
>>>>>any
>>>>> > questions, thanks!
>>>>> >
>>>>> >
>>>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>>>> itamar@code972.com
>>>>> > >wrote:
>>>>> >
>>>>> > > Paul, that's awesome. I will need some more time to go over this
>>>>> thread
>>>>> > and
>>>>> > > your work to give actual feedback, SUPER busy at the moment
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin
>>>>><pi...@feature23.com>
>>>>> > wrote:
>>>>> > >
>>>>> > > > All,
>>>>> > > >
>>>>> > > > My colleagues and I have made good progress on porting Lucene
>>>>> 4.3's
>>>>> > core
>>>>> > > > library before, during, and after the hackathon last week. We
>>>>>now
>>>>> only
>>>>> > > have
>>>>> > > > some remaining items in Search, Index, and Codecs namespaces
>>>>> (plus a
>>>>> > few
>>>>> > > > other minor ones here and there). I expect to be done by the
>>>>>end
>>>>> of the
>>>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
>>>>> Packed),
>>>>> > > and
>>>>> > > > the root Codecs and Codecs.PerField namespaces are all now
>>>>>"done".
>>>>> > > >
>>>>> > > > Again, my goal is to only get a buildable, experimental build
>>>>>of
>>>>> > > Lucene.net
>>>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>>>>> porting
>>>>> > > new
>>>>> > > > javadoc comments or unit tests right now, due to the vast
>>>>>amount
>>>>> of
>>>>> > code
>>>>> > > > that needs to be written just to get it to compile. If this
>>>>>work
>>>>> ends
>>>>> > up
>>>>> > > > becoming a pull request, great, otherwise it should help
>>>>> accelerate a
>>>>> > > port
>>>>> > > > of 4.3.x since the bulk of the work on core will already be
>>>>>done
>>>>> and
>>>>> > > > contributors can use it as a reference. And again, we're taking
>>>>> the
>>>>> > > > pragmatic approach of porting class-by-class,
>>>>> namespace-by-namespace,
>>>>> > > with
>>>>> > > > the understanding that until we're done the project won't
>>>>>build.
>>>>> > > >
>>>>> > > > Once complete, I also will work on updating the Analyzers
>>>>>contrib
>>>>> > module
>>>>> > > > and porting the QueryParsers contrib module, which I feel
>>>>>should
>>>>> be
>>>>> > > > included in the core NuGet package for Lucene.net as the core
>>>>> library
>>>>> > is
>>>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
>>>>> without
>>>>> > > them.
>>>>> > > > You can check out the code on my fork/branch here:
>>>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>> > > >
>>>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
>>>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
>>>>> For the
>>>>> > > MMap
>>>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
>>>>> > > > MemoryMappedFile support which should emulate the Java nio
>>>>>stuff
>>>>> pretty
>>>>> > > > well, but required some creative shuffling of the code to make
>>>>>it
>>>>> work
>>>>> > > due
>>>>> > > > to lifecycle management.
>>>>> > > >
>>>>> > > > I'll update again this weekend or next week, when we should
>>>>>have
>>>>> > wrapped
>>>>> > > up
>>>>> > > > most of the main hacking on porting the core code.
>>>>> > > >
>>>>> > > > Paul
>>>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin
>>>>><pirwin@feature23.com
>>>>> >
>>>>> > > wrote:
>>>>> > > >
>>>>> > > > > Marcos,
>>>>> > > > >
>>>>> > > > > That would be helpful. As far as I can tell, the 3.0 java
>>>>>code
>>>>> is
>>>>> > only
>>>>> > > on
>>>>> > > > > SVN here, before the lucene and solr projects were bundled
>>>>> together:
>>>>> > > > >
>>>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>>>>> > > > >
>>>>> > > > > The SVN for 4.3 java is here:
>>>>> > > > >
>>>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>>>>> > > > > And the GitHub for 4.3 java is here:
>>>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>>>>> > > > >
>>>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
>>>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>>>>> > > > >
>>>>> > > > > My fork is the "upstream" fork for my team members, and i'm
>>>>> remote
>>>>> > > > merging
>>>>> > > > > their changes in from their forks while they fetch/merge from
>>>>> mine to
>>>>> > > get
>>>>> > > > > everyone else's changes, rather than using pull requests.
>>>>>James
>>>>> and I
>>>>> > > > have
>>>>> > > > > been working the past few days on the Util namespace ahead of
>>>>> > tonight's
>>>>> > > > > hackathon since that namespace is in common with the rest of
>>>>>the
>>>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know
>>>>>of
>>>>> > hacking
>>>>> > > on
>>>>> > > > > porting 4.3, each with a different namespace or part of a
>>>>> namespace.
>>>>> > > > Since
>>>>> > > > > we're going class-by-class, namespace-by-namespace, the
>>>>>project
>>>>> does
>>>>> > > not
>>>>> > > > > build as it is. Once we finish doing a translation of each
>>>>> file, then
>>>>> > > > we'll
>>>>> > > > > hammer out any remaining issues and get it to build again.
>>>>>I'm
>>>>> hoping
>>>>> > > > that
>>>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
>>>>> > > > >
>>>>> > > > > But one thing to keep in mind is it looks like much
>>>>> functionality has
>>>>> > > > been
>>>>> > > > > moved out of core into the contrib modules, especially around
>>>>> > analysis,
>>>>> > > > for
>>>>> > > > > 4.0+. For example, there are no built-in analyzers in core
>>>>> anymore.
>>>>> > So
>>>>> > > > when
>>>>> > > > > this is all done, we may want to include at least the
>>>>>analysis
>>>>> > contrib
>>>>> > > > > module in with the standard core NuGet package, because
>>>>> otherwise
>>>>> > it's
>>>>> > > > > practically useless unless you roll your own analyzer.
>>>>> > > > >
>>>>> > > > > Paul
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>>>>> > marcoslimagon@gmail.com
>>>>> > > > >wrote:
>>>>> > > > >
>>>>> > > > >> Hi everyone!
>>>>> > > > >>
>>>>> > > > >> Does someone know where can I find the 3.0.3 release from
>>>>> > > Lucene(java)?
>>>>> > > > >>
>>>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
>>>>> 4.3.0 and
>>>>> > > > make
>>>>> > > > >> the diff between then and get all changes between
>>>>>releases... I
>>>>> > gonna
>>>>> > > > >> publish it here soon. (If you think there is another
>>>>>important
>>>>> > > release,
>>>>> > > > >> let
>>>>> > > > >> me know)
>>>>> > > > >>
>>>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry)
>>>>> with
>>>>> > 4.3.0
>>>>> > > > >> port
>>>>> > > > >> for .Net on github (last email)?
>>>>> > > > >>
>>>>> > > > >> See you,
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>>>> > > > >>
>>>>> > > > >> > Thanks for the discussion points, Michael.
>>>>> > > > >> >
>>>>> > > > >> > I would vote for not worrying about trying to achieve
>>>>> portable
>>>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to
>>>>>4.3+
>>>>> is
>>>>> > > > >> completed.
>>>>> > > > >> > Otherwise it may delay the project and stall it further.
>>>>> That's
>>>>> > just
>>>>> > > > my
>>>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x
>>>>>features.
>>>>> > > > >> >
>>>>> > > > >> > I have started porting the changes from the core library
>>>>> (from the
>>>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
>>>>> separate
>>>>> > > > branch.
>>>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
>>>>> port
>>>>> > > until
>>>>> > > > >> > there's changes to pull from upstream to work from. Also
>>>>>due
>>>>> to my
>>>>> > > > time
>>>>> > > > >> > constraints, I am not fully documenting new methods that
>>>>>I'm
>>>>> > adding.
>>>>> > > > >> But if
>>>>> > > > >> > anyone wants to pull/copy/reference my changes while
>>>>>porting,
>>>>> > that's
>>>>> > > > >> > awesome. My branch currently does not build as I'm
>>>>>primarily
>>>>> going
>>>>> > > > >> > class-by-class, starting with the util namespace. Once we
>>>>> get the
>>>>> > > ball
>>>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
>>>>> join
>>>>> > in.
>>>>> > > > But
>>>>> > > > >> > hopefully my work will be useful to someone, if not as a
>>>>>pull
>>>>> > > request
>>>>> > > > >> then
>>>>> > > > >> > as a reference. I'm also going to be holding a hackathon
>>>>> this week
>>>>> > > > with
>>>>> > > > >> my
>>>>> > > > >> > colleagues where we're all going to work on the port. I'm
>>>>> > comparing
>>>>> > > > >> files
>>>>> > > > >> > and making changes as necessary, rather than starting from
>>>>> > scratch.
>>>>> > > My
>>>>> > > > >> > repo/branch is here:
>>>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>> > > > >> >
>>>>> > > > >> > Paul
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> >
>>>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>>>>> > > > >> > mherndon@michaelherndon.com> wrote:
>>>>> > > > >> >
>>>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
>>>>> apache
>>>>> > > > >> > maintains.
>>>>> > > > >> > >
>>>>> > > > >> > > The was some work at one time to move the official svn
>>>>> > repository
>>>>> > > to
>>>>> > > > >> > start
>>>>> > > > >> > > using git one instead. Was that actually finalized or
>>>>>not?
>>>>> > > > >> > >
>>>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch
>>>>>to
>>>>> see
>>>>> > > what
>>>>> > > > >> kind
>>>>> > > > >> > of
>>>>> > > > >> > > work was involved using a portable libraries project.
>>>>>Some
>>>>> of it
>>>>> > > can
>>>>> > > > >> > still
>>>>> > > > >> > > be used but will need to be validated against the
>>>>>current
>>>>> > version
>>>>> > > of
>>>>> > > > >> > Java's
>>>>> > > > >> > > Lucene. It was also using .net 4.
>>>>> > > > >> > >
>>>>> > > > >> > > clean branch vs current. Its going to depend on
>>>>>what we
>>>>> > > support.
>>>>> > > > >> If
>>>>> > > > >> > you
>>>>> > > > >> > > support windows mobile 8, win RT, then the current code
>>>>>in
>>>>> trunk
>>>>> > > > will
>>>>> > > > >> not
>>>>> > > > >> > > compile against those versions of the framework which
>>>>> would a
>>>>> > > > >> frustrating
>>>>> > > > >> > > starting point, then you couldn't even run tests, which
>>>>> would
>>>>> > make
>>>>> > > > >> taking
>>>>> > > > >> > > patches very difficult. Supporting those can almost
>>>>>mean
>>>>> larger
>>>>> > > > gaps
>>>>> > > > >> in
>>>>> > > > >> > > design between Lucene.Net and its parent project.
>>>>> > > > >> > >
>>>>> > > > >> > > Also the structure has changed significantly between
>>>>>the
>>>>> > branches
>>>>> > > > and
>>>>> > > > >> > the
>>>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java
>>>>>6,
>>>>> and
>>>>> > > seems
>>>>> > > > >> > > significantly different. That doesn't mean you can't
>>>>> cherry
>>>>> > pick
>>>>> > > > >> stuff
>>>>> > > > >> > > from the other tags/branches that would still work as
>>>>>is.
>>>>> A
>>>>> > clean
>>>>> > > > >> branch
>>>>> > > > >> > > would also make it easier to get our build / tool chain
>>>>>in
>>>>> order
>>>>> > > as
>>>>> > > > >> you
>>>>> > > > >> > can
>>>>> > > > >> > > then do them incrementally versus having to do all the
>>>>> stuff
>>>>> > that
>>>>> > > I
>>>>> > > > >> did
>>>>> > > > >> > for
>>>>> > > > >> > > the 3x branch which saps energy and desire to code. It
>>>>> could
>>>>> > > also
>>>>> > > > >> make
>>>>> > > > >> > it
>>>>> > > > >> > > easier to see which classes have been ported or not.
>>>>> > > > >> > >
>>>>> > > > >> > > The major downside to a clean branch is extra work it
>>>>> requires
>>>>> > and
>>>>> > > > the
>>>>> > > > >> > > start up cost in time and energy of getting it in order,
>>>>> which
>>>>> > can
>>>>> > > > be
>>>>> > > > >> > > daunting / intimidating and lower morale. And generally
>>>>> you want
>>>>> > > to
>>>>> > > > >> use
>>>>> > > > >> > > take your legacy code and refactor instead of in
>>>>>someways
>>>>> > starting
>>>>> > > > >> over.
>>>>> > > > >> > >
>>>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
>>>>> > something
>>>>> > > > >> similar
>>>>> > > > >> > > to
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> >
>>>>> > > > >>
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>>https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene
>>>>>4xPortProgress-Lucene.NetCoreFolders
>>>>> > > > >> > > where it tracks what needs to get ported / what has been
>>>>> ported.
>>>>> > > > >> > >
>>>>> > > > >> > > What are we going to support in the next version?
>>>>> > > > >> > >
>>>>> > > > >> > > Who is going to work on the next version?
>>>>> > > > >> > >
>>>>> > > > >> > > What would make the most sense and what would invigorate
>>>>> the
>>>>> > > > >> community to
>>>>> > > > >> > > get involved more and lower the barrier to entry?
>>>>> > > > >> > >
>>>>> > > > >> > > I think those are the questions that would make a lot of
>>>>> the
>>>>> > > > decisions
>>>>> > > > >> > for
>>>>> > > > >> > > us so that we can get back to work on lucene.net.
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > >
>>>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>>>>> > > > marcoslimagon@gmail.com
>>>>> > > > >> > > >wrote:
>>>>> > > > >> > >
>>>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
>>>>> projects...
>>>>> > > > >> > > >
>>>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>>>>> > > > >> > > > https://github.com/apache/lucene.net points to the
>>>>>same
>>>>> > > > repository?
>>>>> > > > >> > > (This
>>>>> > > > >> > > > is new for me, pretty good) Which of them do you
>>>>> recommend
>>>>> > (i'm
>>>>> > > > used
>>>>> > > > >> > with
>>>>> > > > >> > > > SVN and its patterns).
>>>>> > > > >> > > >
>>>>> > > > >> > > > I'm checking the subversion right now.
>>>>> > > > >> > > >
>>>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is
>>>>>a
>>>>> old
>>>>> > > > branch,
>>>>> > > > >> i`m
>>>>> > > > >> > > not
>>>>> > > > >> > > > sure about its current status.
>>>>> > > > >> > > >
>>>>> > > > >> > > > Will we wipe the current solution from /trunk and
>>>>>start
>>>>> a new
>>>>> > > one?
>>>>> > > > >> > > >
>>>>> > > > >> > > > Thanks,
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > > 2013/6/6 mherndon michael
>>>>><mh...@michaelherndon.com>
>>>>> > > > >> > > >
>>>>> > > > >> > > > > We may be forced to start with a clean/empty branch
>>>>>if
>>>>> > people
>>>>> > > > >> still
>>>>> > > > >> > > want
>>>>> > > > >> > > > to
>>>>> > > > >> > > > > attempt supporting lucene.net for mobile devices,
>>>>>win
>>>>> RT,
>>>>> > > etc.
>>>>> > > > >> The
>>>>> > > > >> > are
>>>>> > > > >> > > > > many
>>>>> > > > >> > > > > classes that Lucene.net uses from the full framework
>>>>> that
>>>>> > > would
>>>>> > > > >> not
>>>>> > > > >> > be
>>>>> > > > >> > > > > accessible in other versions of the .NET Framework.
>>>>> It also
>>>>> > > > might
>>>>> > > > >> > > > require
>>>>> > > > >> > > > > a design that differs even more from its parent
>>>>> project.
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > It might be wise to poll what users most desire in
>>>>>the
>>>>> next
>>>>> > > > >> version
>>>>> > > > >> > > > through
>>>>> > > > >> > > > > jira or user voice.
>>>>> > > > >> > > > >
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>>>>> > > > >> > itamar@code972.com
>>>>> > > > >> > > > > >wrote:
>>>>> > > > >> > > > >
>>>>> > > > >> > > > > > inline
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>>>>> > > > >> pirwin@feature23.com>
>>>>> > > > >> > > > wrote:
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've
>>>>>been
>>>>> a TFS
>>>>> > > guy
>>>>> > > > >> for
>>>>> > > > >> > so
>>>>> > > > >> > > > > long
>>>>> > > > >> > > > > > > :-)
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
>>>>> patches
>>>>> > or
>>>>> > > > >> > anything
>>>>> > > > >> > > > to
>>>>> > > > >> > > > > > the
>>>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we
>>>>>will
>>>>> > branch
>>>>> > > > from
>>>>> > > > >> > for
>>>>> > > > >> > > 4x
>>>>> > > > >> > > > > > dev.
>>>>> > > > >> > > > > > > Correct?
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
>>>>> anyone
>>>>> > > will
>>>>> > > > >> be
>>>>> > > > >> > > > > > interested in that
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the
>>>>>deal
>>>>> with
>>>>> > > the
>>>>> > > > >> > github
>>>>> > > > >> > > > > sync?
>>>>> > > > >> > > > > > > Who could diagnose that?
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the
>>>>> apache
>>>>> > repo
>>>>> > > > for
>>>>> > > > >> now
>>>>> > > > >> > > > while
>>>>> > > > >> > > > > > we get that sorted out.
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar
>>>>>Syn-Hershko
>>>>> <
>>>>> > > > >> > > > itamar@code972.com
>>>>> > > > >> > > > > > > >wrote:
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it
>>>>> then for
>>>>> > > 3.x
>>>>> > > > >> > > > > development.
>>>>> > > > >> > > > > > > WRT
>>>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on
>>>>> whatever
>>>>> > > branch.
>>>>> > > > >> When
>>>>> > > > >> > > you
>>>>> > > > >> > > > > > send
>>>>> > > > >> > > > > > > us
>>>>> > > > >> > > > > > > > PRs we will merge either to master or to a
>>>>> dedicated
>>>>> > > repo.
>>>>> > > > >> For
>>>>> > > > >> > > now
>>>>> > > > >> > > > it
>>>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of
>>>>>git.
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see
>>>>> it on
>>>>> > the
>>>>> > > > >> apache
>>>>> > > > >> > > > > servers
>>>>> > > > >> > > > > > > > (github sync seems to be off)
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>>>>> > > > >> > > pirwin@feature23.com>
>>>>> > > > >> > > > > > > wrote:
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on
>>>>> 4.3
>>>>> > > version
>>>>> > > > >> of
>>>>> > > > >> > the
>>>>> > > > >> > > > > > > Analysis
>>>>> > > > >> > > > > > > > > namespace.
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Not sure the checkout command is what you
>>>>> intended
>>>>> > --
>>>>> > > > you
>>>>> > > > >> > might
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > meant
>>>>> > > > >> > > > > > > > > trunk instead of master, and that would
>>>>>create
>>>>> a new
>>>>> > > > "3x"
>>>>> > > > >> > > branch,
>>>>> > > > >> > > > > > when
>>>>> > > > >> > > > > > > > > there's already a "branch_3x" and that
>>>>>would be
>>>>> > > > >> misnamed...
>>>>> > > > >> > so
>>>>> > > > >> > > > > maybe
>>>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
>>>>> aiming
>>>>> > for
>>>>> > > > >> lucene
>>>>> > > > >> > > > 4.3.x
>>>>> > > > >> > > > > > > > > compatibility?
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
>>>>> > upstream
>>>>> > > > >> want to
>>>>> > > > >> > > > > create
>>>>> > > > >> > > > > > > the
>>>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're
>>>>> not all
>>>>> > > > >> trying to
>>>>> > > > >> > > > > create
>>>>> > > > >> > > > > > > them
>>>>> > > > >> > > > > > > > > and dealing with a merge?
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > Paul
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>>>>> Syn-Hershko <
>>>>> > > > >> > > > > > itamar@code972.com
>>>>> > > > >> > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > > > > Unless people here have a specific reason
>>>>>to
>>>>> use
>>>>> > > > 3.6.2 I
>>>>> > > > >> > > would
>>>>> > > > >> > > > > > highly
>>>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
>>>>> towards v4
>>>>> > > > >> > otherwise
>>>>> > > > >> > > we
>>>>> > > > >> > > > > > will
>>>>> > > > >> > > > > > > > > never
>>>>> > > > >> > > > > > > > > > make it...
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > Fork the repo from apache servers or
>>>>>github
>>>>> (same
>>>>> > > > repo,
>>>>> > > > >> > > > different
>>>>> > > > >> > > > > > > > > remotes)
>>>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
>>>>> should
>>>>> > > work
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul
>>>>>Irwin <
>>>>> > > > >> > > > > pirwin@feature23.com>
>>>>> > > > >> > > > > > > > > wrote:
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > Itamar,
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > I agree that from scratch is not the
>>>>>best
>>>>> way to
>>>>> > > do
>>>>> > > > >> it, I
>>>>> > > > >> > > > just
>>>>> > > > >> > > > > > > > thought
>>>>> > > > >> > > > > > > > > > that
>>>>> > > > >> > > > > > > > > > > was the "decision" that was made from
>>>>>the
>>>>> > > discussion
>>>>> > > > >> > > > previously
>>>>> > > > >> > > > > > for
>>>>> > > > >> > > > > > > > the
>>>>> > > > >> > > > > > > > > > 4.x
>>>>> > > > >> > > > > > > > > > > work. An incremental approach will be
>>>>>much
>>>>> > better.
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
>>>>> branch on
>>>>> > > my
>>>>> > > > >> fork
>>>>> > > > >> > > and
>>>>> > > > >> > > > > will
>>>>> > > > >> > > > > > > > begin
>>>>> > > > >> > > > > > > > > > > working on bringing the Analysis
>>>>>namespace
>>>>> up to
>>>>> > > > >> speed to
>>>>> > > > >> > > > > 3.6.2.
>>>>> > > > >> > > > > > If
>>>>> > > > >> > > > > > > > > > anyone
>>>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts
>>>>>once
>>>>> I'm
>>>>> > > done,
>>>>> > > > >> have
>>>>> > > > >> > at
>>>>> > > > >> > > > it.
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
>>>>> branch_3x
>>>>> > > > branch,
>>>>> > > > >> > > please
>>>>> > > > >> > > > > let
>>>>> > > > >> > > > > > > me
>>>>> > > > >> > > > > > > > > know
>>>>> > > > >> > > > > > > > > > > what I should have branched from
>>>>>(trunk?)
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > Paul
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>>>>> > > Syn-Hershko <
>>>>> > > > >> > > > > > > > itamar@code972.com
>>>>> > > > >> > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
>>>>> again :)
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
>>>>> know
>>>>> > what
>>>>> > > > it
>>>>> > > > >> > would
>>>>> > > > >> > > > > take
>>>>> > > > >> > > > > > > > until
>>>>> > > > >> > > > > > > > > > they
>>>>> > > > >> > > > > > > > > > > > have deep dived into the work, and
>>>>>even
>>>>> then
>>>>> > > > >> decisions
>>>>> > > > >> > > > could
>>>>> > > > >> > > > > > and
>>>>> > > > >> > > > > > > > will
>>>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
>>>>> > starting
>>>>> > > > from
>>>>> > > > >> > > > scratch,
>>>>> > > > >> > > > > > > > > although
>>>>> > > > >> > > > > > > > > > I
>>>>> > > > >> > > > > > > > > > > do
>>>>> > > > >> > > > > > > > > > > > think a lot in the current structure
>>>>> should
>>>>> > > > change,
>>>>> > > > >> but
>>>>> > > > >> > > its
>>>>> > > > >> > > > > > going
>>>>> > > > >> > > > > > > > to
>>>>> > > > >> > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > much easier to change it in place,
>>>>> refactoring
>>>>> > > > where
>>>>> > > > >> > > > needed,
>>>>> > > > >> > > > > > than
>>>>> > > > >> > > > > > > > > > > starting
>>>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this
>>>>>off I
>>>>> > > > personally
>>>>> > > > >> > will
>>>>> > > > >> > > > be
>>>>> > > > >> > > > > > > happy
>>>>> > > > >> > > > > > > > > with
>>>>> > > > >> > > > > > > > > > > you
>>>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
>>>>> porting
>>>>> > > it,
>>>>> > > > >> its
>>>>> > > > >> > > > pretty
>>>>> > > > >> > > > > > > much
>>>>> > > > >> > > > > > > > > self
>>>>> > > > >> > > > > > > > > > > > contained.
>>>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that
>>>>>on
>>>>> a fork
>>>>> > > and
>>>>> > > > >> send
>>>>> > > > >> > > us
>>>>> > > > >> > > > > PRs,
>>>>> > > > >> > > > > > > its
>>>>> > > > >> > > > > > > > > > much
>>>>> > > > >> > > > > > > > > > > > more straight forward than the v4
>>>>>upgrade
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
>>>>> fastest
>>>>> > > way
>>>>> > > > >> to do
>>>>> > > > >> > > > this,
>>>>> > > > >> > > > > > we
>>>>> > > > >> > > > > > > > can
>>>>> > > > >> > > > > > > > > > then
>>>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and
>>>>>optimizing
>>>>> using
>>>>> > > > .NET
>>>>> > > > >> > > > > constructs.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
>>>>> create a
>>>>> > > > branch
>>>>> > > > >> out
>>>>> > > > >> > > of
>>>>> > > > >> > > > > the
>>>>> > > > >> > > > > > > > > current
>>>>> > > > >> > > > > > > > > > > git
>>>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and
>>>>>start
>>>>> > > working
>>>>> > > > on
>>>>> > > > >> > > master
>>>>> > > > >> > > > > > > > towards a
>>>>> > > > >> > > > > > > > > > 4.3
>>>>> > > > >> > > > > > > > > > > > compatible version. The actual port
>>>>> should be
>>>>> > > > using
>>>>> > > > >> a
>>>>> > > > >> > > > process
>>>>> > > > >> > > > > > > that
>>>>> > > > >> > > > > > > > > > > ensures
>>>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
>>>>> tests,
>>>>> > > and
>>>>> > > > >> that
>>>>> > > > >> > > > those
>>>>> > > > >> > > > > > > tests
>>>>> > > > >> > > > > > > > > > pass -
>>>>> > > > >> > > > > > > > > > > > but I'm against committing any Java
>>>>>code
>>>>> to
>>>>> > our
>>>>> > > > >> > > > repositories.
>>>>> > > > >> > > > > > The
>>>>> > > > >> > > > > > > > > > process
>>>>> > > > >> > > > > > > > > > > > should probably be working on classes
>>>>>in
>>>>> some
>>>>> > > > order
>>>>> > > > >> > > > > > > > (alphabetically,
>>>>> > > > >> > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > core classes first) and getting each
>>>>> class to
>>>>> > > > >> compile
>>>>> > > > >> > > > before
>>>>> > > > >> > > > > > > moving
>>>>> > > > >> > > > > > > > > > > > forward. I don't mind about the
>>>>>project
>>>>> not
>>>>> > > being
>>>>> > > > >> > > > compilable
>>>>> > > > >> > > > > > for
>>>>> > > > >> > > > > > > a
>>>>> > > > >> > > > > > > > > > month
>>>>> > > > >> > > > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > two.
>>>>> > > > >> > > > > > > > > > > > Once this is done a process of
>>>>> .NETifying and
>>>>> > > > >> proofing
>>>>> > > > >> > > the
>>>>> > > > >> > > > > code
>>>>> > > > >> > > > > > > can
>>>>> > > > >> > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > started, at which point we will
>>>>>already
>>>>> have a
>>>>> > > > >> working
>>>>> > > > >> > v4
>>>>> > > > >> > > > > > version
>>>>> > > > >> > > > > > > > so
>>>>> > > > >> > > > > > > > > it
>>>>> > > > >> > > > > > > > > > > > will be easier to keep up with the
>>>>>Java
>>>>> > project.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
>>>>> test
>>>>> > > suite
>>>>> > > > so
>>>>> > > > >> > > tests
>>>>> > > > >> > > > > > could
>>>>> > > > >> > > > > > > > more
>>>>> > > > >> > > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
>>>>> implementing
>>>>> > > > >> Java-like
>>>>> > > > >> > > > > > > assertEquals
>>>>> > > > >> > > > > > > > > > > methods
>>>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
>>>>> work
>>>>> > with
>>>>> > > > >> than
>>>>> > > > >> > > > > NUnit). I
>>>>> > > > >> > > > > > > > > already
>>>>> > > > >> > > > > > > > > > > did
>>>>> > > > >> > > > > > > > > > > > some work there but there's still a
>>>>>lot
>>>>> to do.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
>>>>> myself at
>>>>> > > this
>>>>> > > > >> > point,
>>>>> > > > >> > > > > but I
>>>>> > > > >> > > > > > > > > should
>>>>> > > > >> > > > > > > > > > be
>>>>> > > > >> > > > > > > > > > > > back in business in August, at which
>>>>> point I
>>>>> > can
>>>>> > > > >> > dedicate
>>>>> > > > >> > > > > > several
>>>>> > > > >> > > > > > > > > > hours a
>>>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to
>>>>>watch
>>>>> > closely
>>>>> > > > and
>>>>> > > > >> > even
>>>>> > > > >> > > > > > > coordinate
>>>>> > > > >> > > > > > > > > the
>>>>> > > > >> > > > > > > > > > > > work to some extent.
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM,
>>>>>Marcos
>>>>> Lima <
>>>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this
>>>>>is a
>>>>> kick
>>>>> > > > start
>>>>> > > > >> > =). I
>>>>> > > > >> > > > > > haven't
>>>>> > > > >> > > > > > > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > > > anything
>>>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you
>>>>>all
>>>>> to get
>>>>> > > > this
>>>>> > > > >> job
>>>>> > > > >> > > > done.
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
>>>>> Prescott.
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > I know that there is a high
>>>>>commitment
>>>>> for
>>>>> > > keep
>>>>> > > > >> the
>>>>> > > > >> > > > > > > > > > retrocompatibility
>>>>> > > > >> > > > > > > > > > > on
>>>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets
>>>>>big
>>>>> > changes
>>>>> > > > >> every
>>>>> > > > >> > > > > release?
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a
>>>>>stable
>>>>> > version
>>>>> > > > >> from a
>>>>> > > > >> > > > > Lucene
>>>>> > > > >> > > > > > > > > version,
>>>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only
>>>>> minor
>>>>> > > changes
>>>>> > > > >> > every
>>>>> > > > >> > > > > stable
>>>>> > > > >> > > > > > > > > release
>>>>> > > > >> > > > > > > > > > > (or
>>>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we
>>>>>could
>>>>> > > compare
>>>>> > > > >> the
>>>>> > > > >> > > > > versions,
>>>>> > > > >> > > > > > > > check
>>>>> > > > >> > > > > > > > > > the
>>>>> > > > >> > > > > > > > > > > > > differences and bring them to
>>>>> Lucene.Net.
>>>>> > > > Again, I
>>>>> > > > >> > > > haven't
>>>>> > > > >> > > > > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > > with
>>>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is
>>>>>(just an
>>>>> > idea).
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > What's your approach for implement
>>>>> simple
>>>>> > > > >> performance
>>>>> > > > >> > > > > > > > improvements
>>>>> > > > >> > > > > > > > > > > > (without
>>>>> > > > >> > > > > > > > > > > > > adding references or changing
>>>>>methods
>>>>> > > > signatures)?
>>>>> > > > >> > Does
>>>>> > > > >> > > > it
>>>>> > > > >> > > > > > > could
>>>>> > > > >> > > > > > > > be
>>>>> > > > >> > > > > > > > > > > done,
>>>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
>>>>> pirwin@feature23.com>
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > This is just an "outsider"
>>>>> suggestion as I
>>>>> > > > >> haven't
>>>>> > > > >> > > > > > > contributed
>>>>> > > > >> > > > > > > > > > > anything
>>>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely
>>>>>help
>>>>> with
>>>>> > > the
>>>>> > > > >> 4.x
>>>>> > > > >> > > work
>>>>> > > > >> > > > > as I
>>>>> > > > >> > > > > > > > have
>>>>> > > > >> > > > > > > > > a
>>>>> > > > >> > > > > > > > > > > > vested
>>>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
>>>>> completed. I
>>>>> > > think
>>>>> > > > >> > there
>>>>> > > > >> > > > > should
>>>>> > > > >> > > > > > > be
>>>>> > > > >> > > > > > > > > one
>>>>> > > > >> > > > > > > > > > > > person
>>>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
>>>>> > structure
>>>>> > > > and
>>>>> > > > >> > > > workflow
>>>>> > > > >> > > > > > will
>>>>> > > > >> > > > > > > > > look
>>>>> > > > >> > > > > > > > > > > like
>>>>> > > > >> > > > > > > > > > > > > to
>>>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is
>>>>> going to
>>>>> > be
>>>>> > > > >> > starting
>>>>> > > > >> > > > from
>>>>> > > > >> > > > > > > > scratch
>>>>> > > > >> > > > > > > > > > as
>>>>> > > > >> > > > > > > > > > > a
>>>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set
>>>>> up the
>>>>> > > > >> project,
>>>>> > > > >> > > get
>>>>> > > > >> > > > > > > > everything
>>>>> > > > >> > > > > > > > > > > going
>>>>> > > > >> > > > > > > > > > > > > in
>>>>> > > > >> > > > > > > > > > > > > > source control, create the folder
>>>>> > structure,
>>>>> > > > >> maybe
>>>>> > > > >> > > stub
>>>>> > > > >> > > > > out
>>>>> > > > >> > > > > > > > some
>>>>> > > > >> > > > > > > > > > > > classes,
>>>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
>>>>> anyone
>>>>> > > > >> interested
>>>>> > > > >> > > in
>>>>> > > > >> > > > > > > > > > contributing,
>>>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the
>>>>>java
>>>>> code
>>>>> > in
>>>>> > > > >> there
>>>>> > > > >> > so
>>>>> > > > >> > > > > it's
>>>>> > > > >> > > > > > > easy
>>>>> > > > >> > > > > > > > > to
>>>>> > > > >> > > > > > > > > > > > > > reference.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > Again, I can work on
>>>>> Lucene.Net.Documents,
>>>>> > > > >> > > > > > > Lucene.Net.Analysis,
>>>>> > > > >> > > > > > > > > or
>>>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
>>>>> those
>>>>> > are
>>>>> > > > >> just
>>>>> > > > >> > the
>>>>> > > > >> > > > > ones
>>>>> > > > >> > > > > > > I'm
>>>>> > > > >> > > > > > > > > most
>>>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
>>>>> Tell me
>>>>> > > what
>>>>> > > > >> to
>>>>> > > > >> > do
>>>>> > > > >> > > > and
>>>>> > > > >> > > > > > I'll
>>>>> > > > >> > > > > > > > get
>>>>> > > > >> > > > > > > > > > > > started
>>>>> > > > >> > > > > > > > > > > > > > on my fork.
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > Paul Irwin
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
>>>>> Prescott
>>>>> > > > Nasser
>>>>> > > > >> <
>>>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
>>>>> > > > >> > > > > > > > > > > > > > >wrote:
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > > > Hey guys -
>>>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
>>>>> while. We
>>>>> > > > have a
>>>>> > > > >> > > board
>>>>> > > > >> > > > > > report
>>>>> > > > >> > > > > > > > due
>>>>> > > > >> > > > > > > > > > > soon
>>>>> > > > >> > > > > > > > > > > > -
>>>>> > > > >> > > > > > > > > > > > > I
>>>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise
>>>>> them
>>>>> > that
>>>>> > > we
>>>>> > > > >> seem
>>>>> > > > >> > > to
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > > stalled
>>>>> > > > >> > > > > > > > > > > > > > somewhat.
>>>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging
>>>>>items
>>>>> out of
>>>>> > > of
>>>>> > > > >> jira
>>>>> > > > >> > > and
>>>>> > > > >> > > > > have
>>>>> > > > >> > > > > > > > been
>>>>> > > > >> > > > > > > > > > > > > responsive
>>>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
>>>>> > > questions,
>>>>> > > > >> but I
>>>>> > > > >> > > > don't
>>>>> > > > >> > > > > > > think
>>>>> > > > >> > > > > > > > > > we've
>>>>> > > > >> > > > > > > > > > > > > done
>>>>> > > > >> > > > > > > > > > > > > > > anything to move forward with
>>>>>4.0.
>>>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try*
>>>>>and
>>>>> > start
>>>>> > > us
>>>>> > > > >> back
>>>>> > > > >> > > up
>>>>> > > > >> > > > > > moving
>>>>> > > > >> > > > > > > > > > > forward.
>>>>> > > > >> > > > > > > > > > > > > What
>>>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish
>>>>> this? If
>>>>> > we
>>>>> > > > took
>>>>> > > > >> > the
>>>>> > > > >> > > > java
>>>>> > > > >> > > > > > > > lucene
>>>>> > > > >> > > > > > > > > > 4.0
>>>>> > > > >> > > > > > > > > > > > code
>>>>> > > > >> > > > > > > > > > > > > > and
>>>>> > > > >> > > > > > > > > > > > > > > committed that java to our
>>>>>branch
>>>>> and
>>>>> > then
>>>>> > > > >> just
>>>>> > > > >> > let
>>>>> > > > >> > > > > > people
>>>>> > > > >> > > > > > > > pull
>>>>> > > > >> > > > > > > > > > > that
>>>>> > > > >> > > > > > > > > > > > > down
>>>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying
>>>>>is
>>>>> that
>>>>> > one
>>>>> > > > >> way to
>>>>> > > > >> > > > maybe
>>>>> > > > >> > > > > > > make
>>>>> > > > >> > > > > > > > > some
>>>>> > > > >> > > > > > > > > > > > > forward
>>>>> > > > >> > > > > > > > > > > > > > > progress?
>>>>> > > > >> > > > > > > > > > > > > > > ~P
>>>>> > > > >> > > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > > > --
>>>>> > > > >> > > > > > > > > > > > > --
>>>>> > > > >> > > > > > > > > > > > > Marcos Lima
>>>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
>>>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>>>>> > > > >> > > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > > >
>>>>> > > > >> > > > > > > > > > >
>>>>> > > > >> > > > > > > > > >
>>>>> > > > >> > > > > > > > >
>>>>> > > > >> > > > > > > >
>>>>> > > > >> > > > > > >
>>>>> > > > >> > > > > >
>>>>> > > > >> > > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > >
>>>>> > > > >> > > > --
>>>>> > > > >> > > > --
>>>>> > > > >> > > > Marcos Lima
>>>>> > > > >> > > > Software Developer/Tech Lead
>>>>> > > > >> > > > marcoslimagon@gmail.com
>>>>> > > > >> > > > tel: +55 (19) 9798-9335
>>>>> > > > >> > > >
>>>>> > > > >> > >
>>>>> > > > >> >
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> --
>>>>> > > > >> --
>>>>> > > > >> Marcos Lima
>>>>> > > > >> Software Developer/Tech Lead
>>>>> > > > >> marcoslimagon@gmail.com
>>>>> > > > >> tel: +55 (19) 9798-9335
>>>>> > > > >>
>>>>> > > > >
>>>>> > > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
Re: Lucene 4.0
Posted by lo...@gmail.com.
Paul,
Paul,
I will work with you to integrate your code into the project repository. Do you have a contributor's agreement filed with the apache foundation?
Do you have a status of where you are and what else needs to get done? Also is there any specific help you need?
Scott
On Aug 8, 2013, at 4:54 PM, Itamar Syn-Hershko <it...@code972.com> wrote:
> Paul, people in the list are busy or in vacation. This doesn't mean the
> project is dead, especially since users like you keep lending a hand and
> help it move forward.
>
> I'll try to jump in soon, but you and your colleagues seem to be doing just
> fine. If you need anything from the project's resources, or when you think
> you are ready for a release, let us know.
>
>
> On Thu, Aug 8, 2013 at 10:31 PM, Paul Irwin <pi...@feature23.com> wrote:
>
>> Is this mailing list dead?! If anyone is interested in releasing an
>> up-to-date build of Lucene.net, please write back! If you didn't read my
>> other messages, I have Lucene.net Core working with Lucene java 4.3.1
>> compatibility thanks to the help of my colleagues. We just need to round
>> out the contrib modules, unit tests, and documentation as a community and
>> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
>> was packaged in December 2010!
>>
>> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
>> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
>> (where they now live in Lucene java, they were moved from core) and their
>> associated filters and tokenizers. I've briefly tested each and they seem
>> to work correctly. I've purposefully "Exclude[d] from Project" the other
>> language analyzers until we can forward-port them. So now the Analyzers DLL
>> compiles with those analyzers only. Also, I fixed the bug that was causing
>> NumericRangeQuery to not work.
>>
>> Next on my list is the QueryParsers contrib library (QueryParser was moved
>> out of Lucene java core) so that, combined with StandardAnalyzer, we can
>> test a pretty common real-world use case (the prototypical "hello lucene"
>> tutorial). After that, it might be worth forward-porting what we have so
>> far to 4.4 and use that as the latest point to finish out the port. The
>> changes shouldn't be too dramatic to core from what I can tell.
>>
>> My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>
>> I'll keep updating as I go, but if anyone wants to jump in, there's not a
>> better time than now...
>>
>>
>>
>> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>>> I made a dumb mistake... I have worked with StandardAnalyzer so long that
>>> I forgot that KeywordAnalyzer is not what I needed to be using, I needed
>> to
>>> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>>>
>>> Now it works after re-indexing with a quick, dirty implementation of
>>> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
>>> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on
>> to
>>> find out why NumericRangeQuery isn't working.
>>>
>>> Sorry for the blast of emails, but I wanted to prevent people from
>>> spending time hunting down my mistake!
>>>
>>>
>>> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
>> wrote:
>>>
>>>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>>>> byte being signed is a pain.
>>>>
>>>> Now there's no exception doing a TermQuery, but I also don't get any
>>>> results. It doesn't find any terms when scanning for them. I also tried
>> a
>>>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>>>> didn't find any results that way either. So right now only
>>>> MatchAllDocsQuery seems to work.
>>>>
>>>> If anyone would like to do a Google Hangout or anything sometime to look
>>>> into it, let me know.
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
>> wrote:
>>>>
>>>>> I realized after I sent that email last night that I could do as you
>>>>> described. When you've been debugging through
>> CorruptedIndexExceptions, you
>>>>> get a little bit of tunnel vision... haha
>>>>>
>>>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>>>> IndexSearcher and TopScoreDocsCollector and get hits! And
>> .ToString()'ing
>>>>> the matching documents prints the fields to the console, so it's
>> loading in
>>>>> the stored fields data correctly.
>>>>>
>>>>> I tried doing a TermQuery and now I get a "read past EOF" exception
>> that
>>>>> I can't figure out. There's a whole bunch of buffered byte array
>> operations
>>>>> going on and I can't determine where the issue came from. I'll keep
>>>>> looking, but if someone could grab my fork/branch and help me look that
>>>>> would be great. Here's example index writing and then reading code
>> (also
>>>>> included is a quick port of KeywordAnalyzer):
>>>>> https://gist.github.com/anonymous/6174164
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <
>> itamar@code972.com>wrote:
>>>>>
>>>>>> Great
>>>>>>
>>>>>> You can build you Query objects on your own to execute a search, you
>>>>>> don't
>>>>>> actually have to use QueryParser for that
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hey all, sorry it's been a little while, but I wanted to let you
>> know
>>>>>> that
>>>>>>> although I took a few weeks off from it, I now have a 4.3.1
>> equivalent
>>>>>>> Lucene.net core building and able to write a simple index in Lucene
>>>>>> 4.2
>>>>>>> codec and read in things like the number of documents and whatnot.
>>>>>> Since
>>>>>>> QueryParser has been moved to a separate module in Lucene Java 4.x,
>> I
>>>>>>> haven't ported that yet so I haven't done a real search, and I only
>>>>>> built
>>>>>>> the index using a quick port of KeywordAnalyzer which all those
>>>>>> analyzers
>>>>>>> have also moved to another module. But this is definitely good
>>>>>> progress and
>>>>>>> should be a launch point for finishing a 4.3/4.4 port.
>>>>>>>
>>>>>>> You can see my fork/branch here:
>>>>>>> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
>>>>>> like I
>>>>>>> said, only core builds now, no modules/tests build, so only open the
>>>>>>> Lucene.Net.Core.sln)
>>>>>>>
>>>>>>> I'm sure it's riddled with bugs, but I hope this can help kickstart
>>>>>> the
>>>>>>> community into finishing the 4.3/4.4 port. Let me know if you have
>> any
>>>>>>> questions, thanks!
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>>>>> itamar@code972.com
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> Paul, that's awesome. I will need some more time to go over this
>>>>>> thread
>>>>>>> and
>>>>>>>> your work to give actual feedback, SUPER busy at the moment
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pirwin@feature23.com
>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> My colleagues and I have made good progress on porting Lucene
>>>>>> 4.3's
>>>>>>> core
>>>>>>>>> library before, during, and after the hackathon last week. We
>> now
>>>>>> only
>>>>>>>> have
>>>>>>>>> some remaining items in Search, Index, and Codecs namespaces
>>>>>> (plus a
>>>>>>> few
>>>>>>>>> other minor ones here and there). I expect to be done by the end
>>>>>> of the
>>>>>>>>> weekend. Analysis, Documents, Store, Util (except some FST and
>>>>>> Packed),
>>>>>>>> and
>>>>>>>>> the root Codecs and Codecs.PerField namespaces are all now
>> "done".
>>>>>>>>>
>>>>>>>>> Again, my goal is to only get a buildable, experimental build of
>>>>>>>> Lucene.net
>>>>>>>>> with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>>>>>> porting
>>>>>>>> new
>>>>>>>>> javadoc comments or unit tests right now, due to the vast amount
>>>>>> of
>>>>>>> code
>>>>>>>>> that needs to be written just to get it to compile. If this work
>>>>>> ends
>>>>>>> up
>>>>>>>>> becoming a pull request, great, otherwise it should help
>>>>>> accelerate a
>>>>>>>> port
>>>>>>>>> of 4.3.x since the bulk of the work on core will already be done
>>>>>> and
>>>>>>>>> contributors can use it as a reference. And again, we're taking
>>>>>> the
>>>>>>>>> pragmatic approach of porting class-by-class,
>>>>>> namespace-by-namespace,
>>>>>>>> with
>>>>>>>>> the understanding that until we're done the project won't build.
>>>>>>>>>
>>>>>>>>> Once complete, I also will work on updating the Analyzers
>> contrib
>>>>>>> module
>>>>>>>>> and porting the QueryParsers contrib module, which I feel should
>>>>>> be
>>>>>>>>> included in the core NuGet package for Lucene.net as the core
>>>>>> library
>>>>>>> is
>>>>>>>>> now (post-4.0) practically useless (or atleast not turn-key)
>>>>>> without
>>>>>>>> them.
>>>>>>>>> You can check out the code on my fork/branch here:
>>>>>>>>> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>>>>>>
>>>>>>>>> In particular, I'd like some feedback on my work on ByteBuffer,
>>>>>>>>> MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
>>>>>> For the
>>>>>>>> MMap
>>>>>>>>> support, I created a ByteBuffer subclass that uses .NET 4's
>>>>>>>>> MemoryMappedFile support which should emulate the Java nio stuff
>>>>>> pretty
>>>>>>>>> well, but required some creative shuffling of the code to make
>> it
>>>>>> work
>>>>>>>> due
>>>>>>>>> to lifecycle management.
>>>>>>>>>
>>>>>>>>> I'll update again this weekend or next week, when we should have
>>>>>>> wrapped
>>>>>>>> up
>>>>>>>>> most of the main hacking on porting the core code.
>>>>>>>>>
>>>>>>>>> Paul
>>>>>>>>> On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <
>> pirwin@feature23.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Marcos,
>>>>>>>>>>
>>>>>>>>>> That would be helpful. As far as I can tell, the 3.0 java code
>>>>>> is
>>>>>>> only
>>>>>>>> on
>>>>>>>>>> SVN here, before the lucene and solr projects were bundled
>>>>>> together:
>>>>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>>>>>>>>>>
>>>>>>>>>> The SVN for 4.3 java is here:
>>>>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>>>>>>>>>> And the GitHub for 4.3 java is here:
>>>>>>>>>> https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>>>>>>>>>>
>>>>>>>>>> My fork/branch of Lucene.net for the 4.3 port is here:
>>>>>>>>>> https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>>>>>>>>>>
>>>>>>>>>> My fork is the "upstream" fork for my team members, and i'm
>>>>>> remote
>>>>>>>>> merging
>>>>>>>>>> their changes in from their forks while they fetch/merge from
>>>>>> mine to
>>>>>>>> get
>>>>>>>>>> everyone else's changes, rather than using pull requests.
>> James
>>>>>> and I
>>>>>>>>> have
>>>>>>>>>> been working the past few days on the Util namespace ahead of
>>>>>>> tonight's
>>>>>>>>>> hackathon since that namespace is in common with the rest of
>> the
>>>>>>>>>> namespaces. Tonight, we'll have at least 8 guys that I know of
>>>>>>> hacking
>>>>>>>> on
>>>>>>>>>> porting 4.3, each with a different namespace or part of a
>>>>>> namespace.
>>>>>>>>> Since
>>>>>>>>>> we're going class-by-class, namespace-by-namespace, the
>> project
>>>>>> does
>>>>>>>> not
>>>>>>>>>> build as it is. Once we finish doing a translation of each
>>>>>> file, then
>>>>>>>>> we'll
>>>>>>>>>> hammer out any remaining issues and get it to build again. I'm
>>>>>> hoping
>>>>>>>>> that
>>>>>>>>>> we can get at least 75% done with Core tonight. Wish us luck!
>>>>>>>>>>
>>>>>>>>>> But one thing to keep in mind is it looks like much
>>>>>> functionality has
>>>>>>>>> been
>>>>>>>>>> moved out of core into the contrib modules, especially around
>>>>>>> analysis,
>>>>>>>>> for
>>>>>>>>>> 4.0+. For example, there are no built-in analyzers in core
>>>>>> anymore.
>>>>>>> So
>>>>>>>>> when
>>>>>>>>>> this is all done, we may want to include at least the analysis
>>>>>>> contrib
>>>>>>>>>> module in with the standard core NuGet package, because
>>>>>> otherwise
>>>>>>> it's
>>>>>>>>>> practically useless unless you roll your own analyzer.
>>>>>>>>>>
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi everyone!
>>>>>>>>>>>
>>>>>>>>>>> Does someone know where can I find the 3.0.3 release from
>>>>>>>> Lucene(java)?
>>>>>>>>>>>
>>>>>>>>>>> I`ll compare the following major versions: 3.03, 3.6.2 and
>>>>>> 4.3.0 and
>>>>>>>>> make
>>>>>>>>>>> the diff between then and get all changes between
>> releases... I
>>>>>>> gonna
>>>>>>>>>>> publish it here soon. (If you think there is another
>> important
>>>>>>>> release,
>>>>>>>>>>> let
>>>>>>>>>>> me know)
>>>>>>>>>>>
>>>>>>>>>>> Paul, are you dealing (i`m not sure about this word, sorry)
>>>>>> with
>>>>>>> 4.3.0
>>>>>>>>>>> port
>>>>>>>>>>> for .Net on github (last email)?
>>>>>>>>>>>
>>>>>>>>>>> See you,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the discussion points, Michael.
>>>>>>>>>>>>
>>>>>>>>>>>> I would vote for not worrying about trying to achieve
>>>>>> portable
>>>>>>>>>>>> compatibility for WP8/WinRT/etc until *after* a port to
>> 4.3+
>>>>>> is
>>>>>>>>>>> completed.
>>>>>>>>>>>> Otherwise it may delay the project and stall it further.
>>>>>> That's
>>>>>>> just
>>>>>>>>> my
>>>>>>>>>>>> $0.02 based on my admittedly selfish need for 4.x features.
>>>>>>>>>>>>
>>>>>>>>>>>> I have started porting the changes from the core library
>>>>>> (from the
>>>>>>>>>>>> java lucene_solr_4_3 branch) in my fork on github in a
>>>>>> separate
>>>>>>>>> branch.
>>>>>>>>>>>> Since I need 4.3 ASAP, I am just going to keep going on my
>>>>>> port
>>>>>>>> until
>>>>>>>>>>>> there's changes to pull from upstream to work from. Also
>> due
>>>>>> to my
>>>>>>>>> time
>>>>>>>>>>>> constraints, I am not fully documenting new methods that
>> I'm
>>>>>>> adding.
>>>>>>>>>>> But if
>>>>>>>>>>>> anyone wants to pull/copy/reference my changes while
>> porting,
>>>>>>> that's
>>>>>>>>>>>> awesome. My branch currently does not build as I'm
>> primarily
>>>>>> going
>>>>>>>>>>>> class-by-class, starting with the util namespace. Once we
>>>>>> get the
>>>>>>>> ball
>>>>>>>>>>>> rolling on a community effort, I'll stop my rogue work and
>>>>>> join
>>>>>>> in.
>>>>>>>>> But
>>>>>>>>>>>> hopefully my work will be useful to someone, if not as a
>> pull
>>>>>>>> request
>>>>>>>>>>> then
>>>>>>>>>>>> as a reference. I'm also going to be holding a hackathon
>>>>>> this week
>>>>>>>>> with
>>>>>>>>>>> my
>>>>>>>>>>>> colleagues where we're all going to work on the port. I'm
>>>>>>> comparing
>>>>>>>>>>> files
>>>>>>>>>>>> and making changes as necessary, rather than starting from
>>>>>>> scratch.
>>>>>>>> My
>>>>>>>>>>>> repo/branch is here:
>>>>>>>>>>>> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>>>>>>>>>>
>>>>>>>>>>>> Paul
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>>>>>>>>>>>> mherndon@michaelherndon.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> the guithub.com repo is a mirror to the git mirror that
>>>>>> apache
>>>>>>>>>>>> maintains.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The was some work at one time to move the official svn
>>>>>>> repository
>>>>>>>> to
>>>>>>>>>>>> start
>>>>>>>>>>>>> using git one instead. Was that actually finalized or
>> not?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Lucene.Net_4e (e for experimental) is an old branch
>> to
>>>>>> see
>>>>>>>> what
>>>>>>>>>>> kind
>>>>>>>>>>>> of
>>>>>>>>>>>>> work was involved using a portable libraries project.
>> Some
>>>>>> of it
>>>>>>>> can
>>>>>>>>>>>> still
>>>>>>>>>>>>> be used but will need to be validated against the current
>>>>>>> version
>>>>>>>> of
>>>>>>>>>>>> Java's
>>>>>>>>>>>>> Lucene. It was also using .net 4.
>>>>>>>>>>>>>
>>>>>>>>>>>>> clean branch vs current. Its going to depend on what
>> we
>>>>>>>> support.
>>>>>>>>>>> If
>>>>>>>>>>>> you
>>>>>>>>>>>>> support windows mobile 8, win RT, then the current code
>> in
>>>>>> trunk
>>>>>>>>> will
>>>>>>>>>>> not
>>>>>>>>>>>>> compile against those versions of the framework which
>>>>>> would a
>>>>>>>>>>> frustrating
>>>>>>>>>>>>> starting point, then you couldn't even run tests, which
>>>>>> would
>>>>>>> make
>>>>>>>>>>> taking
>>>>>>>>>>>>> patches very difficult. Supporting those can almost mean
>>>>>> larger
>>>>>>>>> gaps
>>>>>>>>>>> in
>>>>>>>>>>>>> design between Lucene.Net and its parent project.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also the structure has changed significantly between the
>>>>>>> branches
>>>>>>>>> and
>>>>>>>>>>>> the
>>>>>>>>>>>>> side of the code base of Lucene 4 is bigger, uses Java 6,
>>>>>> and
>>>>>>>> seems
>>>>>>>>>>>>> significantly different. That doesn't mean you can't
>>>>>> cherry
>>>>>>> pick
>>>>>>>>>>> stuff
>>>>>>>>>>>>> from the other tags/branches that would still work as is.
>>>>>> A
>>>>>>> clean
>>>>>>>>>>> branch
>>>>>>>>>>>>> would also make it easier to get our build / tool chain
>> in
>>>>>> order
>>>>>>>> as
>>>>>>>>>>> you
>>>>>>>>>>>> can
>>>>>>>>>>>>> then do them incrementally versus having to do all the
>>>>>> stuff
>>>>>>> that
>>>>>>>> I
>>>>>>>>>>> did
>>>>>>>>>>>> for
>>>>>>>>>>>>> the 3x branch which saps energy and desire to code. It
>>>>>> could
>>>>>>>> also
>>>>>>>>>>> make
>>>>>>>>>>>> it
>>>>>>>>>>>>> easier to see which classes have been ported or not.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The major downside to a clean branch is extra work it
>>>>>> requires
>>>>>>> and
>>>>>>>>> the
>>>>>>>>>>>>> start up cost in time and energy of getting it in order,
>>>>>> which
>>>>>>> can
>>>>>>>>> be
>>>>>>>>>>>>> daunting / intimidating and lower morale. And generally
>>>>>> you want
>>>>>>>> to
>>>>>>>>>>> use
>>>>>>>>>>>>> take your legacy code and refactor instead of in someways
>>>>>>> starting
>>>>>>>>>>> over.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are we going to port lucene 4 or 4.3 ? If so I can do
>>>>>>> something
>>>>>>>>>>> similar
>>>>>>>>>>>>> to
>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>>>>>>>>>>>>> where it tracks what needs to get ported / what has been
>>>>>> ported.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What are we going to support in the next version?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Who is going to work on the next version?
>>>>>>>>>>>>>
>>>>>>>>>>>>> What would make the most sense and what would invigorate
>>>>>> the
>>>>>>>>>>> community to
>>>>>>>>>>>>> get involved more and lower the barrier to entry?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think those are the questions that would make a lot of
>>>>>> the
>>>>>>>>> decisions
>>>>>>>>>>>> for
>>>>>>>>>>>>> us so that we can get back to work on lucene.net.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>>>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regarding the new branch, I'm a rookie with ASF
>>>>>> projects...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The https://svn.apache.org/repos/asf/lucene.net/ and
>>>>>>>>>>>>>> https://github.com/apache/lucene.net points to the
>> same
>>>>>>>>> repository?
>>>>>>>>>>>>> (This
>>>>>>>>>>>>>> is new for me, pretty good) Which of them do you
>>>>>> recommend
>>>>>>> (i'm
>>>>>>>>> used
>>>>>>>>>>>> with
>>>>>>>>>>>>>> SVN and its patterns).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm checking the subversion right now.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can see the branches/Lucene.Net_4e. I think this is a
>>>>>> old
>>>>>>>>> branch,
>>>>>>>>>>> i`m
>>>>>>>>>>>>> not
>>>>>>>>>>>>>> sure about its current status.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Will we wipe the current solution from /trunk and start
>>>>>> a new
>>>>>>>> one?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2013/6/6 mherndon michael <mherndon@michaelherndon.com
>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We may be forced to start with a clean/empty branch
>> if
>>>>>>> people
>>>>>>>>>>> still
>>>>>>>>>>>>> want
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> attempt supporting lucene.net for mobile devices,
>> win
>>>>>> RT,
>>>>>>>> etc.
>>>>>>>>>>> The
>>>>>>>>>>>> are
>>>>>>>>>>>>>>> many
>>>>>>>>>>>>>>> classes that Lucene.net uses from the full framework
>>>>>> that
>>>>>>>> would
>>>>>>>>>>> not
>>>>>>>>>>>> be
>>>>>>>>>>>>>>> accessible in other versions of the .NET Framework.
>>>>>> It also
>>>>>>>>> might
>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>> a design that differs even more from its parent
>>>>>> project.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It might be wise to poll what users most desire in
>> the
>>>>>> next
>>>>>>>>>>> version
>>>>>>>>>>>>>> through
>>>>>>>>>>>>>>> jira or user voice.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>>>>>>>>>>>> itamar@code972.com
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> inline
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>>>>>>>>>>> pirwin@feature23.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ah, I gotcha. Still getting used to git, I've
>> been
>>>>>> a TFS
>>>>>>>> guy
>>>>>>>>>>> for
>>>>>>>>>>>> so
>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>> :-)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So to recap, the branch_3x will be used for any
>>>>>> patches
>>>>>>> or
>>>>>>>>>>>> anything
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> current 3.0.3 release, while trunk is what we
>> will
>>>>>>> branch
>>>>>>>>> from
>>>>>>>>>>>> for
>>>>>>>>>>>>> 4x
>>>>>>>>>>>>>>>> dev.
>>>>>>>>>>>>>>>>> Correct?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes - we can branch from it for 3.6 development if
>>>>>> anyone
>>>>>>>> will
>>>>>>>>>>> be
>>>>>>>>>>>>>>>> interested in that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for pushing the Version.cs. What's the
>> deal
>>>>>> with
>>>>>>>> the
>>>>>>>>>>>> github
>>>>>>>>>>>>>>> sync?
>>>>>>>>>>>>>>>>> Who could diagnose that?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not sure, Apache Infra, basically. Just use the
>>>>>> apache
>>>>>>> repo
>>>>>>>>> for
>>>>>>>>>>> now
>>>>>>>>>>>>>> while
>>>>>>>>>>>>>>>> we get that sorted out.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 6:00 PM, Itamar
>> Syn-Hershko
>>>>>> <
>>>>>>>>>>>>>> itamar@code972.com
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ok, haven't noticed that branch. Just use it
>>>>>> then for
>>>>>>>> 3.x
>>>>>>>>>>>>>>> development.
>>>>>>>>>>>>>>>>> WRT
>>>>>>>>>>>>>>>>>> v4, yeah - just fork the repo and work on
>>>>>> whatever
>>>>>>>> branch.
>>>>>>>>>>> When
>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>> send
>>>>>>>>>>>>>>>>> us
>>>>>>>>>>>>>>>>>> PRs we will merge either to master or to a
>>>>>> dedicated
>>>>>>>> repo.
>>>>>>>>>>> For
>>>>>>>>>>>>> now
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> doesn't really matter, thats the beauty of git.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I pushed a new Version.cs file, you should see
>>>>>> it on
>>>>>>> the
>>>>>>>>>>> apache
>>>>>>>>>>>>>>> servers
>>>>>>>>>>>>>>>>>> (github sync seems to be off)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>>>>>>>>>>>>> pirwin@feature23.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks Itamar. I can certainly start work on
>>>>>> 4.3
>>>>>>>> version
>>>>>>>>>>> of
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> Analysis
>>>>>>>>>>>>>>>>>>> namespace.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Not sure the checkout command is what you
>>>>>> intended
>>>>>>> --
>>>>>>>>> you
>>>>>>>>>>>> might
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> meant
>>>>>>>>>>>>>>>>>>> trunk instead of master, and that would
>> create
>>>>>> a new
>>>>>>>>> "3x"
>>>>>>>>>>>>> branch,
>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>> there's already a "branch_3x" and that would
>> be
>>>>>>>>>>> misnamed...
>>>>>>>>>>>> so
>>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>>>>>>> checkout -b branch_4x trunk and start there
>>>>>> aiming
>>>>>>> for
>>>>>>>>>>> lucene
>>>>>>>>>>>>>> 4.3.x
>>>>>>>>>>>>>>>>>>> compatibility?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Also, does someone with commit rights to the
>>>>>>> upstream
>>>>>>>>>>> want to
>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> necessary Version.cs entries, so that we're
>>>>>> not all
>>>>>>>>>>> trying to
>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>> and dealing with a merge?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>>>>>> Syn-Hershko <
>>>>>>>>>>>>>>>> itamar@code972.com
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Unless people here have a specific reason
>> to
>>>>>> use
>>>>>>>>> 3.6.2 I
>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>> highly
>>>>>>>>>>>>>>>>>>>> recommed putting all the efforts we can
>>>>>> towards v4
>>>>>>>>>>>> otherwise
>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> never
>>>>>>>>>>>>>>>>>>>> make it...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Fork the repo from apache servers or github
>>>>>> (same
>>>>>>>>> repo,
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>>>>> remotes)
>>>>>>>>>>>>>>>>>>>> and checkout -b 3x -t origin/master , that
>>>>>> should
>>>>>>>> work
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, Jun 7, 2013 at 12:20 AM, Paul
>> Irwin <
>>>>>>>>>>>>>>> pirwin@feature23.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Itamar,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I agree that from scratch is not the best
>>>>>> way to
>>>>>>>> do
>>>>>>>>>>> it, I
>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>> thought
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> was the "decision" that was made from the
>>>>>>>> discussion
>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> 4.x
>>>>>>>>>>>>>>>>>>>>> work. An incremental approach will be
>> much
>>>>>>> better.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I've created a branch of the branch_3x
>>>>>> branch on
>>>>>>>> my
>>>>>>>>>>> fork
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>> begin
>>>>>>>>>>>>>>>>>>>>> working on bringing the Analysis
>> namespace
>>>>>> up to
>>>>>>>>>>> speed to
>>>>>>>>>>>>>>> 3.6.2.
>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>>>> anyone
>>>>>>>>>>>>>>>>>>>>> wants to pull it or just reuse parts once
>>>>>> I'm
>>>>>>>> done,
>>>>>>>>>>> have
>>>>>>>>>>>> at
>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If I shouldn't have branched off the
>>>>>> branch_3x
>>>>>>>>> branch,
>>>>>>>>>>>>> please
>>>>>>>>>>>>>>> let
>>>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>> what I should have branched from (trunk?)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>>>>>>>> Syn-Hershko <
>>>>>>>>>>>>>>>>>> itamar@code972.com
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks Prescott for bringing this up
>>>>>> again :)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Paul, the problem is no one can really
>>>>>> know
>>>>>>> what
>>>>>>>>> it
>>>>>>>>>>>> would
>>>>>>>>>>>>>>> take
>>>>>>>>>>>>>>>>>> until
>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>> have deep dived into the work, and even
>>>>>> then
>>>>>>>>>>> decisions
>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>> change. I will strongly advise against
>>>>>>> starting
>>>>>>>>> from
>>>>>>>>>>>>>> scratch,
>>>>>>>>>>>>>>>>>>> although
>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>>>>>> think a lot in the current structure
>>>>>> should
>>>>>>>>> change,
>>>>>>>>>>> but
>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> much easier to change it in place,
>>>>>> refactoring
>>>>>>>>> where
>>>>>>>>>>>>>> needed,
>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>>>>> starting
>>>>>>>>>>>>>>>>>>>>>> all over again. Once we kicked this
>> off I
>>>>>>>>> personally
>>>>>>>>>>>> will
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> happy
>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>> taking the analysis part of Lucene and
>>>>>> porting
>>>>>>>> it,
>>>>>>>>>>> its
>>>>>>>>>>>>>> pretty
>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>>> self
>>>>>>>>>>>>>>>>>>>>>> contained.
>>>>>>>>>>>>>>>>>>>>>> Re 3.6.2 work - you can just do that on
>>>>>> a fork
>>>>>>>> and
>>>>>>>>>>> send
>>>>>>>>>>>>> us
>>>>>>>>>>>>>>> PRs,
>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>>>>>> more straight forward than the v4
>> upgrade
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Marcos, porting class by class is the
>>>>>> fastest
>>>>>>>> way
>>>>>>>>>>> to do
>>>>>>>>>>>>>> this,
>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>>>> concentrate on .NETifying and
>> optimizing
>>>>>> using
>>>>>>>>> .NET
>>>>>>>>>>>>>>> constructs.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That said, I think the way to go is
>>>>>> create a
>>>>>>>>> branch
>>>>>>>>>>> out
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>>> git
>>>>>>>>>>>>>>>>>>>>>> master HEAD and label it "3.x", and
>> start
>>>>>>>> working
>>>>>>>>> on
>>>>>>>>>>>>> master
>>>>>>>>>>>>>>>>>> towards a
>>>>>>>>>>>>>>>>>>>> 4.3
>>>>>>>>>>>>>>>>>>>>>> compatible version. The actual port
>>>>>> should be
>>>>>>>>> using
>>>>>>>>>>> a
>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> ensures
>>>>>>>>>>>>>>>>>>>>>> all Java classes are ported with their
>>>>>> tests,
>>>>>>>> and
>>>>>>>>>>> that
>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>>>>>> pass -
>>>>>>>>>>>>>>>>>>>>>> but I'm against committing any Java
>> code
>>>>>> to
>>>>>>> our
>>>>>>>>>>>>>> repositories.
>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>>> should probably be working on classes
>> in
>>>>>> some
>>>>>>>>> order
>>>>>>>>>>>>>>>>>> (alphabetically,
>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>> core classes first) and getting each
>>>>>> class to
>>>>>>>>>>> compile
>>>>>>>>>>>>>> before
>>>>>>>>>>>>>>>>> moving
>>>>>>>>>>>>>>>>>>>>>> forward. I don't mind about the project
>>>>>> not
>>>>>>>> being
>>>>>>>>>>>>>> compilable
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> month
>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>> two.
>>>>>>>>>>>>>>>>>>>>>> Once this is done a process of
>>>>>> .NETifying and
>>>>>>>>>>> proofing
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> started, at which point we will already
>>>>>> have a
>>>>>>>>>>> working
>>>>>>>>>>>> v4
>>>>>>>>>>>>>>>> version
>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> will be easier to keep up with the Java
>>>>>>> project.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The first step IMO is to stabilize the
>>>>>> test
>>>>>>>> suite
>>>>>>>>> so
>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>> less be copied and pasted (e.g.
>>>>>> implementing
>>>>>>>>>>> Java-like
>>>>>>>>>>>>>>>>> assertEquals
>>>>>>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>>>>>>>> etc; I find xUnit to be much easier to
>>>>>> work
>>>>>>> with
>>>>>>>>>>> than
>>>>>>>>>>>>>>> NUnit). I
>>>>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>>>>>>> did
>>>>>>>>>>>>>>>>>>>>>> some work there but there's still a lot
>>>>>> to do.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Unfortunately I can't dedicate time
>>>>>> myself at
>>>>>>>> this
>>>>>>>>>>>> point,
>>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> back in business in August, at which
>>>>>> point I
>>>>>>> can
>>>>>>>>>>>> dedicate
>>>>>>>>>>>>>>>> several
>>>>>>>>>>>>>>>>>>>> hours a
>>>>>>>>>>>>>>>>>>>>>> week. Until then I'll be happy to watch
>>>>>>> closely
>>>>>>>>> and
>>>>>>>>>>>> even
>>>>>>>>>>>>>>>>> coordinate
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> work to some extent.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 10:41 PM, Marcos
>>>>>> Lima <
>>>>>>>>>>>>>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It really sounds good to me, this is
>> a
>>>>>> kick
>>>>>>>>> start
>>>>>>>>>>>> =). I
>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>>>>>>> contributed
>>>>>>>>>>>>>>>>>>>>>>> anything
>>>>>>>>>>>>>>>>>>>>>>> yet, but I would like to help you all
>>>>>> to get
>>>>>>>>> this
>>>>>>>>>>> job
>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I'm completely agree with Paul and
>>>>>> Prescott.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I know that there is a high
>> commitment
>>>>>> for
>>>>>>>> keep
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> retrocompatibility
>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>> Lucene. Does Java Lucene API gets big
>>>>>>> changes
>>>>>>>>>>> every
>>>>>>>>>>>>>>> release?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Is the Lucene.Net a port from a
>> stable
>>>>>>> version
>>>>>>>>>>> from a
>>>>>>>>>>>>>>> Lucene
>>>>>>>>>>>>>>>>>>> version,
>>>>>>>>>>>>>>>>>>>>>>> right? If the Lucene API gets only
>>>>>> minor
>>>>>>>> changes
>>>>>>>>>>>> every
>>>>>>>>>>>>>>> stable
>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>> (or
>>>>>>>>>>>>>>>>>>>>>>> keep most of its source-code), we
>> could
>>>>>>>> compare
>>>>>>>>>>> the
>>>>>>>>>>>>>>> versions,
>>>>>>>>>>>>>>>>>> check
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> differences and bring them to
>>>>>> Lucene.Net.
>>>>>>>>> Again, I
>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>>>>> contributed
>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>> yet, so I don't know how it is (just
>> an
>>>>>>> idea).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> What's your approach for implement
>>>>>> simple
>>>>>>>>>>> performance
>>>>>>>>>>>>>>>>>> improvements
>>>>>>>>>>>>>>>>>>>>>> (without
>>>>>>>>>>>>>>>>>>>>>>> adding references or changing methods
>>>>>>>>> signatures)?
>>>>>>>>>>>> Does
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>> done,
>>>>>>>>>>>>>>>>>>>>>>> or "follow the java version only"?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2013/6/6 Paul Irwin <
>>>>>> pirwin@feature23.com>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> This is just an "outsider"
>>>>>> suggestion as I
>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>> contributed
>>>>>>>>>>>>>>>>>>>>> anything
>>>>>>>>>>>>>>>>>>>>>>>> yet, although I will definitely
>> help
>>>>>> with
>>>>>>>> the
>>>>>>>>>>> 4.x
>>>>>>>>>>>>> work
>>>>>>>>>>>>>>> as I
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>> vested
>>>>>>>>>>>>>>>>>>>>>>>> interest in seeing that get
>>>>>> completed. I
>>>>>>>> think
>>>>>>>>>>>> there
>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>>>>>> person
>>>>>>>>>>>>>>>>>>>>>>>> (or perhaps two) guiding what the
>>>>>>> structure
>>>>>>>>> and
>>>>>>>>>>>>>> workflow
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> look
>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> avoid chaos. If the 4.x work is
>>>>>> going to
>>>>>>> be
>>>>>>>>>>>> starting
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>> scratch
>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>> fresh port, that person should set
>>>>>> up the
>>>>>>>>>>> project,
>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>> everything
>>>>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>> source control, create the folder
>>>>>>> structure,
>>>>>>>>>>> maybe
>>>>>>>>>>>>> stub
>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>> classes,
>>>>>>>>>>>>>>>>>>>>>>>> etc. Then divide and conquer with
>>>>>> anyone
>>>>>>>>>>> interested
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> contributing,
>>>>>>>>>>>>>>>>>>>>>>>> perhaps by namespace.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I like the idea of throwing the
>> java
>>>>>> code
>>>>>>> in
>>>>>>>>>>> there
>>>>>>>>>>>> so
>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> reference.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Again, I can work on
>>>>>> Lucene.Net.Documents,
>>>>>>>>>>>>>>>>> Lucene.Net.Analysis,
>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>> Lucene.Net.Store -- or any others,
>>>>>> those
>>>>>>> are
>>>>>>>>>>> just
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> ones
>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>> most
>>>>>>>>>>>>>>>>>>>>>>>> familiar with the inner workings.
>>>>>> Tell me
>>>>>>>> what
>>>>>>>>>>> to
>>>>>>>>>>>> do
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>>>> started
>>>>>>>>>>>>>>>>>>>>>>>> on my fork.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Paul Irwin
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jun 6, 2013 at 2:38 PM,
>>>>>> Prescott
>>>>>>>>> Nasser
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>> geobmx540@hotmail.com
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hey guys -
>>>>>>>>>>>>>>>>>>>>>>>>> I know I've been MIA a little
>>>>>> while. We
>>>>>>>>> have a
>>>>>>>>>>>>> board
>>>>>>>>>>>>>>>> report
>>>>>>>>>>>>>>>>>> due
>>>>>>>>>>>>>>>>>>>>> soon
>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>> think it prudent that we advise
>>>>>> them
>>>>>>> that
>>>>>>>> we
>>>>>>>>>>> seem
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> stalled
>>>>>>>>>>>>>>>>>>>>>>>> somewhat.
>>>>>>>>>>>>>>>>>>>>>>>>> We've got a few low hanging items
>>>>>> out of
>>>>>>>> of
>>>>>>>>>>> jira
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>> responsive
>>>>>>>>>>>>>>>>>>>>>>>>> on the mailing list to community
>>>>>>>> questions,
>>>>>>>>>>> but I
>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>> we've
>>>>>>>>>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>>>>>>>>>>> anything to move forward with
>> 4.0.
>>>>>>>>>>>>>>>>>>>>>>>>> To that end - I'd like to *try*
>> and
>>>>>>> start
>>>>>>>> us
>>>>>>>>>>> back
>>>>>>>>>>>>> up
>>>>>>>>>>>>>>>> moving
>>>>>>>>>>>>>>>>>>>>> forward.
>>>>>>>>>>>>>>>>>>>>>>> What
>>>>>>>>>>>>>>>>>>>>>>>>> is the best way to accomplish
>>>>>> this? If
>>>>>>> we
>>>>>>>>> took
>>>>>>>>>>>> the
>>>>>>>>>>>>>> java
>>>>>>>>>>>>>>>>>> lucene
>>>>>>>>>>>>>>>>>>>> 4.0
>>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> committed that java to our branch
>>>>>> and
>>>>>>> then
>>>>>>>>>>> just
>>>>>>>>>>>> let
>>>>>>>>>>>>>>>> people
>>>>>>>>>>>>>>>>>> pull
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> down
>>>>>>>>>>>>>>>>>>>>>>>>> and being changing / modifying is
>>>>>> that
>>>>>>> one
>>>>>>>>>>> way to
>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>>>>>>>>>>> progress?
>>>>>>>>>>>>>>>>>>>>>>>>> ~P
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Marcos Lima
>>>>>>>>>>>>>>>>>>>>>>> Software Developer/Tech Lead
>>>>>>>>>>>>>>>>>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>>>>>>>>>>>>>>> tel: +55 (19) 9798-9335
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Marcos Lima
>>>>>>>>>>>>>> Software Developer/Tech Lead
>>>>>>>>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>>>>>> tel: +55 (19) 9798-9335
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> --
>>>>>>>>>>> Marcos Lima
>>>>>>>>>>> Software Developer/Tech Lead
>>>>>>>>>>> marcoslimagon@gmail.com
>>>>>>>>>>> tel: +55 (19) 9798-9335
>>
Re: Lucene 4.0
Posted by Itamar Syn-Hershko <it...@code972.com>.
Paul, people in the list are busy or in vacation. This doesn't mean the
project is dead, especially since users like you keep lending a hand and
help it move forward.
I'll try to jump in soon, but you and your colleagues seem to be doing just
fine. If you need anything from the project's resources, or when you think
you are ready for a release, let us know.
On Thu, Aug 8, 2013 at 10:31 PM, Paul Irwin <pi...@feature23.com> wrote:
> Is this mailing list dead?! If anyone is interested in releasing an
> up-to-date build of Lucene.net, please write back! If you didn't read my
> other messages, I have Lucene.net Core working with Lucene java 4.3.1
> compatibility thanks to the help of my colleagues. We just need to round
> out the contrib modules, unit tests, and documentation as a community and
> we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
> was packaged in December 2010!
>
> I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
> ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
> (where they now live in Lucene java, they were moved from core) and their
> associated filters and tokenizers. I've briefly tested each and they seem
> to work correctly. I've purposefully "Exclude[d] from Project" the other
> language analyzers until we can forward-port them. So now the Analyzers DLL
> compiles with those analyzers only. Also, I fixed the bug that was causing
> NumericRangeQuery to not work.
>
> Next on my list is the QueryParsers contrib library (QueryParser was moved
> out of Lucene java core) so that, combined with StandardAnalyzer, we can
> test a pretty common real-world use case (the prototypical "hello lucene"
> tutorial). After that, it might be worth forward-porting what we have so
> far to 4.4 and use that as the latest point to finish out the port. The
> changes shouldn't be too dramatic to core from what I can tell.
>
> My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
> I'll keep updating as I go, but if anyone wants to jump in, there's not a
> better time than now...
>
>
>
> On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
>
> > I made a dumb mistake... I have worked with StandardAnalyzer so long that
> > I forgot that KeywordAnalyzer is not what I needed to be using, I needed
> to
> > use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
> >
> > Now it works after re-indexing with a quick, dirty implementation of
> > WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
> > also be read and searched by Java Lucene 4.3.1. Now I'm going to move on
> to
> > find out why NumericRangeQuery isn't working.
> >
> > Sorry for the blast of emails, but I wanted to prevent people from
> > spending time hunting down my mistake!
> >
> >
> > On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >
> >> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
> >> byte being signed is a pain.
> >>
> >> Now there's no exception doing a TermQuery, but I also don't get any
> >> results. It doesn't find any terms when scanning for them. I also tried
> a
> >> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
> >> didn't find any results that way either. So right now only
> >> MatchAllDocsQuery seems to work.
> >>
> >> If anyone would like to do a Google Hangout or anything sometime to look
> >> into it, let me know.
> >>
> >>
> >> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >>
> >>> I realized after I sent that email last night that I could do as you
> >>> described. When you've been debugging through
> CorruptedIndexExceptions, you
> >>> get a little bit of tunnel vision... haha
> >>>
> >>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
> >>> IndexSearcher and TopScoreDocsCollector and get hits! And
> .ToString()'ing
> >>> the matching documents prints the fields to the console, so it's
> loading in
> >>> the stored fields data correctly.
> >>>
> >>> I tried doing a TermQuery and now I get a "read past EOF" exception
> that
> >>> I can't figure out. There's a whole bunch of buffered byte array
> operations
> >>> going on and I can't determine where the issue came from. I'll keep
> >>> looking, but if someone could grab my fork/branch and help me look that
> >>> would be great. Here's example index writing and then reading code
> (also
> >>> included is a quick port of KeywordAnalyzer):
> >>> https://gist.github.com/anonymous/6174164
> >>>
> >>> Thanks!
> >>>
> >>>
> >>>
> >>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <
> itamar@code972.com>wrote:
> >>>
> >>>> Great
> >>>>
> >>>> You can build you Query objects on your own to execute a search, you
> >>>> don't
> >>>> actually have to use QueryParser for that
> >>>>
> >>>>
> >>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
> >>>> wrote:
> >>>>
> >>>> > Hey all, sorry it's been a little while, but I wanted to let you
> know
> >>>> that
> >>>> > although I took a few weeks off from it, I now have a 4.3.1
> equivalent
> >>>> > Lucene.net core building and able to write a simple index in Lucene
> >>>> 4.2
> >>>> > codec and read in things like the number of documents and whatnot.
> >>>> Since
> >>>> > QueryParser has been moved to a separate module in Lucene Java 4.x,
> I
> >>>> > haven't ported that yet so I haven't done a real search, and I only
> >>>> built
> >>>> > the index using a quick port of KeywordAnalyzer which all those
> >>>> analyzers
> >>>> > have also moved to another module. But this is definitely good
> >>>> progress and
> >>>> > should be a launch point for finishing a 4.3/4.4 port.
> >>>> >
> >>>> > You can see my fork/branch here:
> >>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
> >>>> like I
> >>>> > said, only core builds now, no modules/tests build, so only open the
> >>>> > Lucene.Net.Core.sln)
> >>>> >
> >>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
> >>>> the
> >>>> > community into finishing the 4.3/4.4 port. Let me know if you have
> any
> >>>> > questions, thanks!
> >>>> >
> >>>> >
> >>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
> >>>> itamar@code972.com
> >>>> > >wrote:
> >>>> >
> >>>> > > Paul, that's awesome. I will need some more time to go over this
> >>>> thread
> >>>> > and
> >>>> > > your work to give actual feedback, SUPER busy at the moment
> >>>> > >
> >>>> > >
> >>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pirwin@feature23.com
> >
> >>>> > wrote:
> >>>> > >
> >>>> > > > All,
> >>>> > > >
> >>>> > > > My colleagues and I have made good progress on porting Lucene
> >>>> 4.3's
> >>>> > core
> >>>> > > > library before, during, and after the hackathon last week. We
> now
> >>>> only
> >>>> > > have
> >>>> > > > some remaining items in Search, Index, and Codecs namespaces
> >>>> (plus a
> >>>> > few
> >>>> > > > other minor ones here and there). I expect to be done by the end
> >>>> of the
> >>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
> >>>> Packed),
> >>>> > > and
> >>>> > > > the root Codecs and Codecs.PerField namespaces are all now
> "done".
> >>>> > > >
> >>>> > > > Again, my goal is to only get a buildable, experimental build of
> >>>> > > Lucene.net
> >>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
> >>>> porting
> >>>> > > new
> >>>> > > > javadoc comments or unit tests right now, due to the vast amount
> >>>> of
> >>>> > code
> >>>> > > > that needs to be written just to get it to compile. If this work
> >>>> ends
> >>>> > up
> >>>> > > > becoming a pull request, great, otherwise it should help
> >>>> accelerate a
> >>>> > > port
> >>>> > > > of 4.3.x since the bulk of the work on core will already be done
> >>>> and
> >>>> > > > contributors can use it as a reference. And again, we're taking
> >>>> the
> >>>> > > > pragmatic approach of porting class-by-class,
> >>>> namespace-by-namespace,
> >>>> > > with
> >>>> > > > the understanding that until we're done the project won't build.
> >>>> > > >
> >>>> > > > Once complete, I also will work on updating the Analyzers
> contrib
> >>>> > module
> >>>> > > > and porting the QueryParsers contrib module, which I feel should
> >>>> be
> >>>> > > > included in the core NuGet package for Lucene.net as the core
> >>>> library
> >>>> > is
> >>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
> >>>> without
> >>>> > > them.
> >>>> > > > You can check out the code on my fork/branch here:
> >>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >>>> > > >
> >>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
> >>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
> >>>> For the
> >>>> > > MMap
> >>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
> >>>> > > > MemoryMappedFile support which should emulate the Java nio stuff
> >>>> pretty
> >>>> > > > well, but required some creative shuffling of the code to make
> it
> >>>> work
> >>>> > > due
> >>>> > > > to lifecycle management.
> >>>> > > >
> >>>> > > > I'll update again this weekend or next week, when we should have
> >>>> > wrapped
> >>>> > > up
> >>>> > > > most of the main hacking on porting the core code.
> >>>> > > >
> >>>> > > > Paul
> >>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <
> pirwin@feature23.com
> >>>> >
> >>>> > > wrote:
> >>>> > > >
> >>>> > > > > Marcos,
> >>>> > > > >
> >>>> > > > > That would be helpful. As far as I can tell, the 3.0 java code
> >>>> is
> >>>> > only
> >>>> > > on
> >>>> > > > > SVN here, before the lucene and solr projects were bundled
> >>>> together:
> >>>> > > > >
> >>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> >>>> > > > >
> >>>> > > > > The SVN for 4.3 java is here:
> >>>> > > > >
> >>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> >>>> > > > > And the GitHub for 4.3 java is here:
> >>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> >>>> > > > >
> >>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
> >>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> >>>> > > > >
> >>>> > > > > My fork is the "upstream" fork for my team members, and i'm
> >>>> remote
> >>>> > > > merging
> >>>> > > > > their changes in from their forks while they fetch/merge from
> >>>> mine to
> >>>> > > get
> >>>> > > > > everyone else's changes, rather than using pull requests.
> James
> >>>> and I
> >>>> > > > have
> >>>> > > > > been working the past few days on the Util namespace ahead of
> >>>> > tonight's
> >>>> > > > > hackathon since that namespace is in common with the rest of
> the
> >>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
> >>>> > hacking
> >>>> > > on
> >>>> > > > > porting 4.3, each with a different namespace or part of a
> >>>> namespace.
> >>>> > > > Since
> >>>> > > > > we're going class-by-class, namespace-by-namespace, the
> project
> >>>> does
> >>>> > > not
> >>>> > > > > build as it is. Once we finish doing a translation of each
> >>>> file, then
> >>>> > > > we'll
> >>>> > > > > hammer out any remaining issues and get it to build again. I'm
> >>>> hoping
> >>>> > > > that
> >>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
> >>>> > > > >
> >>>> > > > > But one thing to keep in mind is it looks like much
> >>>> functionality has
> >>>> > > > been
> >>>> > > > > moved out of core into the contrib modules, especially around
> >>>> > analysis,
> >>>> > > > for
> >>>> > > > > 4.0+. For example, there are no built-in analyzers in core
> >>>> anymore.
> >>>> > So
> >>>> > > > when
> >>>> > > > > this is all done, we may want to include at least the analysis
> >>>> > contrib
> >>>> > > > > module in with the standard core NuGet package, because
> >>>> otherwise
> >>>> > it's
> >>>> > > > > practically useless unless you roll your own analyzer.
> >>>> > > > >
> >>>> > > > > Paul
> >>>> > > > >
> >>>> > > > >
> >>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
> >>>> > marcoslimagon@gmail.com
> >>>> > > > >wrote:
> >>>> > > > >
> >>>> > > > >> Hi everyone!
> >>>> > > > >>
> >>>> > > > >> Does someone know where can I find the 3.0.3 release from
> >>>> > > Lucene(java)?
> >>>> > > > >>
> >>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
> >>>> 4.3.0 and
> >>>> > > > make
> >>>> > > > >> the diff between then and get all changes between
> releases... I
> >>>> > gonna
> >>>> > > > >> publish it here soon. (If you think there is another
> important
> >>>> > > release,
> >>>> > > > >> let
> >>>> > > > >> me know)
> >>>> > > > >>
> >>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry)
> >>>> with
> >>>> > 4.3.0
> >>>> > > > >> port
> >>>> > > > >> for .Net on github (last email)?
> >>>> > > > >>
> >>>> > > > >> See you,
> >>>> > > > >>
> >>>> > > > >>
> >>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> >>>> > > > >>
> >>>> > > > >> > Thanks for the discussion points, Michael.
> >>>> > > > >> >
> >>>> > > > >> > I would vote for not worrying about trying to achieve
> >>>> portable
> >>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to
> 4.3+
> >>>> is
> >>>> > > > >> completed.
> >>>> > > > >> > Otherwise it may delay the project and stall it further.
> >>>> That's
> >>>> > just
> >>>> > > > my
> >>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
> >>>> > > > >> >
> >>>> > > > >> > I have started porting the changes from the core library
> >>>> (from the
> >>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
> >>>> separate
> >>>> > > > branch.
> >>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
> >>>> port
> >>>> > > until
> >>>> > > > >> > there's changes to pull from upstream to work from. Also
> due
> >>>> to my
> >>>> > > > time
> >>>> > > > >> > constraints, I am not fully documenting new methods that
> I'm
> >>>> > adding.
> >>>> > > > >> But if
> >>>> > > > >> > anyone wants to pull/copy/reference my changes while
> porting,
> >>>> > that's
> >>>> > > > >> > awesome. My branch currently does not build as I'm
> primarily
> >>>> going
> >>>> > > > >> > class-by-class, starting with the util namespace. Once we
> >>>> get the
> >>>> > > ball
> >>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
> >>>> join
> >>>> > in.
> >>>> > > > But
> >>>> > > > >> > hopefully my work will be useful to someone, if not as a
> pull
> >>>> > > request
> >>>> > > > >> then
> >>>> > > > >> > as a reference. I'm also going to be holding a hackathon
> >>>> this week
> >>>> > > > with
> >>>> > > > >> my
> >>>> > > > >> > colleagues where we're all going to work on the port. I'm
> >>>> > comparing
> >>>> > > > >> files
> >>>> > > > >> > and making changes as necessary, rather than starting from
> >>>> > scratch.
> >>>> > > My
> >>>> > > > >> > repo/branch is here:
> >>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >>>> > > > >> >
> >>>> > > > >> > Paul
> >>>> > > > >> >
> >>>> > > > >> >
> >>>> > > > >> >
> >>>> > > > >> >
> >>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> >>>> > > > >> > mherndon@michaelherndon.com> wrote:
> >>>> > > > >> >
> >>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
> >>>> apache
> >>>> > > > >> > maintains.
> >>>> > > > >> > >
> >>>> > > > >> > > The was some work at one time to move the official svn
> >>>> > repository
> >>>> > > to
> >>>> > > > >> > start
> >>>> > > > >> > > using git one instead. Was that actually finalized or
> not?
> >>>> > > > >> > >
> >>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch
> to
> >>>> see
> >>>> > > what
> >>>> > > > >> kind
> >>>> > > > >> > of
> >>>> > > > >> > > work was involved using a portable libraries project.
> Some
> >>>> of it
> >>>> > > can
> >>>> > > > >> > still
> >>>> > > > >> > > be used but will need to be validated against the current
> >>>> > version
> >>>> > > of
> >>>> > > > >> > Java's
> >>>> > > > >> > > Lucene. It was also using .net 4.
> >>>> > > > >> > >
> >>>> > > > >> > > clean branch vs current. Its going to depend on what
> we
> >>>> > > support.
> >>>> > > > >> If
> >>>> > > > >> > you
> >>>> > > > >> > > support windows mobile 8, win RT, then the current code
> in
> >>>> trunk
> >>>> > > > will
> >>>> > > > >> not
> >>>> > > > >> > > compile against those versions of the framework which
> >>>> would a
> >>>> > > > >> frustrating
> >>>> > > > >> > > starting point, then you couldn't even run tests, which
> >>>> would
> >>>> > make
> >>>> > > > >> taking
> >>>> > > > >> > > patches very difficult. Supporting those can almost mean
> >>>> larger
> >>>> > > > gaps
> >>>> > > > >> in
> >>>> > > > >> > > design between Lucene.Net and its parent project.
> >>>> > > > >> > >
> >>>> > > > >> > > Also the structure has changed significantly between the
> >>>> > branches
> >>>> > > > and
> >>>> > > > >> > the
> >>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6,
> >>>> and
> >>>> > > seems
> >>>> > > > >> > > significantly different. That doesn't mean you can't
> >>>> cherry
> >>>> > pick
> >>>> > > > >> stuff
> >>>> > > > >> > > from the other tags/branches that would still work as is.
> >>>> A
> >>>> > clean
> >>>> > > > >> branch
> >>>> > > > >> > > would also make it easier to get our build / tool chain
> in
> >>>> order
> >>>> > > as
> >>>> > > > >> you
> >>>> > > > >> > can
> >>>> > > > >> > > then do them incrementally versus having to do all the
> >>>> stuff
> >>>> > that
> >>>> > > I
> >>>> > > > >> did
> >>>> > > > >> > for
> >>>> > > > >> > > the 3x branch which saps energy and desire to code. It
> >>>> could
> >>>> > > also
> >>>> > > > >> make
> >>>> > > > >> > it
> >>>> > > > >> > > easier to see which classes have been ported or not.
> >>>> > > > >> > >
> >>>> > > > >> > > The major downside to a clean branch is extra work it
> >>>> requires
> >>>> > and
> >>>> > > > the
> >>>> > > > >> > > start up cost in time and energy of getting it in order,
> >>>> which
> >>>> > can
> >>>> > > > be
> >>>> > > > >> > > daunting / intimidating and lower morale. And generally
> >>>> you want
> >>>> > > to
> >>>> > > > >> use
> >>>> > > > >> > > take your legacy code and refactor instead of in someways
> >>>> > starting
> >>>> > > > >> over.
> >>>> > > > >> > >
> >>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
> >>>> > something
> >>>> > > > >> similar
> >>>> > > > >> > > to
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> >
> >>>> > > > >>
> >>>> > > >
> >>>> > >
> >>>> >
> >>>>
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> >>>> > > > >> > > where it tracks what needs to get ported / what has been
> >>>> ported.
> >>>> > > > >> > >
> >>>> > > > >> > > What are we going to support in the next version?
> >>>> > > > >> > >
> >>>> > > > >> > > Who is going to work on the next version?
> >>>> > > > >> > >
> >>>> > > > >> > > What would make the most sense and what would invigorate
> >>>> the
> >>>> > > > >> community to
> >>>> > > > >> > > get involved more and lower the barrier to entry?
> >>>> > > > >> > >
> >>>> > > > >> > > I think those are the questions that would make a lot of
> >>>> the
> >>>> > > > decisions
> >>>> > > > >> > for
> >>>> > > > >> > > us so that we can get back to work on lucene.net.
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > >
> >>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> >>>> > > > marcoslimagon@gmail.com
> >>>> > > > >> > > >wrote:
> >>>> > > > >> > >
> >>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
> >>>> projects...
> >>>> > > > >> > > >
> >>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> >>>> > > > >> > > > https://github.com/apache/lucene.net points to the
> same
> >>>> > > > repository?
> >>>> > > > >> > > (This
> >>>> > > > >> > > > is new for me, pretty good) Which of them do you
> >>>> recommend
> >>>> > (i'm
> >>>> > > > used
> >>>> > > > >> > with
> >>>> > > > >> > > > SVN and its patterns).
> >>>> > > > >> > > >
> >>>> > > > >> > > > I'm checking the subversion right now.
> >>>> > > > >> > > >
> >>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a
> >>>> old
> >>>> > > > branch,
> >>>> > > > >> i`m
> >>>> > > > >> > > not
> >>>> > > > >> > > > sure about its current status.
> >>>> > > > >> > > >
> >>>> > > > >> > > > Will we wipe the current solution from /trunk and start
> >>>> a new
> >>>> > > one?
> >>>> > > > >> > > >
> >>>> > > > >> > > > Thanks,
> >>>> > > > >> > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > > 2013/6/6 mherndon michael <mherndon@michaelherndon.com
> >
> >>>> > > > >> > > >
> >>>> > > > >> > > > > We may be forced to start with a clean/empty branch
> if
> >>>> > people
> >>>> > > > >> still
> >>>> > > > >> > > want
> >>>> > > > >> > > > to
> >>>> > > > >> > > > > attempt supporting lucene.net for mobile devices,
> win
> >>>> RT,
> >>>> > > etc.
> >>>> > > > >> The
> >>>> > > > >> > are
> >>>> > > > >> > > > > many
> >>>> > > > >> > > > > classes that Lucene.net uses from the full framework
> >>>> that
> >>>> > > would
> >>>> > > > >> not
> >>>> > > > >> > be
> >>>> > > > >> > > > > accessible in other versions of the .NET Framework.
> >>>> It also
> >>>> > > > might
> >>>> > > > >> > > > require
> >>>> > > > >> > > > > a design that differs even more from its parent
> >>>> project.
> >>>> > > > >> > > > >
> >>>> > > > >> > > > > It might be wise to poll what users most desire in
> the
> >>>> next
> >>>> > > > >> version
> >>>> > > > >> > > > through
> >>>> > > > >> > > > > jira or user voice.
> >>>> > > > >> > > > >
> >>>> > > > >> > > > >
> >>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> >>>> > > > >> > itamar@code972.com
> >>>> > > > >> > > > > >wrote:
> >>>> > > > >> > > > >
> >>>> > > > >> > > > > > inline
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> >>>> > > > >> pirwin@feature23.com>
> >>>> > > > >> > > > wrote:
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've
> been
> >>>> a TFS
> >>>> > > guy
> >>>> > > > >> for
> >>>> > > > >> > so
> >>>> > > > >> > > > > long
> >>>> > > > >> > > > > > > :-)
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
> >>>> patches
> >>>> > or
> >>>> > > > >> > anything
> >>>> > > > >> > > > to
> >>>> > > > >> > > > > > the
> >>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we
> will
> >>>> > branch
> >>>> > > > from
> >>>> > > > >> > for
> >>>> > > > >> > > 4x
> >>>> > > > >> > > > > > dev.
> >>>> > > > >> > > > > > > Correct?
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
> >>>> anyone
> >>>> > > will
> >>>> > > > >> be
> >>>> > > > >> > > > > > interested in that
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the
> deal
> >>>> with
> >>>> > > the
> >>>> > > > >> > github
> >>>> > > > >> > > > > sync?
> >>>> > > > >> > > > > > > Who could diagnose that?
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the
> >>>> apache
> >>>> > repo
> >>>> > > > for
> >>>> > > > >> now
> >>>> > > > >> > > > while
> >>>> > > > >> > > > > > we get that sorted out.
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar
> Syn-Hershko
> >>>> <
> >>>> > > > >> > > > itamar@code972.com
> >>>> > > > >> > > > > > > >wrote:
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it
> >>>> then for
> >>>> > > 3.x
> >>>> > > > >> > > > > development.
> >>>> > > > >> > > > > > > WRT
> >>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on
> >>>> whatever
> >>>> > > branch.
> >>>> > > > >> When
> >>>> > > > >> > > you
> >>>> > > > >> > > > > > send
> >>>> > > > >> > > > > > > us
> >>>> > > > >> > > > > > > > PRs we will merge either to master or to a
> >>>> dedicated
> >>>> > > repo.
> >>>> > > > >> For
> >>>> > > > >> > > now
> >>>> > > > >> > > > it
> >>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
> >>>> > > > >> > > > > > > >
> >>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see
> >>>> it on
> >>>> > the
> >>>> > > > >> apache
> >>>> > > > >> > > > > servers
> >>>> > > > >> > > > > > > > (github sync seems to be off)
> >>>> > > > >> > > > > > > >
> >>>> > > > >> > > > > > > >
> >>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> >>>> > > > >> > > pirwin@feature23.com>
> >>>> > > > >> > > > > > > wrote:
> >>>> > > > >> > > > > > > >
> >>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on
> >>>> 4.3
> >>>> > > version
> >>>> > > > >> of
> >>>> > > > >> > the
> >>>> > > > >> > > > > > > Analysis
> >>>> > > > >> > > > > > > > > namespace.
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > > Not sure the checkout command is what you
> >>>> intended
> >>>> > --
> >>>> > > > you
> >>>> > > > >> > might
> >>>> > > > >> > > > > have
> >>>> > > > >> > > > > > > > meant
> >>>> > > > >> > > > > > > > > trunk instead of master, and that would
> create
> >>>> a new
> >>>> > > > "3x"
> >>>> > > > >> > > branch,
> >>>> > > > >> > > > > > when
> >>>> > > > >> > > > > > > > > there's already a "branch_3x" and that would
> be
> >>>> > > > >> misnamed...
> >>>> > > > >> > so
> >>>> > > > >> > > > > maybe
> >>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
> >>>> aiming
> >>>> > for
> >>>> > > > >> lucene
> >>>> > > > >> > > > 4.3.x
> >>>> > > > >> > > > > > > > > compatibility?
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
> >>>> > upstream
> >>>> > > > >> want to
> >>>> > > > >> > > > > create
> >>>> > > > >> > > > > > > the
> >>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're
> >>>> not all
> >>>> > > > >> trying to
> >>>> > > > >> > > > > create
> >>>> > > > >> > > > > > > them
> >>>> > > > >> > > > > > > > > and dealing with a merge?
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > > Paul
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
> >>>> Syn-Hershko <
> >>>> > > > >> > > > > > itamar@code972.com
> >>>> > > > >> > > > > > > > > >wrote:
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > > > > Unless people here have a specific reason
> to
> >>>> use
> >>>> > > > 3.6.2 I
> >>>> > > > >> > > would
> >>>> > > > >> > > > > > highly
> >>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
> >>>> towards v4
> >>>> > > > >> > otherwise
> >>>> > > > >> > > we
> >>>> > > > >> > > > > > will
> >>>> > > > >> > > > > > > > > never
> >>>> > > > >> > > > > > > > > > make it...
> >>>> > > > >> > > > > > > > > >
> >>>> > > > >> > > > > > > > > > Fork the repo from apache servers or github
> >>>> (same
> >>>> > > > repo,
> >>>> > > > >> > > > different
> >>>> > > > >> > > > > > > > > remotes)
> >>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
> >>>> should
> >>>> > > work
> >>>> > > > >> > > > > > > > > >
> >>>> > > > >> > > > > > > > > >
> >>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul
> Irwin <
> >>>> > > > >> > > > > pirwin@feature23.com>
> >>>> > > > >> > > > > > > > > wrote:
> >>>> > > > >> > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > Itamar,
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > I agree that from scratch is not the best
> >>>> way to
> >>>> > > do
> >>>> > > > >> it, I
> >>>> > > > >> > > > just
> >>>> > > > >> > > > > > > > thought
> >>>> > > > >> > > > > > > > > > that
> >>>> > > > >> > > > > > > > > > > was the "decision" that was made from the
> >>>> > > discussion
> >>>> > > > >> > > > previously
> >>>> > > > >> > > > > > for
> >>>> > > > >> > > > > > > > the
> >>>> > > > >> > > > > > > > > > 4.x
> >>>> > > > >> > > > > > > > > > > work. An incremental approach will be
> much
> >>>> > better.
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
> >>>> branch on
> >>>> > > my
> >>>> > > > >> fork
> >>>> > > > >> > > and
> >>>> > > > >> > > > > will
> >>>> > > > >> > > > > > > > begin
> >>>> > > > >> > > > > > > > > > > working on bringing the Analysis
> namespace
> >>>> up to
> >>>> > > > >> speed to
> >>>> > > > >> > > > > 3.6.2.
> >>>> > > > >> > > > > > If
> >>>> > > > >> > > > > > > > > > anyone
> >>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once
> >>>> I'm
> >>>> > > done,
> >>>> > > > >> have
> >>>> > > > >> > at
> >>>> > > > >> > > > it.
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
> >>>> branch_3x
> >>>> > > > branch,
> >>>> > > > >> > > please
> >>>> > > > >> > > > > let
> >>>> > > > >> > > > > > > me
> >>>> > > > >> > > > > > > > > know
> >>>> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > Paul
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
> >>>> > > Syn-Hershko <
> >>>> > > > >> > > > > > > > itamar@code972.com
> >>>> > > > >> > > > > > > > > > > >wrote:
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
> >>>> again :)
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
> >>>> know
> >>>> > what
> >>>> > > > it
> >>>> > > > >> > would
> >>>> > > > >> > > > > take
> >>>> > > > >> > > > > > > > until
> >>>> > > > >> > > > > > > > > > they
> >>>> > > > >> > > > > > > > > > > > have deep dived into the work, and even
> >>>> then
> >>>> > > > >> decisions
> >>>> > > > >> > > > could
> >>>> > > > >> > > > > > and
> >>>> > > > >> > > > > > > > will
> >>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
> >>>> > starting
> >>>> > > > from
> >>>> > > > >> > > > scratch,
> >>>> > > > >> > > > > > > > > although
> >>>> > > > >> > > > > > > > > > I
> >>>> > > > >> > > > > > > > > > > do
> >>>> > > > >> > > > > > > > > > > > think a lot in the current structure
> >>>> should
> >>>> > > > change,
> >>>> > > > >> but
> >>>> > > > >> > > its
> >>>> > > > >> > > > > > going
> >>>> > > > >> > > > > > > > to
> >>>> > > > >> > > > > > > > > be
> >>>> > > > >> > > > > > > > > > > > much easier to change it in place,
> >>>> refactoring
> >>>> > > > where
> >>>> > > > >> > > > needed,
> >>>> > > > >> > > > > > than
> >>>> > > > >> > > > > > > > > > > starting
> >>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this
> off I
> >>>> > > > personally
> >>>> > > > >> > will
> >>>> > > > >> > > > be
> >>>> > > > >> > > > > > > happy
> >>>> > > > >> > > > > > > > > with
> >>>> > > > >> > > > > > > > > > > you
> >>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
> >>>> porting
> >>>> > > it,
> >>>> > > > >> its
> >>>> > > > >> > > > pretty
> >>>> > > > >> > > > > > > much
> >>>> > > > >> > > > > > > > > self
> >>>> > > > >> > > > > > > > > > > > contained.
> >>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on
> >>>> a fork
> >>>> > > and
> >>>> > > > >> send
> >>>> > > > >> > > us
> >>>> > > > >> > > > > PRs,
> >>>> > > > >> > > > > > > its
> >>>> > > > >> > > > > > > > > > much
> >>>> > > > >> > > > > > > > > > > > more straight forward than the v4
> upgrade
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
> >>>> fastest
> >>>> > > way
> >>>> > > > >> to do
> >>>> > > > >> > > > this,
> >>>> > > > >> > > > > > we
> >>>> > > > >> > > > > > > > can
> >>>> > > > >> > > > > > > > > > then
> >>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and
> optimizing
> >>>> using
> >>>> > > > .NET
> >>>> > > > >> > > > > constructs.
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
> >>>> create a
> >>>> > > > branch
> >>>> > > > >> out
> >>>> > > > >> > > of
> >>>> > > > >> > > > > the
> >>>> > > > >> > > > > > > > > current
> >>>> > > > >> > > > > > > > > > > git
> >>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and
> start
> >>>> > > working
> >>>> > > > on
> >>>> > > > >> > > master
> >>>> > > > >> > > > > > > > towards a
> >>>> > > > >> > > > > > > > > > 4.3
> >>>> > > > >> > > > > > > > > > > > compatible version. The actual port
> >>>> should be
> >>>> > > > using
> >>>> > > > >> a
> >>>> > > > >> > > > process
> >>>> > > > >> > > > > > > that
> >>>> > > > >> > > > > > > > > > > ensures
> >>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
> >>>> tests,
> >>>> > > and
> >>>> > > > >> that
> >>>> > > > >> > > > those
> >>>> > > > >> > > > > > > tests
> >>>> > > > >> > > > > > > > > > pass -
> >>>> > > > >> > > > > > > > > > > > but I'm against committing any Java
> code
> >>>> to
> >>>> > our
> >>>> > > > >> > > > repositories.
> >>>> > > > >> > > > > > The
> >>>> > > > >> > > > > > > > > > process
> >>>> > > > >> > > > > > > > > > > > should probably be working on classes
> in
> >>>> some
> >>>> > > > order
> >>>> > > > >> > > > > > > > (alphabetically,
> >>>> > > > >> > > > > > > > > or
> >>>> > > > >> > > > > > > > > > > > core classes first) and getting each
> >>>> class to
> >>>> > > > >> compile
> >>>> > > > >> > > > before
> >>>> > > > >> > > > > > > moving
> >>>> > > > >> > > > > > > > > > > > forward. I don't mind about the project
> >>>> not
> >>>> > > being
> >>>> > > > >> > > > compilable
> >>>> > > > >> > > > > > for
> >>>> > > > >> > > > > > > a
> >>>> > > > >> > > > > > > > > > month
> >>>> > > > >> > > > > > > > > > > or
> >>>> > > > >> > > > > > > > > > > > two.
> >>>> > > > >> > > > > > > > > > > > Once this is done a process of
> >>>> .NETifying and
> >>>> > > > >> proofing
> >>>> > > > >> > > the
> >>>> > > > >> > > > > code
> >>>> > > > >> > > > > > > can
> >>>> > > > >> > > > > > > > > be
> >>>> > > > >> > > > > > > > > > > > started, at which point we will already
> >>>> have a
> >>>> > > > >> working
> >>>> > > > >> > v4
> >>>> > > > >> > > > > > version
> >>>> > > > >> > > > > > > > so
> >>>> > > > >> > > > > > > > > it
> >>>> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
> >>>> > project.
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
> >>>> test
> >>>> > > suite
> >>>> > > > so
> >>>> > > > >> > > tests
> >>>> > > > >> > > > > > could
> >>>> > > > >> > > > > > > > more
> >>>> > > > >> > > > > > > > > > or
> >>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
> >>>> implementing
> >>>> > > > >> Java-like
> >>>> > > > >> > > > > > > assertEquals
> >>>> > > > >> > > > > > > > > > > methods
> >>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
> >>>> work
> >>>> > with
> >>>> > > > >> than
> >>>> > > > >> > > > > NUnit). I
> >>>> > > > >> > > > > > > > > already
> >>>> > > > >> > > > > > > > > > > did
> >>>> > > > >> > > > > > > > > > > > some work there but there's still a lot
> >>>> to do.
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
> >>>> myself at
> >>>> > > this
> >>>> > > > >> > point,
> >>>> > > > >> > > > > but I
> >>>> > > > >> > > > > > > > > should
> >>>> > > > >> > > > > > > > > > be
> >>>> > > > >> > > > > > > > > > > > back in business in August, at which
> >>>> point I
> >>>> > can
> >>>> > > > >> > dedicate
> >>>> > > > >> > > > > > several
> >>>> > > > >> > > > > > > > > > hours a
> >>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
> >>>> > closely
> >>>> > > > and
> >>>> > > > >> > even
> >>>> > > > >> > > > > > > coordinate
> >>>> > > > >> > > > > > > > > the
> >>>> > > > >> > > > > > > > > > > > work to some extent.
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
> >>>> Lima <
> >>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
> >>>> > > > >> > > > > > > > > > > > >wrote:
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this is
> a
> >>>> kick
> >>>> > > > start
> >>>> > > > >> > =). I
> >>>> > > > >> > > > > > haven't
> >>>> > > > >> > > > > > > > > > > > contributed
> >>>> > > > >> > > > > > > > > > > > > anything
> >>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you all
> >>>> to get
> >>>> > > > this
> >>>> > > > >> job
> >>>> > > > >> > > > done.
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
> >>>> Prescott.
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > I know that there is a high
> commitment
> >>>> for
> >>>> > > keep
> >>>> > > > >> the
> >>>> > > > >> > > > > > > > > > retrocompatibility
> >>>> > > > >> > > > > > > > > > > on
> >>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
> >>>> > changes
> >>>> > > > >> every
> >>>> > > > >> > > > > release?
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a
> stable
> >>>> > version
> >>>> > > > >> from a
> >>>> > > > >> > > > > Lucene
> >>>> > > > >> > > > > > > > > version,
> >>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only
> >>>> minor
> >>>> > > changes
> >>>> > > > >> > every
> >>>> > > > >> > > > > stable
> >>>> > > > >> > > > > > > > > release
> >>>> > > > >> > > > > > > > > > > (or
> >>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we
> could
> >>>> > > compare
> >>>> > > > >> the
> >>>> > > > >> > > > > versions,
> >>>> > > > >> > > > > > > > check
> >>>> > > > >> > > > > > > > > > the
> >>>> > > > >> > > > > > > > > > > > > differences and bring them to
> >>>> Lucene.Net.
> >>>> > > > Again, I
> >>>> > > > >> > > > haven't
> >>>> > > > >> > > > > > > > > > contributed
> >>>> > > > >> > > > > > > > > > > > with
> >>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just
> an
> >>>> > idea).
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > What's your approach for implement
> >>>> simple
> >>>> > > > >> performance
> >>>> > > > >> > > > > > > > improvements
> >>>> > > > >> > > > > > > > > > > > (without
> >>>> > > > >> > > > > > > > > > > > > adding references or changing methods
> >>>> > > > signatures)?
> >>>> > > > >> > Does
> >>>> > > > >> > > > it
> >>>> > > > >> > > > > > > could
> >>>> > > > >> > > > > > > > be
> >>>> > > > >> > > > > > > > > > > done,
> >>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
> >>>> pirwin@feature23.com>
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > This is just an "outsider"
> >>>> suggestion as I
> >>>> > > > >> haven't
> >>>> > > > >> > > > > > > contributed
> >>>> > > > >> > > > > > > > > > > anything
> >>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely
> help
> >>>> with
> >>>> > > the
> >>>> > > > >> 4.x
> >>>> > > > >> > > work
> >>>> > > > >> > > > > as I
> >>>> > > > >> > > > > > > > have
> >>>> > > > >> > > > > > > > > a
> >>>> > > > >> > > > > > > > > > > > vested
> >>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
> >>>> completed. I
> >>>> > > think
> >>>> > > > >> > there
> >>>> > > > >> > > > > should
> >>>> > > > >> > > > > > > be
> >>>> > > > >> > > > > > > > > one
> >>>> > > > >> > > > > > > > > > > > person
> >>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
> >>>> > structure
> >>>> > > > and
> >>>> > > > >> > > > workflow
> >>>> > > > >> > > > > > will
> >>>> > > > >> > > > > > > > > look
> >>>> > > > >> > > > > > > > > > > like
> >>>> > > > >> > > > > > > > > > > > > to
> >>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is
> >>>> going to
> >>>> > be
> >>>> > > > >> > starting
> >>>> > > > >> > > > from
> >>>> > > > >> > > > > > > > scratch
> >>>> > > > >> > > > > > > > > > as
> >>>> > > > >> > > > > > > > > > > a
> >>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set
> >>>> up the
> >>>> > > > >> project,
> >>>> > > > >> > > get
> >>>> > > > >> > > > > > > > everything
> >>>> > > > >> > > > > > > > > > > going
> >>>> > > > >> > > > > > > > > > > > > in
> >>>> > > > >> > > > > > > > > > > > > > source control, create the folder
> >>>> > structure,
> >>>> > > > >> maybe
> >>>> > > > >> > > stub
> >>>> > > > >> > > > > out
> >>>> > > > >> > > > > > > > some
> >>>> > > > >> > > > > > > > > > > > classes,
> >>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
> >>>> anyone
> >>>> > > > >> interested
> >>>> > > > >> > > in
> >>>> > > > >> > > > > > > > > > contributing,
> >>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the
> java
> >>>> code
> >>>> > in
> >>>> > > > >> there
> >>>> > > > >> > so
> >>>> > > > >> > > > > it's
> >>>> > > > >> > > > > > > easy
> >>>> > > > >> > > > > > > > > to
> >>>> > > > >> > > > > > > > > > > > > > reference.
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > Again, I can work on
> >>>> Lucene.Net.Documents,
> >>>> > > > >> > > > > > > Lucene.Net.Analysis,
> >>>> > > > >> > > > > > > > > or
> >>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
> >>>> those
> >>>> > are
> >>>> > > > >> just
> >>>> > > > >> > the
> >>>> > > > >> > > > > ones
> >>>> > > > >> > > > > > > I'm
> >>>> > > > >> > > > > > > > > most
> >>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
> >>>> Tell me
> >>>> > > what
> >>>> > > > >> to
> >>>> > > > >> > do
> >>>> > > > >> > > > and
> >>>> > > > >> > > > > > I'll
> >>>> > > > >> > > > > > > > get
> >>>> > > > >> > > > > > > > > > > > started
> >>>> > > > >> > > > > > > > > > > > > > on my fork.
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > Paul Irwin
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
> >>>> Prescott
> >>>> > > > Nasser
> >>>> > > > >> <
> >>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
> >>>> > > > >> > > > > > > > > > > > > > >wrote:
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > > > Hey guys -
> >>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
> >>>> while. We
> >>>> > > > have a
> >>>> > > > >> > > board
> >>>> > > > >> > > > > > report
> >>>> > > > >> > > > > > > > due
> >>>> > > > >> > > > > > > > > > > soon
> >>>> > > > >> > > > > > > > > > > > -
> >>>> > > > >> > > > > > > > > > > > > I
> >>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise
> >>>> them
> >>>> > that
> >>>> > > we
> >>>> > > > >> seem
> >>>> > > > >> > > to
> >>>> > > > >> > > > > have
> >>>> > > > >> > > > > > > > > stalled
> >>>> > > > >> > > > > > > > > > > > > > somewhat.
> >>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items
> >>>> out of
> >>>> > > of
> >>>> > > > >> jira
> >>>> > > > >> > > and
> >>>> > > > >> > > > > have
> >>>> > > > >> > > > > > > > been
> >>>> > > > >> > > > > > > > > > > > > responsive
> >>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
> >>>> > > questions,
> >>>> > > > >> but I
> >>>> > > > >> > > > don't
> >>>> > > > >> > > > > > > think
> >>>> > > > >> > > > > > > > > > we've
> >>>> > > > >> > > > > > > > > > > > > done
> >>>> > > > >> > > > > > > > > > > > > > > anything to move forward with
> 4.0.
> >>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try*
> and
> >>>> > start
> >>>> > > us
> >>>> > > > >> back
> >>>> > > > >> > > up
> >>>> > > > >> > > > > > moving
> >>>> > > > >> > > > > > > > > > > forward.
> >>>> > > > >> > > > > > > > > > > > > What
> >>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish
> >>>> this? If
> >>>> > we
> >>>> > > > took
> >>>> > > > >> > the
> >>>> > > > >> > > > java
> >>>> > > > >> > > > > > > > lucene
> >>>> > > > >> > > > > > > > > > 4.0
> >>>> > > > >> > > > > > > > > > > > code
> >>>> > > > >> > > > > > > > > > > > > > and
> >>>> > > > >> > > > > > > > > > > > > > > committed that java to our branch
> >>>> and
> >>>> > then
> >>>> > > > >> just
> >>>> > > > >> > let
> >>>> > > > >> > > > > > people
> >>>> > > > >> > > > > > > > pull
> >>>> > > > >> > > > > > > > > > > that
> >>>> > > > >> > > > > > > > > > > > > down
> >>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying is
> >>>> that
> >>>> > one
> >>>> > > > >> way to
> >>>> > > > >> > > > maybe
> >>>> > > > >> > > > > > > make
> >>>> > > > >> > > > > > > > > some
> >>>> > > > >> > > > > > > > > > > > > forward
> >>>> > > > >> > > > > > > > > > > > > > > progress?
> >>>> > > > >> > > > > > > > > > > > > > > ~P
> >>>> > > > >> > > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > > > --
> >>>> > > > >> > > > > > > > > > > > > --
> >>>> > > > >> > > > > > > > > > > > > Marcos Lima
> >>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
> >>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
> >>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> >>>> > > > >> > > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > > >
> >>>> > > > >> > > > > > > > > > >
> >>>> > > > >> > > > > > > > > >
> >>>> > > > >> > > > > > > > >
> >>>> > > > >> > > > > > > >
> >>>> > > > >> > > > > > >
> >>>> > > > >> > > > > >
> >>>> > > > >> > > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > >
> >>>> > > > >> > > > --
> >>>> > > > >> > > > --
> >>>> > > > >> > > > Marcos Lima
> >>>> > > > >> > > > Software Developer/Tech Lead
> >>>> > > > >> > > > marcoslimagon@gmail.com
> >>>> > > > >> > > > tel: +55 (19) 9798-9335
> >>>> > > > >> > > >
> >>>> > > > >> > >
> >>>> > > > >> >
> >>>> > > > >>
> >>>> > > > >>
> >>>> > > > >>
> >>>> > > > >> --
> >>>> > > > >> --
> >>>> > > > >> Marcos Lima
> >>>> > > > >> Software Developer/Tech Lead
> >>>> > > > >> marcoslimagon@gmail.com
> >>>> > > > >> tel: +55 (19) 9798-9335
> >>>> > > > >>
> >>>> > > > >
> >>>> > > > >
> >>>> > > >
> >>>> > >
> >>>> >
> >>>>
> >>>
> >>>
> >>
> >
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Is this mailing list dead?! If anyone is interested in releasing an
up-to-date build of Lucene.net, please write back! If you didn't read my
other messages, I have Lucene.net Core working with Lucene java 4.3.1
compatibility thanks to the help of my colleagues. We just need to round
out the contrib modules, unit tests, and documentation as a community and
we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
was packaged in December 2010!
I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
(where they now live in Lucene java, they were moved from core) and their
associated filters and tokenizers. I've briefly tested each and they seem
to work correctly. I've purposefully "Exclude[d] from Project" the other
language analyzers until we can forward-port them. So now the Analyzers DLL
compiles with those analyzers only. Also, I fixed the bug that was causing
NumericRangeQuery to not work.
Next on my list is the QueryParsers contrib library (QueryParser was moved
out of Lucene java core) so that, combined with StandardAnalyzer, we can
test a pretty common real-world use case (the prototypical "hello lucene"
tutorial). After that, it might be worth forward-porting what we have so
far to 4.4 and use that as the latest point to finish out the port. The
changes shouldn't be too dramatic to core from what I can tell.
My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
I'll keep updating as I go, but if anyone wants to jump in, there's not a
better time than now...
On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pi...@feature23.com> wrote:
> I made a dumb mistake... I have worked with StandardAnalyzer so long that
> I forgot that KeywordAnalyzer is not what I needed to be using, I needed to
> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>
> Now it works after re-indexing with a quick, dirty implementation of
> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on to
> find out why NumericRangeQuery isn't working.
>
> Sorry for the blast of emails, but I wanted to prevent people from
> spending time hunting down my mistake!
>
>
> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>> byte being signed is a pain.
>>
>> Now there's no exception doing a TermQuery, but I also don't get any
>> results. It doesn't find any terms when scanning for them. I also tried a
>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>> didn't find any results that way either. So right now only
>> MatchAllDocsQuery seems to work.
>>
>> If anyone would like to do a Google Hangout or anything sometime to look
>> into it, let me know.
>>
>>
>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>>> I realized after I sent that email last night that I could do as you
>>> described. When you've been debugging through CorruptedIndexExceptions, you
>>> get a little bit of tunnel vision... haha
>>>
>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
>>> the matching documents prints the fields to the console, so it's loading in
>>> the stored fields data correctly.
>>>
>>> I tried doing a TermQuery and now I get a "read past EOF" exception that
>>> I can't figure out. There's a whole bunch of buffered byte array operations
>>> going on and I can't determine where the issue came from. I'll keep
>>> looking, but if someone could grab my fork/branch and help me look that
>>> would be great. Here's example index writing and then reading code (also
>>> included is a quick port of KeywordAnalyzer):
>>> https://gist.github.com/anonymous/6174164
>>>
>>> Thanks!
>>>
>>>
>>>
>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <it...@code972.com>wrote:
>>>
>>>> Great
>>>>
>>>> You can build you Query objects on your own to execute a search, you
>>>> don't
>>>> actually have to use QueryParser for that
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com>
>>>> wrote:
>>>>
>>>> > Hey all, sorry it's been a little while, but I wanted to let you know
>>>> that
>>>> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
>>>> > Lucene.net core building and able to write a simple index in Lucene
>>>> 4.2
>>>> > codec and read in things like the number of documents and whatnot.
>>>> Since
>>>> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
>>>> > haven't ported that yet so I haven't done a real search, and I only
>>>> built
>>>> > the index using a quick port of KeywordAnalyzer which all those
>>>> analyzers
>>>> > have also moved to another module. But this is definitely good
>>>> progress and
>>>> > should be a launch point for finishing a 4.3/4.4 port.
>>>> >
>>>> > You can see my fork/branch here:
>>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
>>>> like I
>>>> > said, only core builds now, no modules/tests build, so only open the
>>>> > Lucene.Net.Core.sln)
>>>> >
>>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
>>>> the
>>>> > community into finishing the 4.3/4.4 port. Let me know if you have any
>>>> > questions, thanks!
>>>> >
>>>> >
>>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>>> itamar@code972.com
>>>> > >wrote:
>>>> >
>>>> > > Paul, that's awesome. I will need some more time to go over this
>>>> thread
>>>> > and
>>>> > > your work to give actual feedback, SUPER busy at the moment
>>>> > >
>>>> > >
>>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
>>>> > wrote:
>>>> > >
>>>> > > > All,
>>>> > > >
>>>> > > > My colleagues and I have made good progress on porting Lucene
>>>> 4.3's
>>>> > core
>>>> > > > library before, during, and after the hackathon last week. We now
>>>> only
>>>> > > have
>>>> > > > some remaining items in Search, Index, and Codecs namespaces
>>>> (plus a
>>>> > few
>>>> > > > other minor ones here and there). I expect to be done by the end
>>>> of the
>>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
>>>> Packed),
>>>> > > and
>>>> > > > the root Codecs and Codecs.PerField namespaces are all now "done".
>>>> > > >
>>>> > > > Again, my goal is to only get a buildable, experimental build of
>>>> > > Lucene.net
>>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>>>> porting
>>>> > > new
>>>> > > > javadoc comments or unit tests right now, due to the vast amount
>>>> of
>>>> > code
>>>> > > > that needs to be written just to get it to compile. If this work
>>>> ends
>>>> > up
>>>> > > > becoming a pull request, great, otherwise it should help
>>>> accelerate a
>>>> > > port
>>>> > > > of 4.3.x since the bulk of the work on core will already be done
>>>> and
>>>> > > > contributors can use it as a reference. And again, we're taking
>>>> the
>>>> > > > pragmatic approach of porting class-by-class,
>>>> namespace-by-namespace,
>>>> > > with
>>>> > > > the understanding that until we're done the project won't build.
>>>> > > >
>>>> > > > Once complete, I also will work on updating the Analyzers contrib
>>>> > module
>>>> > > > and porting the QueryParsers contrib module, which I feel should
>>>> be
>>>> > > > included in the core NuGet package for Lucene.net as the core
>>>> library
>>>> > is
>>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
>>>> without
>>>> > > them.
>>>> > > > You can check out the code on my fork/branch here:
>>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>> > > >
>>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
>>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory.
>>>> For the
>>>> > > MMap
>>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
>>>> > > > MemoryMappedFile support which should emulate the Java nio stuff
>>>> pretty
>>>> > > > well, but required some creative shuffling of the code to make it
>>>> work
>>>> > > due
>>>> > > > to lifecycle management.
>>>> > > >
>>>> > > > I'll update again this weekend or next week, when we should have
>>>> > wrapped
>>>> > > up
>>>> > > > most of the main hacking on porting the core code.
>>>> > > >
>>>> > > > Paul
>>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pirwin@feature23.com
>>>> >
>>>> > > wrote:
>>>> > > >
>>>> > > > > Marcos,
>>>> > > > >
>>>> > > > > That would be helpful. As far as I can tell, the 3.0 java code
>>>> is
>>>> > only
>>>> > > on
>>>> > > > > SVN here, before the lucene and solr projects were bundled
>>>> together:
>>>> > > > >
>>>> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>>>> > > > >
>>>> > > > > The SVN for 4.3 java is here:
>>>> > > > >
>>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>>>> > > > > And the GitHub for 4.3 java is here:
>>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>>>> > > > >
>>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
>>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>>>> > > > >
>>>> > > > > My fork is the "upstream" fork for my team members, and i'm
>>>> remote
>>>> > > > merging
>>>> > > > > their changes in from their forks while they fetch/merge from
>>>> mine to
>>>> > > get
>>>> > > > > everyone else's changes, rather than using pull requests. James
>>>> and I
>>>> > > > have
>>>> > > > > been working the past few days on the Util namespace ahead of
>>>> > tonight's
>>>> > > > > hackathon since that namespace is in common with the rest of the
>>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
>>>> > hacking
>>>> > > on
>>>> > > > > porting 4.3, each with a different namespace or part of a
>>>> namespace.
>>>> > > > Since
>>>> > > > > we're going class-by-class, namespace-by-namespace, the project
>>>> does
>>>> > > not
>>>> > > > > build as it is. Once we finish doing a translation of each
>>>> file, then
>>>> > > > we'll
>>>> > > > > hammer out any remaining issues and get it to build again. I'm
>>>> hoping
>>>> > > > that
>>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
>>>> > > > >
>>>> > > > > But one thing to keep in mind is it looks like much
>>>> functionality has
>>>> > > > been
>>>> > > > > moved out of core into the contrib modules, especially around
>>>> > analysis,
>>>> > > > for
>>>> > > > > 4.0+. For example, there are no built-in analyzers in core
>>>> anymore.
>>>> > So
>>>> > > > when
>>>> > > > > this is all done, we may want to include at least the analysis
>>>> > contrib
>>>> > > > > module in with the standard core NuGet package, because
>>>> otherwise
>>>> > it's
>>>> > > > > practically useless unless you roll your own analyzer.
>>>> > > > >
>>>> > > > > Paul
>>>> > > > >
>>>> > > > >
>>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>>>> > marcoslimagon@gmail.com
>>>> > > > >wrote:
>>>> > > > >
>>>> > > > >> Hi everyone!
>>>> > > > >>
>>>> > > > >> Does someone know where can I find the 3.0.3 release from
>>>> > > Lucene(java)?
>>>> > > > >>
>>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
>>>> 4.3.0 and
>>>> > > > make
>>>> > > > >> the diff between then and get all changes between releases... I
>>>> > gonna
>>>> > > > >> publish it here soon. (If you think there is another important
>>>> > > release,
>>>> > > > >> let
>>>> > > > >> me know)
>>>> > > > >>
>>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry)
>>>> with
>>>> > 4.3.0
>>>> > > > >> port
>>>> > > > >> for .Net on github (last email)?
>>>> > > > >>
>>>> > > > >> See you,
>>>> > > > >>
>>>> > > > >>
>>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>>> > > > >>
>>>> > > > >> > Thanks for the discussion points, Michael.
>>>> > > > >> >
>>>> > > > >> > I would vote for not worrying about trying to achieve
>>>> portable
>>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+
>>>> is
>>>> > > > >> completed.
>>>> > > > >> > Otherwise it may delay the project and stall it further.
>>>> That's
>>>> > just
>>>> > > > my
>>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
>>>> > > > >> >
>>>> > > > >> > I have started porting the changes from the core library
>>>> (from the
>>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
>>>> separate
>>>> > > > branch.
>>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
>>>> port
>>>> > > until
>>>> > > > >> > there's changes to pull from upstream to work from. Also due
>>>> to my
>>>> > > > time
>>>> > > > >> > constraints, I am not fully documenting new methods that I'm
>>>> > adding.
>>>> > > > >> But if
>>>> > > > >> > anyone wants to pull/copy/reference my changes while porting,
>>>> > that's
>>>> > > > >> > awesome. My branch currently does not build as I'm primarily
>>>> going
>>>> > > > >> > class-by-class, starting with the util namespace. Once we
>>>> get the
>>>> > > ball
>>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
>>>> join
>>>> > in.
>>>> > > > But
>>>> > > > >> > hopefully my work will be useful to someone, if not as a pull
>>>> > > request
>>>> > > > >> then
>>>> > > > >> > as a reference. I'm also going to be holding a hackathon
>>>> this week
>>>> > > > with
>>>> > > > >> my
>>>> > > > >> > colleagues where we're all going to work on the port. I'm
>>>> > comparing
>>>> > > > >> files
>>>> > > > >> > and making changes as necessary, rather than starting from
>>>> > scratch.
>>>> > > My
>>>> > > > >> > repo/branch is here:
>>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>>> > > > >> >
>>>> > > > >> > Paul
>>>> > > > >> >
>>>> > > > >> >
>>>> > > > >> >
>>>> > > > >> >
>>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>>>> > > > >> > mherndon@michaelherndon.com> wrote:
>>>> > > > >> >
>>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
>>>> apache
>>>> > > > >> > maintains.
>>>> > > > >> > >
>>>> > > > >> > > The was some work at one time to move the official svn
>>>> > repository
>>>> > > to
>>>> > > > >> > start
>>>> > > > >> > > using git one instead. Was that actually finalized or not?
>>>> > > > >> > >
>>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to
>>>> see
>>>> > > what
>>>> > > > >> kind
>>>> > > > >> > of
>>>> > > > >> > > work was involved using a portable libraries project. Some
>>>> of it
>>>> > > can
>>>> > > > >> > still
>>>> > > > >> > > be used but will need to be validated against the current
>>>> > version
>>>> > > of
>>>> > > > >> > Java's
>>>> > > > >> > > Lucene. It was also using .net 4.
>>>> > > > >> > >
>>>> > > > >> > > clean branch vs current. Its going to depend on what we
>>>> > > support.
>>>> > > > >> If
>>>> > > > >> > you
>>>> > > > >> > > support windows mobile 8, win RT, then the current code in
>>>> trunk
>>>> > > > will
>>>> > > > >> not
>>>> > > > >> > > compile against those versions of the framework which
>>>> would a
>>>> > > > >> frustrating
>>>> > > > >> > > starting point, then you couldn't even run tests, which
>>>> would
>>>> > make
>>>> > > > >> taking
>>>> > > > >> > > patches very difficult. Supporting those can almost mean
>>>> larger
>>>> > > > gaps
>>>> > > > >> in
>>>> > > > >> > > design between Lucene.Net and its parent project.
>>>> > > > >> > >
>>>> > > > >> > > Also the structure has changed significantly between the
>>>> > branches
>>>> > > > and
>>>> > > > >> > the
>>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6,
>>>> and
>>>> > > seems
>>>> > > > >> > > significantly different. That doesn't mean you can't
>>>> cherry
>>>> > pick
>>>> > > > >> stuff
>>>> > > > >> > > from the other tags/branches that would still work as is.
>>>> A
>>>> > clean
>>>> > > > >> branch
>>>> > > > >> > > would also make it easier to get our build / tool chain in
>>>> order
>>>> > > as
>>>> > > > >> you
>>>> > > > >> > can
>>>> > > > >> > > then do them incrementally versus having to do all the
>>>> stuff
>>>> > that
>>>> > > I
>>>> > > > >> did
>>>> > > > >> > for
>>>> > > > >> > > the 3x branch which saps energy and desire to code. It
>>>> could
>>>> > > also
>>>> > > > >> make
>>>> > > > >> > it
>>>> > > > >> > > easier to see which classes have been ported or not.
>>>> > > > >> > >
>>>> > > > >> > > The major downside to a clean branch is extra work it
>>>> requires
>>>> > and
>>>> > > > the
>>>> > > > >> > > start up cost in time and energy of getting it in order,
>>>> which
>>>> > can
>>>> > > > be
>>>> > > > >> > > daunting / intimidating and lower morale. And generally
>>>> you want
>>>> > > to
>>>> > > > >> use
>>>> > > > >> > > take your legacy code and refactor instead of in someways
>>>> > starting
>>>> > > > >> over.
>>>> > > > >> > >
>>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
>>>> > something
>>>> > > > >> similar
>>>> > > > >> > > to
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> >
>>>> > > > >>
>>>> > > >
>>>> > >
>>>> >
>>>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>>>> > > > >> > > where it tracks what needs to get ported / what has been
>>>> ported.
>>>> > > > >> > >
>>>> > > > >> > > What are we going to support in the next version?
>>>> > > > >> > >
>>>> > > > >> > > Who is going to work on the next version?
>>>> > > > >> > >
>>>> > > > >> > > What would make the most sense and what would invigorate
>>>> the
>>>> > > > >> community to
>>>> > > > >> > > get involved more and lower the barrier to entry?
>>>> > > > >> > >
>>>> > > > >> > > I think those are the questions that would make a lot of
>>>> the
>>>> > > > decisions
>>>> > > > >> > for
>>>> > > > >> > > us so that we can get back to work on lucene.net.
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > >
>>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>>>> > > > marcoslimagon@gmail.com
>>>> > > > >> > > >wrote:
>>>> > > > >> > >
>>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
>>>> projects...
>>>> > > > >> > > >
>>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>>>> > > > >> > > > https://github.com/apache/lucene.net points to the same
>>>> > > > repository?
>>>> > > > >> > > (This
>>>> > > > >> > > > is new for me, pretty good) Which of them do you
>>>> recommend
>>>> > (i'm
>>>> > > > used
>>>> > > > >> > with
>>>> > > > >> > > > SVN and its patterns).
>>>> > > > >> > > >
>>>> > > > >> > > > I'm checking the subversion right now.
>>>> > > > >> > > >
>>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a
>>>> old
>>>> > > > branch,
>>>> > > > >> i`m
>>>> > > > >> > > not
>>>> > > > >> > > > sure about its current status.
>>>> > > > >> > > >
>>>> > > > >> > > > Will we wipe the current solution from /trunk and start
>>>> a new
>>>> > > one?
>>>> > > > >> > > >
>>>> > > > >> > > > Thanks,
>>>> > > > >> > > >
>>>> > > > >> > > >
>>>> > > > >> > > >
>>>> > > > >> > > >
>>>> > > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
>>>> > > > >> > > >
>>>> > > > >> > > > > We may be forced to start with a clean/empty branch if
>>>> > people
>>>> > > > >> still
>>>> > > > >> > > want
>>>> > > > >> > > > to
>>>> > > > >> > > > > attempt supporting lucene.net for mobile devices, win
>>>> RT,
>>>> > > etc.
>>>> > > > >> The
>>>> > > > >> > are
>>>> > > > >> > > > > many
>>>> > > > >> > > > > classes that Lucene.net uses from the full framework
>>>> that
>>>> > > would
>>>> > > > >> not
>>>> > > > >> > be
>>>> > > > >> > > > > accessible in other versions of the .NET Framework.
>>>> It also
>>>> > > > might
>>>> > > > >> > > > require
>>>> > > > >> > > > > a design that differs even more from its parent
>>>> project.
>>>> > > > >> > > > >
>>>> > > > >> > > > > It might be wise to poll what users most desire in the
>>>> next
>>>> > > > >> version
>>>> > > > >> > > > through
>>>> > > > >> > > > > jira or user voice.
>>>> > > > >> > > > >
>>>> > > > >> > > > >
>>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>>>> > > > >> > itamar@code972.com
>>>> > > > >> > > > > >wrote:
>>>> > > > >> > > > >
>>>> > > > >> > > > > > inline
>>>> > > > >> > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>>>> > > > >> pirwin@feature23.com>
>>>> > > > >> > > > wrote:
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been
>>>> a TFS
>>>> > > guy
>>>> > > > >> for
>>>> > > > >> > so
>>>> > > > >> > > > > long
>>>> > > > >> > > > > > > :-)
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
>>>> patches
>>>> > or
>>>> > > > >> > anything
>>>> > > > >> > > > to
>>>> > > > >> > > > > > the
>>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we will
>>>> > branch
>>>> > > > from
>>>> > > > >> > for
>>>> > > > >> > > 4x
>>>> > > > >> > > > > > dev.
>>>> > > > >> > > > > > > Correct?
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
>>>> anyone
>>>> > > will
>>>> > > > >> be
>>>> > > > >> > > > > > interested in that
>>>> > > > >> > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal
>>>> with
>>>> > > the
>>>> > > > >> > github
>>>> > > > >> > > > > sync?
>>>> > > > >> > > > > > > Who could diagnose that?
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the
>>>> apache
>>>> > repo
>>>> > > > for
>>>> > > > >> now
>>>> > > > >> > > > while
>>>> > > > >> > > > > > we get that sorted out.
>>>> > > > >> > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko
>>>> <
>>>> > > > >> > > > itamar@code972.com
>>>> > > > >> > > > > > > >wrote:
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it
>>>> then for
>>>> > > 3.x
>>>> > > > >> > > > > development.
>>>> > > > >> > > > > > > WRT
>>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on
>>>> whatever
>>>> > > branch.
>>>> > > > >> When
>>>> > > > >> > > you
>>>> > > > >> > > > > > send
>>>> > > > >> > > > > > > us
>>>> > > > >> > > > > > > > PRs we will merge either to master or to a
>>>> dedicated
>>>> > > repo.
>>>> > > > >> For
>>>> > > > >> > > now
>>>> > > > >> > > > it
>>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
>>>> > > > >> > > > > > > >
>>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see
>>>> it on
>>>> > the
>>>> > > > >> apache
>>>> > > > >> > > > > servers
>>>> > > > >> > > > > > > > (github sync seems to be off)
>>>> > > > >> > > > > > > >
>>>> > > > >> > > > > > > >
>>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>>>> > > > >> > > pirwin@feature23.com>
>>>> > > > >> > > > > > > wrote:
>>>> > > > >> > > > > > > >
>>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on
>>>> 4.3
>>>> > > version
>>>> > > > >> of
>>>> > > > >> > the
>>>> > > > >> > > > > > > Analysis
>>>> > > > >> > > > > > > > > namespace.
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > > Not sure the checkout command is what you
>>>> intended
>>>> > --
>>>> > > > you
>>>> > > > >> > might
>>>> > > > >> > > > > have
>>>> > > > >> > > > > > > > meant
>>>> > > > >> > > > > > > > > trunk instead of master, and that would create
>>>> a new
>>>> > > > "3x"
>>>> > > > >> > > branch,
>>>> > > > >> > > > > > when
>>>> > > > >> > > > > > > > > there's already a "branch_3x" and that would be
>>>> > > > >> misnamed...
>>>> > > > >> > so
>>>> > > > >> > > > > maybe
>>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
>>>> aiming
>>>> > for
>>>> > > > >> lucene
>>>> > > > >> > > > 4.3.x
>>>> > > > >> > > > > > > > > compatibility?
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
>>>> > upstream
>>>> > > > >> want to
>>>> > > > >> > > > > create
>>>> > > > >> > > > > > > the
>>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're
>>>> not all
>>>> > > > >> trying to
>>>> > > > >> > > > > create
>>>> > > > >> > > > > > > them
>>>> > > > >> > > > > > > > > and dealing with a merge?
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > > Paul
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>>>> Syn-Hershko <
>>>> > > > >> > > > > > itamar@code972.com
>>>> > > > >> > > > > > > > > >wrote:
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > > > > Unless people here have a specific reason to
>>>> use
>>>> > > > 3.6.2 I
>>>> > > > >> > > would
>>>> > > > >> > > > > > highly
>>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
>>>> towards v4
>>>> > > > >> > otherwise
>>>> > > > >> > > we
>>>> > > > >> > > > > > will
>>>> > > > >> > > > > > > > > never
>>>> > > > >> > > > > > > > > > make it...
>>>> > > > >> > > > > > > > > >
>>>> > > > >> > > > > > > > > > Fork the repo from apache servers or github
>>>> (same
>>>> > > > repo,
>>>> > > > >> > > > different
>>>> > > > >> > > > > > > > > remotes)
>>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
>>>> should
>>>> > > work
>>>> > > > >> > > > > > > > > >
>>>> > > > >> > > > > > > > > >
>>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
>>>> > > > >> > > > > pirwin@feature23.com>
>>>> > > > >> > > > > > > > > wrote:
>>>> > > > >> > > > > > > > > >
>>>> > > > >> > > > > > > > > > > Itamar,
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > I agree that from scratch is not the best
>>>> way to
>>>> > > do
>>>> > > > >> it, I
>>>> > > > >> > > > just
>>>> > > > >> > > > > > > > thought
>>>> > > > >> > > > > > > > > > that
>>>> > > > >> > > > > > > > > > > was the "decision" that was made from the
>>>> > > discussion
>>>> > > > >> > > > previously
>>>> > > > >> > > > > > for
>>>> > > > >> > > > > > > > the
>>>> > > > >> > > > > > > > > > 4.x
>>>> > > > >> > > > > > > > > > > work. An incremental approach will be much
>>>> > better.
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
>>>> branch on
>>>> > > my
>>>> > > > >> fork
>>>> > > > >> > > and
>>>> > > > >> > > > > will
>>>> > > > >> > > > > > > > begin
>>>> > > > >> > > > > > > > > > > working on bringing the Analysis namespace
>>>> up to
>>>> > > > >> speed to
>>>> > > > >> > > > > 3.6.2.
>>>> > > > >> > > > > > If
>>>> > > > >> > > > > > > > > > anyone
>>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once
>>>> I'm
>>>> > > done,
>>>> > > > >> have
>>>> > > > >> > at
>>>> > > > >> > > > it.
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
>>>> branch_3x
>>>> > > > branch,
>>>> > > > >> > > please
>>>> > > > >> > > > > let
>>>> > > > >> > > > > > > me
>>>> > > > >> > > > > > > > > know
>>>> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > Paul
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>>>> > > Syn-Hershko <
>>>> > > > >> > > > > > > > itamar@code972.com
>>>> > > > >> > > > > > > > > > > >wrote:
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
>>>> again :)
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
>>>> know
>>>> > what
>>>> > > > it
>>>> > > > >> > would
>>>> > > > >> > > > > take
>>>> > > > >> > > > > > > > until
>>>> > > > >> > > > > > > > > > they
>>>> > > > >> > > > > > > > > > > > have deep dived into the work, and even
>>>> then
>>>> > > > >> decisions
>>>> > > > >> > > > could
>>>> > > > >> > > > > > and
>>>> > > > >> > > > > > > > will
>>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
>>>> > starting
>>>> > > > from
>>>> > > > >> > > > scratch,
>>>> > > > >> > > > > > > > > although
>>>> > > > >> > > > > > > > > > I
>>>> > > > >> > > > > > > > > > > do
>>>> > > > >> > > > > > > > > > > > think a lot in the current structure
>>>> should
>>>> > > > change,
>>>> > > > >> but
>>>> > > > >> > > its
>>>> > > > >> > > > > > going
>>>> > > > >> > > > > > > > to
>>>> > > > >> > > > > > > > > be
>>>> > > > >> > > > > > > > > > > > much easier to change it in place,
>>>> refactoring
>>>> > > > where
>>>> > > > >> > > > needed,
>>>> > > > >> > > > > > than
>>>> > > > >> > > > > > > > > > > starting
>>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this off I
>>>> > > > personally
>>>> > > > >> > will
>>>> > > > >> > > > be
>>>> > > > >> > > > > > > happy
>>>> > > > >> > > > > > > > > with
>>>> > > > >> > > > > > > > > > > you
>>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
>>>> porting
>>>> > > it,
>>>> > > > >> its
>>>> > > > >> > > > pretty
>>>> > > > >> > > > > > > much
>>>> > > > >> > > > > > > > > self
>>>> > > > >> > > > > > > > > > > > contained.
>>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on
>>>> a fork
>>>> > > and
>>>> > > > >> send
>>>> > > > >> > > us
>>>> > > > >> > > > > PRs,
>>>> > > > >> > > > > > > its
>>>> > > > >> > > > > > > > > > much
>>>> > > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
>>>> fastest
>>>> > > way
>>>> > > > >> to do
>>>> > > > >> > > > this,
>>>> > > > >> > > > > > we
>>>> > > > >> > > > > > > > can
>>>> > > > >> > > > > > > > > > then
>>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing
>>>> using
>>>> > > > .NET
>>>> > > > >> > > > > constructs.
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
>>>> create a
>>>> > > > branch
>>>> > > > >> out
>>>> > > > >> > > of
>>>> > > > >> > > > > the
>>>> > > > >> > > > > > > > > current
>>>> > > > >> > > > > > > > > > > git
>>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
>>>> > > working
>>>> > > > on
>>>> > > > >> > > master
>>>> > > > >> > > > > > > > towards a
>>>> > > > >> > > > > > > > > > 4.3
>>>> > > > >> > > > > > > > > > > > compatible version. The actual port
>>>> should be
>>>> > > > using
>>>> > > > >> a
>>>> > > > >> > > > process
>>>> > > > >> > > > > > > that
>>>> > > > >> > > > > > > > > > > ensures
>>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
>>>> tests,
>>>> > > and
>>>> > > > >> that
>>>> > > > >> > > > those
>>>> > > > >> > > > > > > tests
>>>> > > > >> > > > > > > > > > pass -
>>>> > > > >> > > > > > > > > > > > but I'm against committing any Java code
>>>> to
>>>> > our
>>>> > > > >> > > > repositories.
>>>> > > > >> > > > > > The
>>>> > > > >> > > > > > > > > > process
>>>> > > > >> > > > > > > > > > > > should probably be working on classes in
>>>> some
>>>> > > > order
>>>> > > > >> > > > > > > > (alphabetically,
>>>> > > > >> > > > > > > > > or
>>>> > > > >> > > > > > > > > > > > core classes first) and getting each
>>>> class to
>>>> > > > >> compile
>>>> > > > >> > > > before
>>>> > > > >> > > > > > > moving
>>>> > > > >> > > > > > > > > > > > forward. I don't mind about the project
>>>> not
>>>> > > being
>>>> > > > >> > > > compilable
>>>> > > > >> > > > > > for
>>>> > > > >> > > > > > > a
>>>> > > > >> > > > > > > > > > month
>>>> > > > >> > > > > > > > > > > or
>>>> > > > >> > > > > > > > > > > > two.
>>>> > > > >> > > > > > > > > > > > Once this is done a process of
>>>> .NETifying and
>>>> > > > >> proofing
>>>> > > > >> > > the
>>>> > > > >> > > > > code
>>>> > > > >> > > > > > > can
>>>> > > > >> > > > > > > > > be
>>>> > > > >> > > > > > > > > > > > started, at which point we will already
>>>> have a
>>>> > > > >> working
>>>> > > > >> > v4
>>>> > > > >> > > > > > version
>>>> > > > >> > > > > > > > so
>>>> > > > >> > > > > > > > > it
>>>> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
>>>> > project.
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
>>>> test
>>>> > > suite
>>>> > > > so
>>>> > > > >> > > tests
>>>> > > > >> > > > > > could
>>>> > > > >> > > > > > > > more
>>>> > > > >> > > > > > > > > > or
>>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
>>>> implementing
>>>> > > > >> Java-like
>>>> > > > >> > > > > > > assertEquals
>>>> > > > >> > > > > > > > > > > methods
>>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
>>>> work
>>>> > with
>>>> > > > >> than
>>>> > > > >> > > > > NUnit). I
>>>> > > > >> > > > > > > > > already
>>>> > > > >> > > > > > > > > > > did
>>>> > > > >> > > > > > > > > > > > some work there but there's still a lot
>>>> to do.
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
>>>> myself at
>>>> > > this
>>>> > > > >> > point,
>>>> > > > >> > > > > but I
>>>> > > > >> > > > > > > > > should
>>>> > > > >> > > > > > > > > > be
>>>> > > > >> > > > > > > > > > > > back in business in August, at which
>>>> point I
>>>> > can
>>>> > > > >> > dedicate
>>>> > > > >> > > > > > several
>>>> > > > >> > > > > > > > > > hours a
>>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
>>>> > closely
>>>> > > > and
>>>> > > > >> > even
>>>> > > > >> > > > > > > coordinate
>>>> > > > >> > > > > > > > > the
>>>> > > > >> > > > > > > > > > > > work to some extent.
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
>>>> Lima <
>>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
>>>> > > > >> > > > > > > > > > > > >wrote:
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this is a
>>>> kick
>>>> > > > start
>>>> > > > >> > =). I
>>>> > > > >> > > > > > haven't
>>>> > > > >> > > > > > > > > > > > contributed
>>>> > > > >> > > > > > > > > > > > > anything
>>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you all
>>>> to get
>>>> > > > this
>>>> > > > >> job
>>>> > > > >> > > > done.
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
>>>> Prescott.
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > I know that there is a high commitment
>>>> for
>>>> > > keep
>>>> > > > >> the
>>>> > > > >> > > > > > > > > > retrocompatibility
>>>> > > > >> > > > > > > > > > > on
>>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
>>>> > changes
>>>> > > > >> every
>>>> > > > >> > > > > release?
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
>>>> > version
>>>> > > > >> from a
>>>> > > > >> > > > > Lucene
>>>> > > > >> > > > > > > > > version,
>>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only
>>>> minor
>>>> > > changes
>>>> > > > >> > every
>>>> > > > >> > > > > stable
>>>> > > > >> > > > > > > > > release
>>>> > > > >> > > > > > > > > > > (or
>>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we could
>>>> > > compare
>>>> > > > >> the
>>>> > > > >> > > > > versions,
>>>> > > > >> > > > > > > > check
>>>> > > > >> > > > > > > > > > the
>>>> > > > >> > > > > > > > > > > > > differences and bring them to
>>>> Lucene.Net.
>>>> > > > Again, I
>>>> > > > >> > > > haven't
>>>> > > > >> > > > > > > > > > contributed
>>>> > > > >> > > > > > > > > > > > with
>>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
>>>> > idea).
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > What's your approach for implement
>>>> simple
>>>> > > > >> performance
>>>> > > > >> > > > > > > > improvements
>>>> > > > >> > > > > > > > > > > > (without
>>>> > > > >> > > > > > > > > > > > > adding references or changing methods
>>>> > > > signatures)?
>>>> > > > >> > Does
>>>> > > > >> > > > it
>>>> > > > >> > > > > > > could
>>>> > > > >> > > > > > > > be
>>>> > > > >> > > > > > > > > > > done,
>>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
>>>> pirwin@feature23.com>
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > This is just an "outsider"
>>>> suggestion as I
>>>> > > > >> haven't
>>>> > > > >> > > > > > > contributed
>>>> > > > >> > > > > > > > > > > anything
>>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely help
>>>> with
>>>> > > the
>>>> > > > >> 4.x
>>>> > > > >> > > work
>>>> > > > >> > > > > as I
>>>> > > > >> > > > > > > > have
>>>> > > > >> > > > > > > > > a
>>>> > > > >> > > > > > > > > > > > vested
>>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
>>>> completed. I
>>>> > > think
>>>> > > > >> > there
>>>> > > > >> > > > > should
>>>> > > > >> > > > > > > be
>>>> > > > >> > > > > > > > > one
>>>> > > > >> > > > > > > > > > > > person
>>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
>>>> > structure
>>>> > > > and
>>>> > > > >> > > > workflow
>>>> > > > >> > > > > > will
>>>> > > > >> > > > > > > > > look
>>>> > > > >> > > > > > > > > > > like
>>>> > > > >> > > > > > > > > > > > > to
>>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is
>>>> going to
>>>> > be
>>>> > > > >> > starting
>>>> > > > >> > > > from
>>>> > > > >> > > > > > > > scratch
>>>> > > > >> > > > > > > > > > as
>>>> > > > >> > > > > > > > > > > a
>>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set
>>>> up the
>>>> > > > >> project,
>>>> > > > >> > > get
>>>> > > > >> > > > > > > > everything
>>>> > > > >> > > > > > > > > > > going
>>>> > > > >> > > > > > > > > > > > > in
>>>> > > > >> > > > > > > > > > > > > > source control, create the folder
>>>> > structure,
>>>> > > > >> maybe
>>>> > > > >> > > stub
>>>> > > > >> > > > > out
>>>> > > > >> > > > > > > > some
>>>> > > > >> > > > > > > > > > > > classes,
>>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
>>>> anyone
>>>> > > > >> interested
>>>> > > > >> > > in
>>>> > > > >> > > > > > > > > > contributing,
>>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the java
>>>> code
>>>> > in
>>>> > > > >> there
>>>> > > > >> > so
>>>> > > > >> > > > > it's
>>>> > > > >> > > > > > > easy
>>>> > > > >> > > > > > > > > to
>>>> > > > >> > > > > > > > > > > > > > reference.
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > Again, I can work on
>>>> Lucene.Net.Documents,
>>>> > > > >> > > > > > > Lucene.Net.Analysis,
>>>> > > > >> > > > > > > > > or
>>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
>>>> those
>>>> > are
>>>> > > > >> just
>>>> > > > >> > the
>>>> > > > >> > > > > ones
>>>> > > > >> > > > > > > I'm
>>>> > > > >> > > > > > > > > most
>>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
>>>> Tell me
>>>> > > what
>>>> > > > >> to
>>>> > > > >> > do
>>>> > > > >> > > > and
>>>> > > > >> > > > > > I'll
>>>> > > > >> > > > > > > > get
>>>> > > > >> > > > > > > > > > > > started
>>>> > > > >> > > > > > > > > > > > > > on my fork.
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > Paul Irwin
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
>>>> Prescott
>>>> > > > Nasser
>>>> > > > >> <
>>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
>>>> > > > >> > > > > > > > > > > > > > >wrote:
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > > > Hey guys -
>>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
>>>> while. We
>>>> > > > have a
>>>> > > > >> > > board
>>>> > > > >> > > > > > report
>>>> > > > >> > > > > > > > due
>>>> > > > >> > > > > > > > > > > soon
>>>> > > > >> > > > > > > > > > > > -
>>>> > > > >> > > > > > > > > > > > > I
>>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise
>>>> them
>>>> > that
>>>> > > we
>>>> > > > >> seem
>>>> > > > >> > > to
>>>> > > > >> > > > > have
>>>> > > > >> > > > > > > > > stalled
>>>> > > > >> > > > > > > > > > > > > > somewhat.
>>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items
>>>> out of
>>>> > > of
>>>> > > > >> jira
>>>> > > > >> > > and
>>>> > > > >> > > > > have
>>>> > > > >> > > > > > > > been
>>>> > > > >> > > > > > > > > > > > > responsive
>>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
>>>> > > questions,
>>>> > > > >> but I
>>>> > > > >> > > > don't
>>>> > > > >> > > > > > > think
>>>> > > > >> > > > > > > > > > we've
>>>> > > > >> > > > > > > > > > > > > done
>>>> > > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
>>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
>>>> > start
>>>> > > us
>>>> > > > >> back
>>>> > > > >> > > up
>>>> > > > >> > > > > > moving
>>>> > > > >> > > > > > > > > > > forward.
>>>> > > > >> > > > > > > > > > > > > What
>>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish
>>>> this? If
>>>> > we
>>>> > > > took
>>>> > > > >> > the
>>>> > > > >> > > > java
>>>> > > > >> > > > > > > > lucene
>>>> > > > >> > > > > > > > > > 4.0
>>>> > > > >> > > > > > > > > > > > code
>>>> > > > >> > > > > > > > > > > > > > and
>>>> > > > >> > > > > > > > > > > > > > > committed that java to our branch
>>>> and
>>>> > then
>>>> > > > >> just
>>>> > > > >> > let
>>>> > > > >> > > > > > people
>>>> > > > >> > > > > > > > pull
>>>> > > > >> > > > > > > > > > > that
>>>> > > > >> > > > > > > > > > > > > down
>>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying is
>>>> that
>>>> > one
>>>> > > > >> way to
>>>> > > > >> > > > maybe
>>>> > > > >> > > > > > > make
>>>> > > > >> > > > > > > > > some
>>>> > > > >> > > > > > > > > > > > > forward
>>>> > > > >> > > > > > > > > > > > > > > progress?
>>>> > > > >> > > > > > > > > > > > > > > ~P
>>>> > > > >> > > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > > > --
>>>> > > > >> > > > > > > > > > > > > --
>>>> > > > >> > > > > > > > > > > > > Marcos Lima
>>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
>>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
>>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>>>> > > > >> > > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > > >
>>>> > > > >> > > > > > > > > > >
>>>> > > > >> > > > > > > > > >
>>>> > > > >> > > > > > > > >
>>>> > > > >> > > > > > > >
>>>> > > > >> > > > > > >
>>>> > > > >> > > > > >
>>>> > > > >> > > > >
>>>> > > > >> > > >
>>>> > > > >> > > >
>>>> > > > >> > > >
>>>> > > > >> > > > --
>>>> > > > >> > > > --
>>>> > > > >> > > > Marcos Lima
>>>> > > > >> > > > Software Developer/Tech Lead
>>>> > > > >> > > > marcoslimagon@gmail.com
>>>> > > > >> > > > tel: +55 (19) 9798-9335
>>>> > > > >> > > >
>>>> > > > >> > >
>>>> > > > >> >
>>>> > > > >>
>>>> > > > >>
>>>> > > > >>
>>>> > > > >> --
>>>> > > > >> --
>>>> > > > >> Marcos Lima
>>>> > > > >> Software Developer/Tech Lead
>>>> > > > >> marcoslimagon@gmail.com
>>>> > > > >> tel: +55 (19) 9798-9335
>>>> > > > >>
>>>> > > > >
>>>> > > > >
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
>>>
>>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
I made a dumb mistake... I have worked with StandardAnalyzer so long that I
forgot that KeywordAnalyzer is not what I needed to be using, I needed to
use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
Now it works after re-indexing with a quick, dirty implementation of
WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
also be read and searched by Java Lucene 4.3.1. Now I'm going to move on to
find out why NumericRangeQuery isn't working.
Sorry for the blast of emails, but I wanted to prevent people from spending
time hunting down my mistake!
On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pi...@feature23.com> wrote:
> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
> byte being signed is a pain.
>
> Now there's no exception doing a TermQuery, but I also don't get any
> results. It doesn't find any terms when scanning for them. I also tried a
> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
> didn't find any results that way either. So right now only
> MatchAllDocsQuery seems to work.
>
> If anyone would like to do a Google Hangout or anything sometime to look
> into it, let me know.
>
>
> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com> wrote:
>
>> I realized after I sent that email last night that I could do as you
>> described. When you've been debugging through CorruptedIndexExceptions, you
>> get a little bit of tunnel vision... haha
>>
>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
>> the matching documents prints the fields to the console, so it's loading in
>> the stored fields data correctly.
>>
>> I tried doing a TermQuery and now I get a "read past EOF" exception that
>> I can't figure out. There's a whole bunch of buffered byte array operations
>> going on and I can't determine where the issue came from. I'll keep
>> looking, but if someone could grab my fork/branch and help me look that
>> would be great. Here's example index writing and then reading code (also
>> included is a quick port of KeywordAnalyzer):
>> https://gist.github.com/anonymous/6174164
>>
>> Thanks!
>>
>>
>>
>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <it...@code972.com>wrote:
>>
>>> Great
>>>
>>> You can build you Query objects on your own to execute a search, you
>>> don't
>>> actually have to use QueryParser for that
>>>
>>>
>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com> wrote:
>>>
>>> > Hey all, sorry it's been a little while, but I wanted to let you know
>>> that
>>> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
>>> > Lucene.net core building and able to write a simple index in Lucene 4.2
>>> > codec and read in things like the number of documents and whatnot.
>>> Since
>>> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
>>> > haven't ported that yet so I haven't done a real search, and I only
>>> built
>>> > the index using a quick port of KeywordAnalyzer which all those
>>> analyzers
>>> > have also moved to another module. But this is definitely good
>>> progress and
>>> > should be a launch point for finishing a 4.3/4.4 port.
>>> >
>>> > You can see my fork/branch here:
>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note: like
>>> I
>>> > said, only core builds now, no modules/tests build, so only open the
>>> > Lucene.Net.Core.sln)
>>> >
>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart the
>>> > community into finishing the 4.3/4.4 port. Let me know if you have any
>>> > questions, thanks!
>>> >
>>> >
>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>> itamar@code972.com
>>> > >wrote:
>>> >
>>> > > Paul, that's awesome. I will need some more time to go over this
>>> thread
>>> > and
>>> > > your work to give actual feedback, SUPER busy at the moment
>>> > >
>>> > >
>>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
>>> > wrote:
>>> > >
>>> > > > All,
>>> > > >
>>> > > > My colleagues and I have made good progress on porting Lucene 4.3's
>>> > core
>>> > > > library before, during, and after the hackathon last week. We now
>>> only
>>> > > have
>>> > > > some remaining items in Search, Index, and Codecs namespaces (plus
>>> a
>>> > few
>>> > > > other minor ones here and there). I expect to be done by the end
>>> of the
>>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
>>> Packed),
>>> > > and
>>> > > > the root Codecs and Codecs.PerField namespaces are all now "done".
>>> > > >
>>> > > > Again, my goal is to only get a buildable, experimental build of
>>> > > Lucene.net
>>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>>> porting
>>> > > new
>>> > > > javadoc comments or unit tests right now, due to the vast amount of
>>> > code
>>> > > > that needs to be written just to get it to compile. If this work
>>> ends
>>> > up
>>> > > > becoming a pull request, great, otherwise it should help
>>> accelerate a
>>> > > port
>>> > > > of 4.3.x since the bulk of the work on core will already be done
>>> and
>>> > > > contributors can use it as a reference. And again, we're taking the
>>> > > > pragmatic approach of porting class-by-class,
>>> namespace-by-namespace,
>>> > > with
>>> > > > the understanding that until we're done the project won't build.
>>> > > >
>>> > > > Once complete, I also will work on updating the Analyzers contrib
>>> > module
>>> > > > and porting the QueryParsers contrib module, which I feel should be
>>> > > > included in the core NuGet package for Lucene.net as the core
>>> library
>>> > is
>>> > > > now (post-4.0) practically useless (or atleast not turn-key)
>>> without
>>> > > them.
>>> > > > You can check out the code on my fork/branch here:
>>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>> > > >
>>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
>>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For
>>> the
>>> > > MMap
>>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
>>> > > > MemoryMappedFile support which should emulate the Java nio stuff
>>> pretty
>>> > > > well, but required some creative shuffling of the code to make it
>>> work
>>> > > due
>>> > > > to lifecycle management.
>>> > > >
>>> > > > I'll update again this weekend or next week, when we should have
>>> > wrapped
>>> > > up
>>> > > > most of the main hacking on porting the core code.
>>> > > >
>>> > > > Paul
>>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com>
>>> > > wrote:
>>> > > >
>>> > > > > Marcos,
>>> > > > >
>>> > > > > That would be helpful. As far as I can tell, the 3.0 java code is
>>> > only
>>> > > on
>>> > > > > SVN here, before the lucene and solr projects were bundled
>>> together:
>>> > > > > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>>> > > > >
>>> > > > > The SVN for 4.3 java is here:
>>> > > > >
>>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>>> > > > > And the GitHub for 4.3 java is here:
>>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>>> > > > >
>>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
>>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>>> > > > >
>>> > > > > My fork is the "upstream" fork for my team members, and i'm
>>> remote
>>> > > > merging
>>> > > > > their changes in from their forks while they fetch/merge from
>>> mine to
>>> > > get
>>> > > > > everyone else's changes, rather than using pull requests. James
>>> and I
>>> > > > have
>>> > > > > been working the past few days on the Util namespace ahead of
>>> > tonight's
>>> > > > > hackathon since that namespace is in common with the rest of the
>>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
>>> > hacking
>>> > > on
>>> > > > > porting 4.3, each with a different namespace or part of a
>>> namespace.
>>> > > > Since
>>> > > > > we're going class-by-class, namespace-by-namespace, the project
>>> does
>>> > > not
>>> > > > > build as it is. Once we finish doing a translation of each file,
>>> then
>>> > > > we'll
>>> > > > > hammer out any remaining issues and get it to build again. I'm
>>> hoping
>>> > > > that
>>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
>>> > > > >
>>> > > > > But one thing to keep in mind is it looks like much
>>> functionality has
>>> > > > been
>>> > > > > moved out of core into the contrib modules, especially around
>>> > analysis,
>>> > > > for
>>> > > > > 4.0+. For example, there are no built-in analyzers in core
>>> anymore.
>>> > So
>>> > > > when
>>> > > > > this is all done, we may want to include at least the analysis
>>> > contrib
>>> > > > > module in with the standard core NuGet package, because otherwise
>>> > it's
>>> > > > > practically useless unless you roll your own analyzer.
>>> > > > >
>>> > > > > Paul
>>> > > > >
>>> > > > >
>>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>>> > marcoslimagon@gmail.com
>>> > > > >wrote:
>>> > > > >
>>> > > > >> Hi everyone!
>>> > > > >>
>>> > > > >> Does someone know where can I find the 3.0.3 release from
>>> > > Lucene(java)?
>>> > > > >>
>>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and
>>> 4.3.0 and
>>> > > > make
>>> > > > >> the diff between then and get all changes between releases... I
>>> > gonna
>>> > > > >> publish it here soon. (If you think there is another important
>>> > > release,
>>> > > > >> let
>>> > > > >> me know)
>>> > > > >>
>>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry) with
>>> > 4.3.0
>>> > > > >> port
>>> > > > >> for .Net on github (last email)?
>>> > > > >>
>>> > > > >> See you,
>>> > > > >>
>>> > > > >>
>>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>> > > > >>
>>> > > > >> > Thanks for the discussion points, Michael.
>>> > > > >> >
>>> > > > >> > I would vote for not worrying about trying to achieve portable
>>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+
>>> is
>>> > > > >> completed.
>>> > > > >> > Otherwise it may delay the project and stall it further.
>>> That's
>>> > just
>>> > > > my
>>> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
>>> > > > >> >
>>> > > > >> > I have started porting the changes from the core library
>>> (from the
>>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a
>>> separate
>>> > > > branch.
>>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my
>>> port
>>> > > until
>>> > > > >> > there's changes to pull from upstream to work from. Also due
>>> to my
>>> > > > time
>>> > > > >> > constraints, I am not fully documenting new methods that I'm
>>> > adding.
>>> > > > >> But if
>>> > > > >> > anyone wants to pull/copy/reference my changes while porting,
>>> > that's
>>> > > > >> > awesome. My branch currently does not build as I'm primarily
>>> going
>>> > > > >> > class-by-class, starting with the util namespace. Once we get
>>> the
>>> > > ball
>>> > > > >> > rolling on a community effort, I'll stop my rogue work and
>>> join
>>> > in.
>>> > > > But
>>> > > > >> > hopefully my work will be useful to someone, if not as a pull
>>> > > request
>>> > > > >> then
>>> > > > >> > as a reference. I'm also going to be holding a hackathon this
>>> week
>>> > > > with
>>> > > > >> my
>>> > > > >> > colleagues where we're all going to work on the port. I'm
>>> > comparing
>>> > > > >> files
>>> > > > >> > and making changes as necessary, rather than starting from
>>> > scratch.
>>> > > My
>>> > > > >> > repo/branch is here:
>>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>>> > > > >> >
>>> > > > >> > Paul
>>> > > > >> >
>>> > > > >> >
>>> > > > >> >
>>> > > > >> >
>>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>>> > > > >> > mherndon@michaelherndon.com> wrote:
>>> > > > >> >
>>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
>>> apache
>>> > > > >> > maintains.
>>> > > > >> > >
>>> > > > >> > > The was some work at one time to move the official svn
>>> > repository
>>> > > to
>>> > > > >> > start
>>> > > > >> > > using git one instead. Was that actually finalized or not?
>>> > > > >> > >
>>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to
>>> see
>>> > > what
>>> > > > >> kind
>>> > > > >> > of
>>> > > > >> > > work was involved using a portable libraries project. Some
>>> of it
>>> > > can
>>> > > > >> > still
>>> > > > >> > > be used but will need to be validated against the current
>>> > version
>>> > > of
>>> > > > >> > Java's
>>> > > > >> > > Lucene. It was also using .net 4.
>>> > > > >> > >
>>> > > > >> > > clean branch vs current. Its going to depend on what we
>>> > > support.
>>> > > > >> If
>>> > > > >> > you
>>> > > > >> > > support windows mobile 8, win RT, then the current code in
>>> trunk
>>> > > > will
>>> > > > >> not
>>> > > > >> > > compile against those versions of the framework which would
>>> a
>>> > > > >> frustrating
>>> > > > >> > > starting point, then you couldn't even run tests, which
>>> would
>>> > make
>>> > > > >> taking
>>> > > > >> > > patches very difficult. Supporting those can almost mean
>>> larger
>>> > > > gaps
>>> > > > >> in
>>> > > > >> > > design between Lucene.Net and its parent project.
>>> > > > >> > >
>>> > > > >> > > Also the structure has changed significantly between the
>>> > branches
>>> > > > and
>>> > > > >> > the
>>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6,
>>> and
>>> > > seems
>>> > > > >> > > significantly different. That doesn't mean you can't cherry
>>> > pick
>>> > > > >> stuff
>>> > > > >> > > from the other tags/branches that would still work as is. A
>>> > clean
>>> > > > >> branch
>>> > > > >> > > would also make it easier to get our build / tool chain in
>>> order
>>> > > as
>>> > > > >> you
>>> > > > >> > can
>>> > > > >> > > then do them incrementally versus having to do all the stuff
>>> > that
>>> > > I
>>> > > > >> did
>>> > > > >> > for
>>> > > > >> > > the 3x branch which saps energy and desire to code. It
>>> could
>>> > > also
>>> > > > >> make
>>> > > > >> > it
>>> > > > >> > > easier to see which classes have been ported or not.
>>> > > > >> > >
>>> > > > >> > > The major downside to a clean branch is extra work it
>>> requires
>>> > and
>>> > > > the
>>> > > > >> > > start up cost in time and energy of getting it in order,
>>> which
>>> > can
>>> > > > be
>>> > > > >> > > daunting / intimidating and lower morale. And generally you
>>> want
>>> > > to
>>> > > > >> use
>>> > > > >> > > take your legacy code and refactor instead of in someways
>>> > starting
>>> > > > >> over.
>>> > > > >> > >
>>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
>>> > something
>>> > > > >> similar
>>> > > > >> > > to
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> >
>>> > > > >>
>>> > > >
>>> > >
>>> >
>>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>>> > > > >> > > where it tracks what needs to get ported / what has been
>>> ported.
>>> > > > >> > >
>>> > > > >> > > What are we going to support in the next version?
>>> > > > >> > >
>>> > > > >> > > Who is going to work on the next version?
>>> > > > >> > >
>>> > > > >> > > What would make the most sense and what would invigorate the
>>> > > > >> community to
>>> > > > >> > > get involved more and lower the barrier to entry?
>>> > > > >> > >
>>> > > > >> > > I think those are the questions that would make a lot of the
>>> > > > decisions
>>> > > > >> > for
>>> > > > >> > > us so that we can get back to work on lucene.net.
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>>> > > > marcoslimagon@gmail.com
>>> > > > >> > > >wrote:
>>> > > > >> > >
>>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF
>>> projects...
>>> > > > >> > > >
>>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>>> > > > >> > > > https://github.com/apache/lucene.net points to the same
>>> > > > repository?
>>> > > > >> > > (This
>>> > > > >> > > > is new for me, pretty good) Which of them do you recommend
>>> > (i'm
>>> > > > used
>>> > > > >> > with
>>> > > > >> > > > SVN and its patterns).
>>> > > > >> > > >
>>> > > > >> > > > I'm checking the subversion right now.
>>> > > > >> > > >
>>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a
>>> old
>>> > > > branch,
>>> > > > >> i`m
>>> > > > >> > > not
>>> > > > >> > > > sure about its current status.
>>> > > > >> > > >
>>> > > > >> > > > Will we wipe the current solution from /trunk and start a
>>> new
>>> > > one?
>>> > > > >> > > >
>>> > > > >> > > > Thanks,
>>> > > > >> > > >
>>> > > > >> > > >
>>> > > > >> > > >
>>> > > > >> > > >
>>> > > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
>>> > > > >> > > >
>>> > > > >> > > > > We may be forced to start with a clean/empty branch if
>>> > people
>>> > > > >> still
>>> > > > >> > > want
>>> > > > >> > > > to
>>> > > > >> > > > > attempt supporting lucene.net for mobile devices, win
>>> RT,
>>> > > etc.
>>> > > > >> The
>>> > > > >> > are
>>> > > > >> > > > > many
>>> > > > >> > > > > classes that Lucene.net uses from the full framework
>>> that
>>> > > would
>>> > > > >> not
>>> > > > >> > be
>>> > > > >> > > > > accessible in other versions of the .NET Framework. It
>>> also
>>> > > > might
>>> > > > >> > > > require
>>> > > > >> > > > > a design that differs even more from its parent project.
>>> > > > >> > > > >
>>> > > > >> > > > > It might be wise to poll what users most desire in the
>>> next
>>> > > > >> version
>>> > > > >> > > > through
>>> > > > >> > > > > jira or user voice.
>>> > > > >> > > > >
>>> > > > >> > > > >
>>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>>> > > > >> > itamar@code972.com
>>> > > > >> > > > > >wrote:
>>> > > > >> > > > >
>>> > > > >> > > > > > inline
>>> > > > >> > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>>> > > > >> pirwin@feature23.com>
>>> > > > >> > > > wrote:
>>> > > > >> > > > > >
>>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been
>>> a TFS
>>> > > guy
>>> > > > >> for
>>> > > > >> > so
>>> > > > >> > > > > long
>>> > > > >> > > > > > > :-)
>>> > > > >> > > > > > >
>>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
>>> patches
>>> > or
>>> > > > >> > anything
>>> > > > >> > > > to
>>> > > > >> > > > > > the
>>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we will
>>> > branch
>>> > > > from
>>> > > > >> > for
>>> > > > >> > > 4x
>>> > > > >> > > > > > dev.
>>> > > > >> > > > > > > Correct?
>>> > > > >> > > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
>>> anyone
>>> > > will
>>> > > > >> be
>>> > > > >> > > > > > interested in that
>>> > > > >> > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > > > >
>>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal
>>> with
>>> > > the
>>> > > > >> > github
>>> > > > >> > > > > sync?
>>> > > > >> > > > > > > Who could diagnose that?
>>> > > > >> > > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the apache
>>> > repo
>>> > > > for
>>> > > > >> now
>>> > > > >> > > > while
>>> > > > >> > > > > > we get that sorted out.
>>> > > > >> > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > > > >
>>> > > > >> > > > > > >
>>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
>>> > > > >> > > > itamar@code972.com
>>> > > > >> > > > > > > >wrote:
>>> > > > >> > > > > > >
>>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it then
>>> for
>>> > > 3.x
>>> > > > >> > > > > development.
>>> > > > >> > > > > > > WRT
>>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on whatever
>>> > > branch.
>>> > > > >> When
>>> > > > >> > > you
>>> > > > >> > > > > > send
>>> > > > >> > > > > > > us
>>> > > > >> > > > > > > > PRs we will merge either to master or to a
>>> dedicated
>>> > > repo.
>>> > > > >> For
>>> > > > >> > > now
>>> > > > >> > > > it
>>> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
>>> > > > >> > > > > > > >
>>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see it
>>> on
>>> > the
>>> > > > >> apache
>>> > > > >> > > > > servers
>>> > > > >> > > > > > > > (github sync seems to be off)
>>> > > > >> > > > > > > >
>>> > > > >> > > > > > > >
>>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>>> > > > >> > > pirwin@feature23.com>
>>> > > > >> > > > > > > wrote:
>>> > > > >> > > > > > > >
>>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3
>>> > > version
>>> > > > >> of
>>> > > > >> > the
>>> > > > >> > > > > > > Analysis
>>> > > > >> > > > > > > > > namespace.
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > > Not sure the checkout command is what you
>>> intended
>>> > --
>>> > > > you
>>> > > > >> > might
>>> > > > >> > > > > have
>>> > > > >> > > > > > > > meant
>>> > > > >> > > > > > > > > trunk instead of master, and that would create
>>> a new
>>> > > > "3x"
>>> > > > >> > > branch,
>>> > > > >> > > > > > when
>>> > > > >> > > > > > > > > there's already a "branch_3x" and that would be
>>> > > > >> misnamed...
>>> > > > >> > so
>>> > > > >> > > > > maybe
>>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
>>> aiming
>>> > for
>>> > > > >> lucene
>>> > > > >> > > > 4.3.x
>>> > > > >> > > > > > > > > compatibility?
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > > Also, does someone with commit rights to the
>>> > upstream
>>> > > > >> want to
>>> > > > >> > > > > create
>>> > > > >> > > > > > > the
>>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're not
>>> all
>>> > > > >> trying to
>>> > > > >> > > > > create
>>> > > > >> > > > > > > them
>>> > > > >> > > > > > > > > and dealing with a merge?
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > > Paul
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>>> Syn-Hershko <
>>> > > > >> > > > > > itamar@code972.com
>>> > > > >> > > > > > > > > >wrote:
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > > > > Unless people here have a specific reason to
>>> use
>>> > > > 3.6.2 I
>>> > > > >> > > would
>>> > > > >> > > > > > highly
>>> > > > >> > > > > > > > > > recommed putting all the efforts we can
>>> towards v4
>>> > > > >> > otherwise
>>> > > > >> > > we
>>> > > > >> > > > > > will
>>> > > > >> > > > > > > > > never
>>> > > > >> > > > > > > > > > make it...
>>> > > > >> > > > > > > > > >
>>> > > > >> > > > > > > > > > Fork the repo from apache servers or github
>>> (same
>>> > > > repo,
>>> > > > >> > > > different
>>> > > > >> > > > > > > > > remotes)
>>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
>>> should
>>> > > work
>>> > > > >> > > > > > > > > >
>>> > > > >> > > > > > > > > >
>>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
>>> > > > >> > > > > pirwin@feature23.com>
>>> > > > >> > > > > > > > > wrote:
>>> > > > >> > > > > > > > > >
>>> > > > >> > > > > > > > > > > Itamar,
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > I agree that from scratch is not the best
>>> way to
>>> > > do
>>> > > > >> it, I
>>> > > > >> > > > just
>>> > > > >> > > > > > > > thought
>>> > > > >> > > > > > > > > > that
>>> > > > >> > > > > > > > > > > was the "decision" that was made from the
>>> > > discussion
>>> > > > >> > > > previously
>>> > > > >> > > > > > for
>>> > > > >> > > > > > > > the
>>> > > > >> > > > > > > > > > 4.x
>>> > > > >> > > > > > > > > > > work. An incremental approach will be much
>>> > better.
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
>>> branch on
>>> > > my
>>> > > > >> fork
>>> > > > >> > > and
>>> > > > >> > > > > will
>>> > > > >> > > > > > > > begin
>>> > > > >> > > > > > > > > > > working on bringing the Analysis namespace
>>> up to
>>> > > > >> speed to
>>> > > > >> > > > > 3.6.2.
>>> > > > >> > > > > > If
>>> > > > >> > > > > > > > > > anyone
>>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once
>>> I'm
>>> > > done,
>>> > > > >> have
>>> > > > >> > at
>>> > > > >> > > > it.
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
>>> branch_3x
>>> > > > branch,
>>> > > > >> > > please
>>> > > > >> > > > > let
>>> > > > >> > > > > > > me
>>> > > > >> > > > > > > > > know
>>> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > Paul
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>>> > > Syn-Hershko <
>>> > > > >> > > > > > > > itamar@code972.com
>>> > > > >> > > > > > > > > > > >wrote:
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up
>>> again :)
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really
>>> know
>>> > what
>>> > > > it
>>> > > > >> > would
>>> > > > >> > > > > take
>>> > > > >> > > > > > > > until
>>> > > > >> > > > > > > > > > they
>>> > > > >> > > > > > > > > > > > have deep dived into the work, and even
>>> then
>>> > > > >> decisions
>>> > > > >> > > > could
>>> > > > >> > > > > > and
>>> > > > >> > > > > > > > will
>>> > > > >> > > > > > > > > > > > change. I will strongly advise against
>>> > starting
>>> > > > from
>>> > > > >> > > > scratch,
>>> > > > >> > > > > > > > > although
>>> > > > >> > > > > > > > > > I
>>> > > > >> > > > > > > > > > > do
>>> > > > >> > > > > > > > > > > > think a lot in the current structure
>>> should
>>> > > > change,
>>> > > > >> but
>>> > > > >> > > its
>>> > > > >> > > > > > going
>>> > > > >> > > > > > > > to
>>> > > > >> > > > > > > > > be
>>> > > > >> > > > > > > > > > > > much easier to change it in place,
>>> refactoring
>>> > > > where
>>> > > > >> > > > needed,
>>> > > > >> > > > > > than
>>> > > > >> > > > > > > > > > > starting
>>> > > > >> > > > > > > > > > > > all over again. Once we kicked this off I
>>> > > > personally
>>> > > > >> > will
>>> > > > >> > > > be
>>> > > > >> > > > > > > happy
>>> > > > >> > > > > > > > > with
>>> > > > >> > > > > > > > > > > you
>>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
>>> porting
>>> > > it,
>>> > > > >> its
>>> > > > >> > > > pretty
>>> > > > >> > > > > > > much
>>> > > > >> > > > > > > > > self
>>> > > > >> > > > > > > > > > > > contained.
>>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a
>>> fork
>>> > > and
>>> > > > >> send
>>> > > > >> > > us
>>> > > > >> > > > > PRs,
>>> > > > >> > > > > > > its
>>> > > > >> > > > > > > > > > much
>>> > > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
>>> fastest
>>> > > way
>>> > > > >> to do
>>> > > > >> > > > this,
>>> > > > >> > > > > > we
>>> > > > >> > > > > > > > can
>>> > > > >> > > > > > > > > > then
>>> > > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing
>>> using
>>> > > > .NET
>>> > > > >> > > > > constructs.
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > That said, I think the way to go is
>>> create a
>>> > > > branch
>>> > > > >> out
>>> > > > >> > > of
>>> > > > >> > > > > the
>>> > > > >> > > > > > > > > current
>>> > > > >> > > > > > > > > > > git
>>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
>>> > > working
>>> > > > on
>>> > > > >> > > master
>>> > > > >> > > > > > > > towards a
>>> > > > >> > > > > > > > > > 4.3
>>> > > > >> > > > > > > > > > > > compatible version. The actual port
>>> should be
>>> > > > using
>>> > > > >> a
>>> > > > >> > > > process
>>> > > > >> > > > > > > that
>>> > > > >> > > > > > > > > > > ensures
>>> > > > >> > > > > > > > > > > > all Java classes are ported with their
>>> tests,
>>> > > and
>>> > > > >> that
>>> > > > >> > > > those
>>> > > > >> > > > > > > tests
>>> > > > >> > > > > > > > > > pass -
>>> > > > >> > > > > > > > > > > > but I'm against committing any Java code
>>> to
>>> > our
>>> > > > >> > > > repositories.
>>> > > > >> > > > > > The
>>> > > > >> > > > > > > > > > process
>>> > > > >> > > > > > > > > > > > should probably be working on classes in
>>> some
>>> > > > order
>>> > > > >> > > > > > > > (alphabetically,
>>> > > > >> > > > > > > > > or
>>> > > > >> > > > > > > > > > > > core classes first) and getting each
>>> class to
>>> > > > >> compile
>>> > > > >> > > > before
>>> > > > >> > > > > > > moving
>>> > > > >> > > > > > > > > > > > forward. I don't mind about the project
>>> not
>>> > > being
>>> > > > >> > > > compilable
>>> > > > >> > > > > > for
>>> > > > >> > > > > > > a
>>> > > > >> > > > > > > > > > month
>>> > > > >> > > > > > > > > > > or
>>> > > > >> > > > > > > > > > > > two.
>>> > > > >> > > > > > > > > > > > Once this is done a process of .NETifying
>>> and
>>> > > > >> proofing
>>> > > > >> > > the
>>> > > > >> > > > > code
>>> > > > >> > > > > > > can
>>> > > > >> > > > > > > > > be
>>> > > > >> > > > > > > > > > > > started, at which point we will already
>>> have a
>>> > > > >> working
>>> > > > >> > v4
>>> > > > >> > > > > > version
>>> > > > >> > > > > > > > so
>>> > > > >> > > > > > > > > it
>>> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
>>> > project.
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the
>>> test
>>> > > suite
>>> > > > so
>>> > > > >> > > tests
>>> > > > >> > > > > > could
>>> > > > >> > > > > > > > more
>>> > > > >> > > > > > > > > > or
>>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
>>> implementing
>>> > > > >> Java-like
>>> > > > >> > > > > > > assertEquals
>>> > > > >> > > > > > > > > > > methods
>>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to
>>> work
>>> > with
>>> > > > >> than
>>> > > > >> > > > > NUnit). I
>>> > > > >> > > > > > > > > already
>>> > > > >> > > > > > > > > > > did
>>> > > > >> > > > > > > > > > > > some work there but there's still a lot
>>> to do.
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time
>>> myself at
>>> > > this
>>> > > > >> > point,
>>> > > > >> > > > > but I
>>> > > > >> > > > > > > > > should
>>> > > > >> > > > > > > > > > be
>>> > > > >> > > > > > > > > > > > back in business in August, at which
>>> point I
>>> > can
>>> > > > >> > dedicate
>>> > > > >> > > > > > several
>>> > > > >> > > > > > > > > > hours a
>>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
>>> > closely
>>> > > > and
>>> > > > >> > even
>>> > > > >> > > > > > > coordinate
>>> > > > >> > > > > > > > > the
>>> > > > >> > > > > > > > > > > > work to some extent.
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
>>> Lima <
>>> > > > >> > > > > > > > > marcoslimagon@gmail.com
>>> > > > >> > > > > > > > > > > > >wrote:
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > It really sounds good to me, this is a
>>> kick
>>> > > > start
>>> > > > >> > =). I
>>> > > > >> > > > > > haven't
>>> > > > >> > > > > > > > > > > > contributed
>>> > > > >> > > > > > > > > > > > > anything
>>> > > > >> > > > > > > > > > > > > yet, but I would like to help you all
>>> to get
>>> > > > this
>>> > > > >> job
>>> > > > >> > > > done.
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
>>> Prescott.
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > I know that there is a high commitment
>>> for
>>> > > keep
>>> > > > >> the
>>> > > > >> > > > > > > > > > retrocompatibility
>>> > > > >> > > > > > > > > > > on
>>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
>>> > changes
>>> > > > >> every
>>> > > > >> > > > > release?
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
>>> > version
>>> > > > >> from a
>>> > > > >> > > > > Lucene
>>> > > > >> > > > > > > > > version,
>>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only minor
>>> > > changes
>>> > > > >> > every
>>> > > > >> > > > > stable
>>> > > > >> > > > > > > > > release
>>> > > > >> > > > > > > > > > > (or
>>> > > > >> > > > > > > > > > > > > keep most of its source-code), we could
>>> > > compare
>>> > > > >> the
>>> > > > >> > > > > versions,
>>> > > > >> > > > > > > > check
>>> > > > >> > > > > > > > > > the
>>> > > > >> > > > > > > > > > > > > differences and bring them to
>>> Lucene.Net.
>>> > > > Again, I
>>> > > > >> > > > haven't
>>> > > > >> > > > > > > > > > contributed
>>> > > > >> > > > > > > > > > > > with
>>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
>>> > idea).
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > What's your approach for implement
>>> simple
>>> > > > >> performance
>>> > > > >> > > > > > > > improvements
>>> > > > >> > > > > > > > > > > > (without
>>> > > > >> > > > > > > > > > > > > adding references or changing methods
>>> > > > signatures)?
>>> > > > >> > Does
>>> > > > >> > > > it
>>> > > > >> > > > > > > could
>>> > > > >> > > > > > > > be
>>> > > > >> > > > > > > > > > > done,
>>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
>>> pirwin@feature23.com>
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > This is just an "outsider" suggestion
>>> as I
>>> > > > >> haven't
>>> > > > >> > > > > > > contributed
>>> > > > >> > > > > > > > > > > anything
>>> > > > >> > > > > > > > > > > > > > yet, although I will definitely help
>>> with
>>> > > the
>>> > > > >> 4.x
>>> > > > >> > > work
>>> > > > >> > > > > as I
>>> > > > >> > > > > > > > have
>>> > > > >> > > > > > > > > a
>>> > > > >> > > > > > > > > > > > vested
>>> > > > >> > > > > > > > > > > > > > interest in seeing that get
>>> completed. I
>>> > > think
>>> > > > >> > there
>>> > > > >> > > > > should
>>> > > > >> > > > > > > be
>>> > > > >> > > > > > > > > one
>>> > > > >> > > > > > > > > > > > person
>>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
>>> > structure
>>> > > > and
>>> > > > >> > > > workflow
>>> > > > >> > > > > > will
>>> > > > >> > > > > > > > > look
>>> > > > >> > > > > > > > > > > like
>>> > > > >> > > > > > > > > > > > > to
>>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going
>>> to
>>> > be
>>> > > > >> > starting
>>> > > > >> > > > from
>>> > > > >> > > > > > > > scratch
>>> > > > >> > > > > > > > > > as
>>> > > > >> > > > > > > > > > > a
>>> > > > >> > > > > > > > > > > > > > fresh port, that person should set up
>>> the
>>> > > > >> project,
>>> > > > >> > > get
>>> > > > >> > > > > > > > everything
>>> > > > >> > > > > > > > > > > going
>>> > > > >> > > > > > > > > > > > > in
>>> > > > >> > > > > > > > > > > > > > source control, create the folder
>>> > structure,
>>> > > > >> maybe
>>> > > > >> > > stub
>>> > > > >> > > > > out
>>> > > > >> > > > > > > > some
>>> > > > >> > > > > > > > > > > > classes,
>>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
>>> anyone
>>> > > > >> interested
>>> > > > >> > > in
>>> > > > >> > > > > > > > > > contributing,
>>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the java
>>> code
>>> > in
>>> > > > >> there
>>> > > > >> > so
>>> > > > >> > > > > it's
>>> > > > >> > > > > > > easy
>>> > > > >> > > > > > > > > to
>>> > > > >> > > > > > > > > > > > > > reference.
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > Again, I can work on
>>> Lucene.Net.Documents,
>>> > > > >> > > > > > > Lucene.Net.Analysis,
>>> > > > >> > > > > > > > > or
>>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
>>> those
>>> > are
>>> > > > >> just
>>> > > > >> > the
>>> > > > >> > > > > ones
>>> > > > >> > > > > > > I'm
>>> > > > >> > > > > > > > > most
>>> > > > >> > > > > > > > > > > > > > familiar with the inner workings.
>>> Tell me
>>> > > what
>>> > > > >> to
>>> > > > >> > do
>>> > > > >> > > > and
>>> > > > >> > > > > > I'll
>>> > > > >> > > > > > > > get
>>> > > > >> > > > > > > > > > > > started
>>> > > > >> > > > > > > > > > > > > > on my fork.
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > Paul Irwin
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
>>> Prescott
>>> > > > Nasser
>>> > > > >> <
>>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
>>> > > > >> > > > > > > > > > > > > > >wrote:
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > > > Hey guys -
>>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little
>>> while. We
>>> > > > have a
>>> > > > >> > > board
>>> > > > >> > > > > > report
>>> > > > >> > > > > > > > due
>>> > > > >> > > > > > > > > > > soon
>>> > > > >> > > > > > > > > > > > -
>>> > > > >> > > > > > > > > > > > > I
>>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise them
>>> > that
>>> > > we
>>> > > > >> seem
>>> > > > >> > > to
>>> > > > >> > > > > have
>>> > > > >> > > > > > > > > stalled
>>> > > > >> > > > > > > > > > > > > > somewhat.
>>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items
>>> out of
>>> > > of
>>> > > > >> jira
>>> > > > >> > > and
>>> > > > >> > > > > have
>>> > > > >> > > > > > > > been
>>> > > > >> > > > > > > > > > > > > responsive
>>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
>>> > > questions,
>>> > > > >> but I
>>> > > > >> > > > don't
>>> > > > >> > > > > > > think
>>> > > > >> > > > > > > > > > we've
>>> > > > >> > > > > > > > > > > > > done
>>> > > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
>>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
>>> > start
>>> > > us
>>> > > > >> back
>>> > > > >> > > up
>>> > > > >> > > > > > moving
>>> > > > >> > > > > > > > > > > forward.
>>> > > > >> > > > > > > > > > > > > What
>>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish this?
>>> If
>>> > we
>>> > > > took
>>> > > > >> > the
>>> > > > >> > > > java
>>> > > > >> > > > > > > > lucene
>>> > > > >> > > > > > > > > > 4.0
>>> > > > >> > > > > > > > > > > > code
>>> > > > >> > > > > > > > > > > > > > and
>>> > > > >> > > > > > > > > > > > > > > committed that java to our branch
>>> and
>>> > then
>>> > > > >> just
>>> > > > >> > let
>>> > > > >> > > > > > people
>>> > > > >> > > > > > > > pull
>>> > > > >> > > > > > > > > > > that
>>> > > > >> > > > > > > > > > > > > down
>>> > > > >> > > > > > > > > > > > > > > and being changing / modifying is
>>> that
>>> > one
>>> > > > >> way to
>>> > > > >> > > > maybe
>>> > > > >> > > > > > > make
>>> > > > >> > > > > > > > > some
>>> > > > >> > > > > > > > > > > > > forward
>>> > > > >> > > > > > > > > > > > > > > progress?
>>> > > > >> > > > > > > > > > > > > > > ~P
>>> > > > >> > > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > > > --
>>> > > > >> > > > > > > > > > > > > --
>>> > > > >> > > > > > > > > > > > > Marcos Lima
>>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
>>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
>>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>>> > > > >> > > > > > > > > > > > >
>>> > > > >> > > > > > > > > > > >
>>> > > > >> > > > > > > > > > >
>>> > > > >> > > > > > > > > >
>>> > > > >> > > > > > > > >
>>> > > > >> > > > > > > >
>>> > > > >> > > > > > >
>>> > > > >> > > > > >
>>> > > > >> > > > >
>>> > > > >> > > >
>>> > > > >> > > >
>>> > > > >> > > >
>>> > > > >> > > > --
>>> > > > >> > > > --
>>> > > > >> > > > Marcos Lima
>>> > > > >> > > > Software Developer/Tech Lead
>>> > > > >> > > > marcoslimagon@gmail.com
>>> > > > >> > > > tel: +55 (19) 9798-9335
>>> > > > >> > > >
>>> > > > >> > >
>>> > > > >> >
>>> > > > >>
>>> > > > >>
>>> > > > >>
>>> > > > >> --
>>> > > > >> --
>>> > > > >> Marcos Lima
>>> > > > >> Software Developer/Tech Lead
>>> > > > >> marcoslimagon@gmail.com
>>> > > > >> tel: +55 (19) 9798-9335
>>> > > > >>
>>> > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
byte being signed is a pain.
Now there's no exception doing a TermQuery, but I also don't get any
results. It doesn't find any terms when scanning for them. I also tried a
NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
didn't find any results that way either. So right now only
MatchAllDocsQuery seems to work.
If anyone would like to do a Google Hangout or anything sometime to look
into it, let me know.
On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pi...@feature23.com> wrote:
> I realized after I sent that email last night that I could do as you
> described. When you've been debugging through CorruptedIndexExceptions, you
> get a little bit of tunnel vision... haha
>
> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
> the matching documents prints the fields to the console, so it's loading in
> the stored fields data correctly.
>
> I tried doing a TermQuery and now I get a "read past EOF" exception that I
> can't figure out. There's a whole bunch of buffered byte array operations
> going on and I can't determine where the issue came from. I'll keep
> looking, but if someone could grab my fork/branch and help me look that
> would be great. Here's example index writing and then reading code (also
> included is a quick port of KeywordAnalyzer):
> https://gist.github.com/anonymous/6174164
>
> Thanks!
>
>
>
> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <it...@code972.com>wrote:
>
>> Great
>>
>> You can build you Query objects on your own to execute a search, you don't
>> actually have to use QueryParser for that
>>
>>
>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com> wrote:
>>
>> > Hey all, sorry it's been a little while, but I wanted to let you know
>> that
>> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
>> > Lucene.net core building and able to write a simple index in Lucene 4.2
>> > codec and read in things like the number of documents and whatnot. Since
>> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
>> > haven't ported that yet so I haven't done a real search, and I only
>> built
>> > the index using a quick port of KeywordAnalyzer which all those
>> analyzers
>> > have also moved to another module. But this is definitely good progress
>> and
>> > should be a launch point for finishing a 4.3/4.4 port.
>> >
>> > You can see my fork/branch here:
>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note: like I
>> > said, only core builds now, no modules/tests build, so only open the
>> > Lucene.Net.Core.sln)
>> >
>> > I'm sure it's riddled with bugs, but I hope this can help kickstart the
>> > community into finishing the 4.3/4.4 port. Let me know if you have any
>> > questions, thanks!
>> >
>> >
>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <itamar@code972.com
>> > >wrote:
>> >
>> > > Paul, that's awesome. I will need some more time to go over this
>> thread
>> > and
>> > > your work to give actual feedback, SUPER busy at the moment
>> > >
>> > >
>> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
>> > wrote:
>> > >
>> > > > All,
>> > > >
>> > > > My colleagues and I have made good progress on porting Lucene 4.3's
>> > core
>> > > > library before, during, and after the hackathon last week. We now
>> only
>> > > have
>> > > > some remaining items in Search, Index, and Codecs namespaces (plus a
>> > few
>> > > > other minor ones here and there). I expect to be done by the end of
>> the
>> > > > weekend. Analysis, Documents, Store, Util (except some FST and
>> Packed),
>> > > and
>> > > > the root Codecs and Codecs.PerField namespaces are all now "done".
>> > > >
>> > > > Again, my goal is to only get a buildable, experimental build of
>> > > Lucene.net
>> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
>> porting
>> > > new
>> > > > javadoc comments or unit tests right now, due to the vast amount of
>> > code
>> > > > that needs to be written just to get it to compile. If this work
>> ends
>> > up
>> > > > becoming a pull request, great, otherwise it should help accelerate
>> a
>> > > port
>> > > > of 4.3.x since the bulk of the work on core will already be done and
>> > > > contributors can use it as a reference. And again, we're taking the
>> > > > pragmatic approach of porting class-by-class,
>> namespace-by-namespace,
>> > > with
>> > > > the understanding that until we're done the project won't build.
>> > > >
>> > > > Once complete, I also will work on updating the Analyzers contrib
>> > module
>> > > > and porting the QueryParsers contrib module, which I feel should be
>> > > > included in the core NuGet package for Lucene.net as the core
>> library
>> > is
>> > > > now (post-4.0) practically useless (or atleast not turn-key) without
>> > > them.
>> > > > You can check out the code on my fork/branch here:
>> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>> > > >
>> > > > In particular, I'd like some feedback on my work on ByteBuffer,
>> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For
>> the
>> > > MMap
>> > > > support, I created a ByteBuffer subclass that uses .NET 4's
>> > > > MemoryMappedFile support which should emulate the Java nio stuff
>> pretty
>> > > > well, but required some creative shuffling of the code to make it
>> work
>> > > due
>> > > > to lifecycle management.
>> > > >
>> > > > I'll update again this weekend or next week, when we should have
>> > wrapped
>> > > up
>> > > > most of the main hacking on porting the core code.
>> > > >
>> > > > Paul
>> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com>
>> > > wrote:
>> > > >
>> > > > > Marcos,
>> > > > >
>> > > > > That would be helpful. As far as I can tell, the 3.0 java code is
>> > only
>> > > on
>> > > > > SVN here, before the lucene and solr projects were bundled
>> together:
>> > > > > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>> > > > >
>> > > > > The SVN for 4.3 java is here:
>> > > > >
>> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
>> > > > > And the GitHub for 4.3 java is here:
>> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>> > > > >
>> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
>> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>> > > > >
>> > > > > My fork is the "upstream" fork for my team members, and i'm remote
>> > > > merging
>> > > > > their changes in from their forks while they fetch/merge from
>> mine to
>> > > get
>> > > > > everyone else's changes, rather than using pull requests. James
>> and I
>> > > > have
>> > > > > been working the past few days on the Util namespace ahead of
>> > tonight's
>> > > > > hackathon since that namespace is in common with the rest of the
>> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
>> > hacking
>> > > on
>> > > > > porting 4.3, each with a different namespace or part of a
>> namespace.
>> > > > Since
>> > > > > we're going class-by-class, namespace-by-namespace, the project
>> does
>> > > not
>> > > > > build as it is. Once we finish doing a translation of each file,
>> then
>> > > > we'll
>> > > > > hammer out any remaining issues and get it to build again. I'm
>> hoping
>> > > > that
>> > > > > we can get at least 75% done with Core tonight. Wish us luck!
>> > > > >
>> > > > > But one thing to keep in mind is it looks like much functionality
>> has
>> > > > been
>> > > > > moved out of core into the contrib modules, especially around
>> > analysis,
>> > > > for
>> > > > > 4.0+. For example, there are no built-in analyzers in core
>> anymore.
>> > So
>> > > > when
>> > > > > this is all done, we may want to include at least the analysis
>> > contrib
>> > > > > module in with the standard core NuGet package, because otherwise
>> > it's
>> > > > > practically useless unless you roll your own analyzer.
>> > > > >
>> > > > > Paul
>> > > > >
>> > > > >
>> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
>> > marcoslimagon@gmail.com
>> > > > >wrote:
>> > > > >
>> > > > >> Hi everyone!
>> > > > >>
>> > > > >> Does someone know where can I find the 3.0.3 release from
>> > > Lucene(java)?
>> > > > >>
>> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0
>> and
>> > > > make
>> > > > >> the diff between then and get all changes between releases... I
>> > gonna
>> > > > >> publish it here soon. (If you think there is another important
>> > > release,
>> > > > >> let
>> > > > >> me know)
>> > > > >>
>> > > > >> Paul, are you dealing (i`m not sure about this word, sorry) with
>> > 4.3.0
>> > > > >> port
>> > > > >> for .Net on github (last email)?
>> > > > >>
>> > > > >> See you,
>> > > > >>
>> > > > >>
>> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
>> > > > >>
>> > > > >> > Thanks for the discussion points, Michael.
>> > > > >> >
>> > > > >> > I would vote for not worrying about trying to achieve portable
>> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
>> > > > >> completed.
>> > > > >> > Otherwise it may delay the project and stall it further. That's
>> > just
>> > > > my
>> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
>> > > > >> >
>> > > > >> > I have started porting the changes from the core library (from
>> the
>> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a separate
>> > > > branch.
>> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my port
>> > > until
>> > > > >> > there's changes to pull from upstream to work from. Also due
>> to my
>> > > > time
>> > > > >> > constraints, I am not fully documenting new methods that I'm
>> > adding.
>> > > > >> But if
>> > > > >> > anyone wants to pull/copy/reference my changes while porting,
>> > that's
>> > > > >> > awesome. My branch currently does not build as I'm primarily
>> going
>> > > > >> > class-by-class, starting with the util namespace. Once we get
>> the
>> > > ball
>> > > > >> > rolling on a community effort, I'll stop my rogue work and join
>> > in.
>> > > > But
>> > > > >> > hopefully my work will be useful to someone, if not as a pull
>> > > request
>> > > > >> then
>> > > > >> > as a reference. I'm also going to be holding a hackathon this
>> week
>> > > > with
>> > > > >> my
>> > > > >> > colleagues where we're all going to work on the port. I'm
>> > comparing
>> > > > >> files
>> > > > >> > and making changes as necessary, rather than starting from
>> > scratch.
>> > > My
>> > > > >> > repo/branch is here:
>> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>> > > > >> >
>> > > > >> > Paul
>> > > > >> >
>> > > > >> >
>> > > > >> >
>> > > > >> >
>> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>> > > > >> > mherndon@michaelherndon.com> wrote:
>> > > > >> >
>> > > > >> > > the guithub.com repo is a mirror to the git mirror that
>> apache
>> > > > >> > maintains.
>> > > > >> > >
>> > > > >> > > The was some work at one time to move the official svn
>> > repository
>> > > to
>> > > > >> > start
>> > > > >> > > using git one instead. Was that actually finalized or not?
>> > > > >> > >
>> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to
>> see
>> > > what
>> > > > >> kind
>> > > > >> > of
>> > > > >> > > work was involved using a portable libraries project. Some
>> of it
>> > > can
>> > > > >> > still
>> > > > >> > > be used but will need to be validated against the current
>> > version
>> > > of
>> > > > >> > Java's
>> > > > >> > > Lucene. It was also using .net 4.
>> > > > >> > >
>> > > > >> > > clean branch vs current. Its going to depend on what we
>> > > support.
>> > > > >> If
>> > > > >> > you
>> > > > >> > > support windows mobile 8, win RT, then the current code in
>> trunk
>> > > > will
>> > > > >> not
>> > > > >> > > compile against those versions of the framework which would a
>> > > > >> frustrating
>> > > > >> > > starting point, then you couldn't even run tests, which would
>> > make
>> > > > >> taking
>> > > > >> > > patches very difficult. Supporting those can almost mean
>> larger
>> > > > gaps
>> > > > >> in
>> > > > >> > > design between Lucene.Net and its parent project.
>> > > > >> > >
>> > > > >> > > Also the structure has changed significantly between the
>> > branches
>> > > > and
>> > > > >> > the
>> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6, and
>> > > seems
>> > > > >> > > significantly different. That doesn't mean you can't cherry
>> > pick
>> > > > >> stuff
>> > > > >> > > from the other tags/branches that would still work as is. A
>> > clean
>> > > > >> branch
>> > > > >> > > would also make it easier to get our build / tool chain in
>> order
>> > > as
>> > > > >> you
>> > > > >> > can
>> > > > >> > > then do them incrementally versus having to do all the stuff
>> > that
>> > > I
>> > > > >> did
>> > > > >> > for
>> > > > >> > > the 3x branch which saps energy and desire to code. It
>> could
>> > > also
>> > > > >> make
>> > > > >> > it
>> > > > >> > > easier to see which classes have been ported or not.
>> > > > >> > >
>> > > > >> > > The major downside to a clean branch is extra work it
>> requires
>> > and
>> > > > the
>> > > > >> > > start up cost in time and energy of getting it in order,
>> which
>> > can
>> > > > be
>> > > > >> > > daunting / intimidating and lower morale. And generally you
>> want
>> > > to
>> > > > >> use
>> > > > >> > > take your legacy code and refactor instead of in someways
>> > starting
>> > > > >> over.
>> > > > >> > >
>> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
>> > something
>> > > > >> similar
>> > > > >> > > to
>> > > > >> > >
>> > > > >> > >
>> > > > >> >
>> > > > >>
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>> > > > >> > > where it tracks what needs to get ported / what has been
>> ported.
>> > > > >> > >
>> > > > >> > > What are we going to support in the next version?
>> > > > >> > >
>> > > > >> > > Who is going to work on the next version?
>> > > > >> > >
>> > > > >> > > What would make the most sense and what would invigorate the
>> > > > >> community to
>> > > > >> > > get involved more and lower the barrier to entry?
>> > > > >> > >
>> > > > >> > > I think those are the questions that would make a lot of the
>> > > > decisions
>> > > > >> > for
>> > > > >> > > us so that we can get back to work on lucene.net.
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
>> > > > marcoslimagon@gmail.com
>> > > > >> > > >wrote:
>> > > > >> > >
>> > > > >> > > > Regarding the new branch, I'm a rookie with ASF projects...
>> > > > >> > > >
>> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>> > > > >> > > > https://github.com/apache/lucene.net points to the same
>> > > > repository?
>> > > > >> > > (This
>> > > > >> > > > is new for me, pretty good) Which of them do you recommend
>> > (i'm
>> > > > used
>> > > > >> > with
>> > > > >> > > > SVN and its patterns).
>> > > > >> > > >
>> > > > >> > > > I'm checking the subversion right now.
>> > > > >> > > >
>> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a old
>> > > > branch,
>> > > > >> i`m
>> > > > >> > > not
>> > > > >> > > > sure about its current status.
>> > > > >> > > >
>> > > > >> > > > Will we wipe the current solution from /trunk and start a
>> new
>> > > one?
>> > > > >> > > >
>> > > > >> > > > Thanks,
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
>> > > > >> > > >
>> > > > >> > > > > We may be forced to start with a clean/empty branch if
>> > people
>> > > > >> still
>> > > > >> > > want
>> > > > >> > > > to
>> > > > >> > > > > attempt supporting lucene.net for mobile devices, win
>> RT,
>> > > etc.
>> > > > >> The
>> > > > >> > are
>> > > > >> > > > > many
>> > > > >> > > > > classes that Lucene.net uses from the full framework that
>> > > would
>> > > > >> not
>> > > > >> > be
>> > > > >> > > > > accessible in other versions of the .NET Framework. It
>> also
>> > > > might
>> > > > >> > > > require
>> > > > >> > > > > a design that differs even more from its parent project.
>> > > > >> > > > >
>> > > > >> > > > > It might be wise to poll what users most desire in the
>> next
>> > > > >> version
>> > > > >> > > > through
>> > > > >> > > > > jira or user voice.
>> > > > >> > > > >
>> > > > >> > > > >
>> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>> > > > >> > itamar@code972.com
>> > > > >> > > > > >wrote:
>> > > > >> > > > >
>> > > > >> > > > > > inline
>> > > > >> > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>> > > > >> pirwin@feature23.com>
>> > > > >> > > > wrote:
>> > > > >> > > > > >
>> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been a
>> TFS
>> > > guy
>> > > > >> for
>> > > > >> > so
>> > > > >> > > > > long
>> > > > >> > > > > > > :-)
>> > > > >> > > > > > >
>> > > > >> > > > > > > So to recap, the branch_3x will be used for any
>> patches
>> > or
>> > > > >> > anything
>> > > > >> > > > to
>> > > > >> > > > > > the
>> > > > >> > > > > > > current 3.0.3 release, while trunk is what we will
>> > branch
>> > > > from
>> > > > >> > for
>> > > > >> > > 4x
>> > > > >> > > > > > dev.
>> > > > >> > > > > > > Correct?
>> > > > >> > > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
>> anyone
>> > > will
>> > > > >> be
>> > > > >> > > > > > interested in that
>> > > > >> > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal
>> with
>> > > the
>> > > > >> > github
>> > > > >> > > > > sync?
>> > > > >> > > > > > > Who could diagnose that?
>> > > > >> > > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the apache
>> > repo
>> > > > for
>> > > > >> now
>> > > > >> > > > while
>> > > > >> > > > > > we get that sorted out.
>> > > > >> > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
>> > > > >> > > > itamar@code972.com
>> > > > >> > > > > > > >wrote:
>> > > > >> > > > > > >
>> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it then
>> for
>> > > 3.x
>> > > > >> > > > > development.
>> > > > >> > > > > > > WRT
>> > > > >> > > > > > > > v4, yeah - just fork the repo and work on whatever
>> > > branch.
>> > > > >> When
>> > > > >> > > you
>> > > > >> > > > > > send
>> > > > >> > > > > > > us
>> > > > >> > > > > > > > PRs we will merge either to master or to a
>> dedicated
>> > > repo.
>> > > > >> For
>> > > > >> > > now
>> > > > >> > > > it
>> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > I pushed a new Version.cs file, you should see it
>> on
>> > the
>> > > > >> apache
>> > > > >> > > > > servers
>> > > > >> > > > > > > > (github sync seems to be off)
>> > > > >> > > > > > > >
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>> > > > >> > > pirwin@feature23.com>
>> > > > >> > > > > > > wrote:
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3
>> > > version
>> > > > >> of
>> > > > >> > the
>> > > > >> > > > > > > Analysis
>> > > > >> > > > > > > > > namespace.
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > Not sure the checkout command is what you
>> intended
>> > --
>> > > > you
>> > > > >> > might
>> > > > >> > > > > have
>> > > > >> > > > > > > > meant
>> > > > >> > > > > > > > > trunk instead of master, and that would create a
>> new
>> > > > "3x"
>> > > > >> > > branch,
>> > > > >> > > > > > when
>> > > > >> > > > > > > > > there's already a "branch_3x" and that would be
>> > > > >> misnamed...
>> > > > >> > so
>> > > > >> > > > > maybe
>> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there
>> aiming
>> > for
>> > > > >> lucene
>> > > > >> > > > 4.3.x
>> > > > >> > > > > > > > > compatibility?
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > Also, does someone with commit rights to the
>> > upstream
>> > > > >> want to
>> > > > >> > > > > create
>> > > > >> > > > > > > the
>> > > > >> > > > > > > > > necessary Version.cs entries, so that we're not
>> all
>> > > > >> trying to
>> > > > >> > > > > create
>> > > > >> > > > > > > them
>> > > > >> > > > > > > > > and dealing with a merge?
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > Paul
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
>> Syn-Hershko <
>> > > > >> > > > > > itamar@code972.com
>> > > > >> > > > > > > > > >wrote:
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > > Unless people here have a specific reason to
>> use
>> > > > 3.6.2 I
>> > > > >> > > would
>> > > > >> > > > > > highly
>> > > > >> > > > > > > > > > recommed putting all the efforts we can
>> towards v4
>> > > > >> > otherwise
>> > > > >> > > we
>> > > > >> > > > > > will
>> > > > >> > > > > > > > > never
>> > > > >> > > > > > > > > > make it...
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > Fork the repo from apache servers or github
>> (same
>> > > > repo,
>> > > > >> > > > different
>> > > > >> > > > > > > > > remotes)
>> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
>> should
>> > > work
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
>> > > > >> > > > > pirwin@feature23.com>
>> > > > >> > > > > > > > > wrote:
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > > Itamar,
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > I agree that from scratch is not the best
>> way to
>> > > do
>> > > > >> it, I
>> > > > >> > > > just
>> > > > >> > > > > > > > thought
>> > > > >> > > > > > > > > > that
>> > > > >> > > > > > > > > > > was the "decision" that was made from the
>> > > discussion
>> > > > >> > > > previously
>> > > > >> > > > > > for
>> > > > >> > > > > > > > the
>> > > > >> > > > > > > > > > 4.x
>> > > > >> > > > > > > > > > > work. An incremental approach will be much
>> > better.
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > I've created a branch of the branch_3x
>> branch on
>> > > my
>> > > > >> fork
>> > > > >> > > and
>> > > > >> > > > > will
>> > > > >> > > > > > > > begin
>> > > > >> > > > > > > > > > > working on bringing the Analysis namespace
>> up to
>> > > > >> speed to
>> > > > >> > > > > 3.6.2.
>> > > > >> > > > > > If
>> > > > >> > > > > > > > > > anyone
>> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once I'm
>> > > done,
>> > > > >> have
>> > > > >> > at
>> > > > >> > > > it.
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > If I shouldn't have branched off the
>> branch_3x
>> > > > branch,
>> > > > >> > > please
>> > > > >> > > > > let
>> > > > >> > > > > > > me
>> > > > >> > > > > > > > > know
>> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > Paul
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
>> > > Syn-Hershko <
>> > > > >> > > > > > > > itamar@code972.com
>> > > > >> > > > > > > > > > > >wrote:
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up again
>> :)
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > Paul, the problem is no one can really know
>> > what
>> > > > it
>> > > > >> > would
>> > > > >> > > > > take
>> > > > >> > > > > > > > until
>> > > > >> > > > > > > > > > they
>> > > > >> > > > > > > > > > > > have deep dived into the work, and even
>> then
>> > > > >> decisions
>> > > > >> > > > could
>> > > > >> > > > > > and
>> > > > >> > > > > > > > will
>> > > > >> > > > > > > > > > > > change. I will strongly advise against
>> > starting
>> > > > from
>> > > > >> > > > scratch,
>> > > > >> > > > > > > > > although
>> > > > >> > > > > > > > > > I
>> > > > >> > > > > > > > > > > do
>> > > > >> > > > > > > > > > > > think a lot in the current structure should
>> > > > change,
>> > > > >> but
>> > > > >> > > its
>> > > > >> > > > > > going
>> > > > >> > > > > > > > to
>> > > > >> > > > > > > > > be
>> > > > >> > > > > > > > > > > > much easier to change it in place,
>> refactoring
>> > > > where
>> > > > >> > > > needed,
>> > > > >> > > > > > than
>> > > > >> > > > > > > > > > > starting
>> > > > >> > > > > > > > > > > > all over again. Once we kicked this off I
>> > > > personally
>> > > > >> > will
>> > > > >> > > > be
>> > > > >> > > > > > > happy
>> > > > >> > > > > > > > > with
>> > > > >> > > > > > > > > > > you
>> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
>> porting
>> > > it,
>> > > > >> its
>> > > > >> > > > pretty
>> > > > >> > > > > > > much
>> > > > >> > > > > > > > > self
>> > > > >> > > > > > > > > > > > contained.
>> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a
>> fork
>> > > and
>> > > > >> send
>> > > > >> > > us
>> > > > >> > > > > PRs,
>> > > > >> > > > > > > its
>> > > > >> > > > > > > > > > much
>> > > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
>> fastest
>> > > way
>> > > > >> to do
>> > > > >> > > > this,
>> > > > >> > > > > > we
>> > > > >> > > > > > > > can
>> > > > >> > > > > > > > > > then
>> > > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing
>> using
>> > > > .NET
>> > > > >> > > > > constructs.
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > That said, I think the way to go is create
>> a
>> > > > branch
>> > > > >> out
>> > > > >> > > of
>> > > > >> > > > > the
>> > > > >> > > > > > > > > current
>> > > > >> > > > > > > > > > > git
>> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
>> > > working
>> > > > on
>> > > > >> > > master
>> > > > >> > > > > > > > towards a
>> > > > >> > > > > > > > > > 4.3
>> > > > >> > > > > > > > > > > > compatible version. The actual port should
>> be
>> > > > using
>> > > > >> a
>> > > > >> > > > process
>> > > > >> > > > > > > that
>> > > > >> > > > > > > > > > > ensures
>> > > > >> > > > > > > > > > > > all Java classes are ported with their
>> tests,
>> > > and
>> > > > >> that
>> > > > >> > > > those
>> > > > >> > > > > > > tests
>> > > > >> > > > > > > > > > pass -
>> > > > >> > > > > > > > > > > > but I'm against committing any Java code to
>> > our
>> > > > >> > > > repositories.
>> > > > >> > > > > > The
>> > > > >> > > > > > > > > > process
>> > > > >> > > > > > > > > > > > should probably be working on classes in
>> some
>> > > > order
>> > > > >> > > > > > > > (alphabetically,
>> > > > >> > > > > > > > > or
>> > > > >> > > > > > > > > > > > core classes first) and getting each class
>> to
>> > > > >> compile
>> > > > >> > > > before
>> > > > >> > > > > > > moving
>> > > > >> > > > > > > > > > > > forward. I don't mind about the project not
>> > > being
>> > > > >> > > > compilable
>> > > > >> > > > > > for
>> > > > >> > > > > > > a
>> > > > >> > > > > > > > > > month
>> > > > >> > > > > > > > > > > or
>> > > > >> > > > > > > > > > > > two.
>> > > > >> > > > > > > > > > > > Once this is done a process of .NETifying
>> and
>> > > > >> proofing
>> > > > >> > > the
>> > > > >> > > > > code
>> > > > >> > > > > > > can
>> > > > >> > > > > > > > > be
>> > > > >> > > > > > > > > > > > started, at which point we will already
>> have a
>> > > > >> working
>> > > > >> > v4
>> > > > >> > > > > > version
>> > > > >> > > > > > > > so
>> > > > >> > > > > > > > > it
>> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
>> > project.
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the test
>> > > suite
>> > > > so
>> > > > >> > > tests
>> > > > >> > > > > > could
>> > > > >> > > > > > > > more
>> > > > >> > > > > > > > > > or
>> > > > >> > > > > > > > > > > > less be copied and pasted (e.g.
>> implementing
>> > > > >> Java-like
>> > > > >> > > > > > > assertEquals
>> > > > >> > > > > > > > > > > methods
>> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to work
>> > with
>> > > > >> than
>> > > > >> > > > > NUnit). I
>> > > > >> > > > > > > > > already
>> > > > >> > > > > > > > > > > did
>> > > > >> > > > > > > > > > > > some work there but there's still a lot to
>> do.
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time myself
>> at
>> > > this
>> > > > >> > point,
>> > > > >> > > > > but I
>> > > > >> > > > > > > > > should
>> > > > >> > > > > > > > > > be
>> > > > >> > > > > > > > > > > > back in business in August, at which point
>> I
>> > can
>> > > > >> > dedicate
>> > > > >> > > > > > several
>> > > > >> > > > > > > > > > hours a
>> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
>> > closely
>> > > > and
>> > > > >> > even
>> > > > >> > > > > > > coordinate
>> > > > >> > > > > > > > > the
>> > > > >> > > > > > > > > > > > work to some extent.
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
>> Lima <
>> > > > >> > > > > > > > > marcoslimagon@gmail.com
>> > > > >> > > > > > > > > > > > >wrote:
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > It really sounds good to me, this is a
>> kick
>> > > > start
>> > > > >> > =). I
>> > > > >> > > > > > haven't
>> > > > >> > > > > > > > > > > > contributed
>> > > > >> > > > > > > > > > > > > anything
>> > > > >> > > > > > > > > > > > > yet, but I would like to help you all to
>> get
>> > > > this
>> > > > >> job
>> > > > >> > > > done.
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
>> Prescott.
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > I know that there is a high commitment
>> for
>> > > keep
>> > > > >> the
>> > > > >> > > > > > > > > > retrocompatibility
>> > > > >> > > > > > > > > > > on
>> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
>> > changes
>> > > > >> every
>> > > > >> > > > > release?
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
>> > version
>> > > > >> from a
>> > > > >> > > > > Lucene
>> > > > >> > > > > > > > > version,
>> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only minor
>> > > changes
>> > > > >> > every
>> > > > >> > > > > stable
>> > > > >> > > > > > > > > release
>> > > > >> > > > > > > > > > > (or
>> > > > >> > > > > > > > > > > > > keep most of its source-code), we could
>> > > compare
>> > > > >> the
>> > > > >> > > > > versions,
>> > > > >> > > > > > > > check
>> > > > >> > > > > > > > > > the
>> > > > >> > > > > > > > > > > > > differences and bring them to Lucene.Net.
>> > > > Again, I
>> > > > >> > > > haven't
>> > > > >> > > > > > > > > > contributed
>> > > > >> > > > > > > > > > > > with
>> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
>> > idea).
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > What's your approach for implement simple
>> > > > >> performance
>> > > > >> > > > > > > > improvements
>> > > > >> > > > > > > > > > > > (without
>> > > > >> > > > > > > > > > > > > adding references or changing methods
>> > > > signatures)?
>> > > > >> > Does
>> > > > >> > > > it
>> > > > >> > > > > > > could
>> > > > >> > > > > > > > be
>> > > > >> > > > > > > > > > > done,
>> > > > >> > > > > > > > > > > > > or "follow the java version only"?
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <
>> pirwin@feature23.com>
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > This is just an "outsider" suggestion
>> as I
>> > > > >> haven't
>> > > > >> > > > > > > contributed
>> > > > >> > > > > > > > > > > anything
>> > > > >> > > > > > > > > > > > > > yet, although I will definitely help
>> with
>> > > the
>> > > > >> 4.x
>> > > > >> > > work
>> > > > >> > > > > as I
>> > > > >> > > > > > > > have
>> > > > >> > > > > > > > > a
>> > > > >> > > > > > > > > > > > vested
>> > > > >> > > > > > > > > > > > > > interest in seeing that get completed.
>> I
>> > > think
>> > > > >> > there
>> > > > >> > > > > should
>> > > > >> > > > > > > be
>> > > > >> > > > > > > > > one
>> > > > >> > > > > > > > > > > > person
>> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
>> > structure
>> > > > and
>> > > > >> > > > workflow
>> > > > >> > > > > > will
>> > > > >> > > > > > > > > look
>> > > > >> > > > > > > > > > > like
>> > > > >> > > > > > > > > > > > > to
>> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going
>> to
>> > be
>> > > > >> > starting
>> > > > >> > > > from
>> > > > >> > > > > > > > scratch
>> > > > >> > > > > > > > > > as
>> > > > >> > > > > > > > > > > a
>> > > > >> > > > > > > > > > > > > > fresh port, that person should set up
>> the
>> > > > >> project,
>> > > > >> > > get
>> > > > >> > > > > > > > everything
>> > > > >> > > > > > > > > > > going
>> > > > >> > > > > > > > > > > > > in
>> > > > >> > > > > > > > > > > > > > source control, create the folder
>> > structure,
>> > > > >> maybe
>> > > > >> > > stub
>> > > > >> > > > > out
>> > > > >> > > > > > > > some
>> > > > >> > > > > > > > > > > > classes,
>> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with
>> anyone
>> > > > >> interested
>> > > > >> > > in
>> > > > >> > > > > > > > > > contributing,
>> > > > >> > > > > > > > > > > > > > perhaps by namespace.
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > I like the idea of throwing the java
>> code
>> > in
>> > > > >> there
>> > > > >> > so
>> > > > >> > > > > it's
>> > > > >> > > > > > > easy
>> > > > >> > > > > > > > > to
>> > > > >> > > > > > > > > > > > > > reference.
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > Again, I can work on
>> Lucene.Net.Documents,
>> > > > >> > > > > > > Lucene.Net.Analysis,
>> > > > >> > > > > > > > > or
>> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others,
>> those
>> > are
>> > > > >> just
>> > > > >> > the
>> > > > >> > > > > ones
>> > > > >> > > > > > > I'm
>> > > > >> > > > > > > > > most
>> > > > >> > > > > > > > > > > > > > familiar with the inner workings. Tell
>> me
>> > > what
>> > > > >> to
>> > > > >> > do
>> > > > >> > > > and
>> > > > >> > > > > > I'll
>> > > > >> > > > > > > > get
>> > > > >> > > > > > > > > > > > started
>> > > > >> > > > > > > > > > > > > > on my fork.
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > Paul Irwin
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM,
>> Prescott
>> > > > Nasser
>> > > > >> <
>> > > > >> > > > > > > > > > > geobmx540@hotmail.com
>> > > > >> > > > > > > > > > > > > > >wrote:
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > > > Hey guys -
>> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little while.
>> We
>> > > > have a
>> > > > >> > > board
>> > > > >> > > > > > report
>> > > > >> > > > > > > > due
>> > > > >> > > > > > > > > > > soon
>> > > > >> > > > > > > > > > > > -
>> > > > >> > > > > > > > > > > > > I
>> > > > >> > > > > > > > > > > > > > > think it prudent that we advise them
>> > that
>> > > we
>> > > > >> seem
>> > > > >> > > to
>> > > > >> > > > > have
>> > > > >> > > > > > > > > stalled
>> > > > >> > > > > > > > > > > > > > somewhat.
>> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items
>> out of
>> > > of
>> > > > >> jira
>> > > > >> > > and
>> > > > >> > > > > have
>> > > > >> > > > > > > > been
>> > > > >> > > > > > > > > > > > > responsive
>> > > > >> > > > > > > > > > > > > > > on the mailing list to community
>> > > questions,
>> > > > >> but I
>> > > > >> > > > don't
>> > > > >> > > > > > > think
>> > > > >> > > > > > > > > > we've
>> > > > >> > > > > > > > > > > > > done
>> > > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
>> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
>> > start
>> > > us
>> > > > >> back
>> > > > >> > > up
>> > > > >> > > > > > moving
>> > > > >> > > > > > > > > > > forward.
>> > > > >> > > > > > > > > > > > > What
>> > > > >> > > > > > > > > > > > > > > is the best way to accomplish this?
>> If
>> > we
>> > > > took
>> > > > >> > the
>> > > > >> > > > java
>> > > > >> > > > > > > > lucene
>> > > > >> > > > > > > > > > 4.0
>> > > > >> > > > > > > > > > > > code
>> > > > >> > > > > > > > > > > > > > and
>> > > > >> > > > > > > > > > > > > > > committed that java to our branch and
>> > then
>> > > > >> just
>> > > > >> > let
>> > > > >> > > > > > people
>> > > > >> > > > > > > > pull
>> > > > >> > > > > > > > > > > that
>> > > > >> > > > > > > > > > > > > down
>> > > > >> > > > > > > > > > > > > > > and being changing / modifying is
>> that
>> > one
>> > > > >> way to
>> > > > >> > > > maybe
>> > > > >> > > > > > > make
>> > > > >> > > > > > > > > some
>> > > > >> > > > > > > > > > > > > forward
>> > > > >> > > > > > > > > > > > > > > progress?
>> > > > >> > > > > > > > > > > > > > > ~P
>> > > > >> > > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > > > --
>> > > > >> > > > > > > > > > > > > --
>> > > > >> > > > > > > > > > > > > Marcos Lima
>> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
>> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
>> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>> > > > >> > > > > > > > > > > > >
>> > > > >> > > > > > > > > > > >
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > >
>> > > > >> > > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > > --
>> > > > >> > > > --
>> > > > >> > > > Marcos Lima
>> > > > >> > > > Software Developer/Tech Lead
>> > > > >> > > > marcoslimagon@gmail.com
>> > > > >> > > > tel: +55 (19) 9798-9335
>> > > > >> > > >
>> > > > >> > >
>> > > > >> >
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> --
>> > > > >> --
>> > > > >> Marcos Lima
>> > > > >> Software Developer/Tech Lead
>> > > > >> marcoslimagon@gmail.com
>> > > > >> tel: +55 (19) 9798-9335
>> > > > >>
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
I realized after I sent that email last night that I could do as you
described. When you've been debugging through CorruptedIndexExceptions, you
get a little bit of tunnel vision... haha
I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
the matching documents prints the fields to the console, so it's loading in
the stored fields data correctly.
I tried doing a TermQuery and now I get a "read past EOF" exception that I
can't figure out. There's a whole bunch of buffered byte array operations
going on and I can't determine where the issue came from. I'll keep
looking, but if someone could grab my fork/branch and help me look that
would be great. Here's example index writing and then reading code (also
included is a quick port of KeywordAnalyzer):
https://gist.github.com/anonymous/6174164
Thanks!
On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <it...@code972.com>wrote:
> Great
>
> You can build you Query objects on your own to execute a search, you don't
> actually have to use QueryParser for that
>
>
> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com> wrote:
>
> > Hey all, sorry it's been a little while, but I wanted to let you know
> that
> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
> > Lucene.net core building and able to write a simple index in Lucene 4.2
> > codec and read in things like the number of documents and whatnot. Since
> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
> > haven't ported that yet so I haven't done a real search, and I only built
> > the index using a quick port of KeywordAnalyzer which all those analyzers
> > have also moved to another module. But this is definitely good progress
> and
> > should be a launch point for finishing a 4.3/4.4 port.
> >
> > You can see my fork/branch here:
> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note: like I
> > said, only core builds now, no modules/tests build, so only open the
> > Lucene.Net.Core.sln)
> >
> > I'm sure it's riddled with bugs, but I hope this can help kickstart the
> > community into finishing the 4.3/4.4 port. Let me know if you have any
> > questions, thanks!
> >
> >
> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > Paul, that's awesome. I will need some more time to go over this thread
> > and
> > > your work to give actual feedback, SUPER busy at the moment
> > >
> > >
> > > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
> > wrote:
> > >
> > > > All,
> > > >
> > > > My colleagues and I have made good progress on porting Lucene 4.3's
> > core
> > > > library before, during, and after the hackathon last week. We now
> only
> > > have
> > > > some remaining items in Search, Index, and Codecs namespaces (plus a
> > few
> > > > other minor ones here and there). I expect to be done by the end of
> the
> > > > weekend. Analysis, Documents, Store, Util (except some FST and
> Packed),
> > > and
> > > > the root Codecs and Codecs.PerField namespaces are all now "done".
> > > >
> > > > Again, my goal is to only get a buildable, experimental build of
> > > Lucene.net
> > > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not
> porting
> > > new
> > > > javadoc comments or unit tests right now, due to the vast amount of
> > code
> > > > that needs to be written just to get it to compile. If this work ends
> > up
> > > > becoming a pull request, great, otherwise it should help accelerate a
> > > port
> > > > of 4.3.x since the bulk of the work on core will already be done and
> > > > contributors can use it as a reference. And again, we're taking the
> > > > pragmatic approach of porting class-by-class, namespace-by-namespace,
> > > with
> > > > the understanding that until we're done the project won't build.
> > > >
> > > > Once complete, I also will work on updating the Analyzers contrib
> > module
> > > > and porting the QueryParsers contrib module, which I feel should be
> > > > included in the core NuGet package for Lucene.net as the core library
> > is
> > > > now (post-4.0) practically useless (or atleast not turn-key) without
> > > them.
> > > > You can check out the code on my fork/branch here:
> > > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> > > >
> > > > In particular, I'd like some feedback on my work on ByteBuffer,
> > > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For
> the
> > > MMap
> > > > support, I created a ByteBuffer subclass that uses .NET 4's
> > > > MemoryMappedFile support which should emulate the Java nio stuff
> pretty
> > > > well, but required some creative shuffling of the code to make it
> work
> > > due
> > > > to lifecycle management.
> > > >
> > > > I'll update again this weekend or next week, when we should have
> > wrapped
> > > up
> > > > most of the main hacking on porting the core code.
> > > >
> > > > Paul
> > > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com>
> > > wrote:
> > > >
> > > > > Marcos,
> > > > >
> > > > > That would be helpful. As far as I can tell, the 3.0 java code is
> > only
> > > on
> > > > > SVN here, before the lucene and solr projects were bundled
> together:
> > > > > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> > > > >
> > > > > The SVN for 4.3 java is here:
> > > > >
> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> > > > > And the GitHub for 4.3 java is here:
> > > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> > > > >
> > > > > My fork/branch of Lucene.net for the 4.3 port is here:
> > > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> > > > >
> > > > > My fork is the "upstream" fork for my team members, and i'm remote
> > > > merging
> > > > > their changes in from their forks while they fetch/merge from mine
> to
> > > get
> > > > > everyone else's changes, rather than using pull requests. James
> and I
> > > > have
> > > > > been working the past few days on the Util namespace ahead of
> > tonight's
> > > > > hackathon since that namespace is in common with the rest of the
> > > > > namespaces. Tonight, we'll have at least 8 guys that I know of
> > hacking
> > > on
> > > > > porting 4.3, each with a different namespace or part of a
> namespace.
> > > > Since
> > > > > we're going class-by-class, namespace-by-namespace, the project
> does
> > > not
> > > > > build as it is. Once we finish doing a translation of each file,
> then
> > > > we'll
> > > > > hammer out any remaining issues and get it to build again. I'm
> hoping
> > > > that
> > > > > we can get at least 75% done with Core tonight. Wish us luck!
> > > > >
> > > > > But one thing to keep in mind is it looks like much functionality
> has
> > > > been
> > > > > moved out of core into the contrib modules, especially around
> > analysis,
> > > > for
> > > > > 4.0+. For example, there are no built-in analyzers in core anymore.
> > So
> > > > when
> > > > > this is all done, we may want to include at least the analysis
> > contrib
> > > > > module in with the standard core NuGet package, because otherwise
> > it's
> > > > > practically useless unless you roll your own analyzer.
> > > > >
> > > > > Paul
> > > > >
> > > > >
> > > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
> > marcoslimagon@gmail.com
> > > > >wrote:
> > > > >
> > > > >> Hi everyone!
> > > > >>
> > > > >> Does someone know where can I find the 3.0.3 release from
> > > Lucene(java)?
> > > > >>
> > > > >> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0
> and
> > > > make
> > > > >> the diff between then and get all changes between releases... I
> > gonna
> > > > >> publish it here soon. (If you think there is another important
> > > release,
> > > > >> let
> > > > >> me know)
> > > > >>
> > > > >> Paul, are you dealing (i`m not sure about this word, sorry) with
> > 4.3.0
> > > > >> port
> > > > >> for .Net on github (last email)?
> > > > >>
> > > > >> See you,
> > > > >>
> > > > >>
> > > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> > > > >>
> > > > >> > Thanks for the discussion points, Michael.
> > > > >> >
> > > > >> > I would vote for not worrying about trying to achieve portable
> > > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
> > > > >> completed.
> > > > >> > Otherwise it may delay the project and stall it further. That's
> > just
> > > > my
> > > > >> > $0.02 based on my admittedly selfish need for 4.x features.
> > > > >> >
> > > > >> > I have started porting the changes from the core library (from
> the
> > > > >> > java lucene_solr_4_3 branch) in my fork on github in a separate
> > > > branch.
> > > > >> > Since I need 4.3 ASAP, I am just going to keep going on my port
> > > until
> > > > >> > there's changes to pull from upstream to work from. Also due to
> my
> > > > time
> > > > >> > constraints, I am not fully documenting new methods that I'm
> > adding.
> > > > >> But if
> > > > >> > anyone wants to pull/copy/reference my changes while porting,
> > that's
> > > > >> > awesome. My branch currently does not build as I'm primarily
> going
> > > > >> > class-by-class, starting with the util namespace. Once we get
> the
> > > ball
> > > > >> > rolling on a community effort, I'll stop my rogue work and join
> > in.
> > > > But
> > > > >> > hopefully my work will be useful to someone, if not as a pull
> > > request
> > > > >> then
> > > > >> > as a reference. I'm also going to be holding a hackathon this
> week
> > > > with
> > > > >> my
> > > > >> > colleagues where we're all going to work on the port. I'm
> > comparing
> > > > >> files
> > > > >> > and making changes as necessary, rather than starting from
> > scratch.
> > > My
> > > > >> > repo/branch is here:
> > > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> > > > >> >
> > > > >> > Paul
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> > > > >> > mherndon@michaelherndon.com> wrote:
> > > > >> >
> > > > >> > > the guithub.com repo is a mirror to the git mirror that
> apache
> > > > >> > maintains.
> > > > >> > >
> > > > >> > > The was some work at one time to move the official svn
> > repository
> > > to
> > > > >> > start
> > > > >> > > using git one instead. Was that actually finalized or not?
> > > > >> > >
> > > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to see
> > > what
> > > > >> kind
> > > > >> > of
> > > > >> > > work was involved using a portable libraries project. Some of
> it
> > > can
> > > > >> > still
> > > > >> > > be used but will need to be validated against the current
> > version
> > > of
> > > > >> > Java's
> > > > >> > > Lucene. It was also using .net 4.
> > > > >> > >
> > > > >> > > clean branch vs current. Its going to depend on what we
> > > support.
> > > > >> If
> > > > >> > you
> > > > >> > > support windows mobile 8, win RT, then the current code in
> trunk
> > > > will
> > > > >> not
> > > > >> > > compile against those versions of the framework which would a
> > > > >> frustrating
> > > > >> > > starting point, then you couldn't even run tests, which would
> > make
> > > > >> taking
> > > > >> > > patches very difficult. Supporting those can almost mean
> larger
> > > > gaps
> > > > >> in
> > > > >> > > design between Lucene.Net and its parent project.
> > > > >> > >
> > > > >> > > Also the structure has changed significantly between the
> > branches
> > > > and
> > > > >> > the
> > > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6, and
> > > seems
> > > > >> > > significantly different. That doesn't mean you can't cherry
> > pick
> > > > >> stuff
> > > > >> > > from the other tags/branches that would still work as is. A
> > clean
> > > > >> branch
> > > > >> > > would also make it easier to get our build / tool chain in
> order
> > > as
> > > > >> you
> > > > >> > can
> > > > >> > > then do them incrementally versus having to do all the stuff
> > that
> > > I
> > > > >> did
> > > > >> > for
> > > > >> > > the 3x branch which saps energy and desire to code. It could
> > > also
> > > > >> make
> > > > >> > it
> > > > >> > > easier to see which classes have been ported or not.
> > > > >> > >
> > > > >> > > The major downside to a clean branch is extra work it requires
> > and
> > > > the
> > > > >> > > start up cost in time and energy of getting it in order, which
> > can
> > > > be
> > > > >> > > daunting / intimidating and lower morale. And generally you
> want
> > > to
> > > > >> use
> > > > >> > > take your legacy code and refactor instead of in someways
> > starting
> > > > >> over.
> > > > >> > >
> > > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
> > something
> > > > >> similar
> > > > >> > > to
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> > > > >> > > where it tracks what needs to get ported / what has been
> ported.
> > > > >> > >
> > > > >> > > What are we going to support in the next version?
> > > > >> > >
> > > > >> > > Who is going to work on the next version?
> > > > >> > >
> > > > >> > > What would make the most sense and what would invigorate the
> > > > >> community to
> > > > >> > > get involved more and lower the barrier to entry?
> > > > >> > >
> > > > >> > > I think those are the questions that would make a lot of the
> > > > decisions
> > > > >> > for
> > > > >> > > us so that we can get back to work on lucene.net.
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> > > > marcoslimagon@gmail.com
> > > > >> > > >wrote:
> > > > >> > >
> > > > >> > > > Regarding the new branch, I'm a rookie with ASF projects...
> > > > >> > > >
> > > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> > > > >> > > > https://github.com/apache/lucene.net points to the same
> > > > repository?
> > > > >> > > (This
> > > > >> > > > is new for me, pretty good) Which of them do you recommend
> > (i'm
> > > > used
> > > > >> > with
> > > > >> > > > SVN and its patterns).
> > > > >> > > >
> > > > >> > > > I'm checking the subversion right now.
> > > > >> > > >
> > > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a old
> > > > branch,
> > > > >> i`m
> > > > >> > > not
> > > > >> > > > sure about its current status.
> > > > >> > > >
> > > > >> > > > Will we wipe the current solution from /trunk and start a
> new
> > > one?
> > > > >> > > >
> > > > >> > > > Thanks,
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
> > > > >> > > >
> > > > >> > > > > We may be forced to start with a clean/empty branch if
> > people
> > > > >> still
> > > > >> > > want
> > > > >> > > > to
> > > > >> > > > > attempt supporting lucene.net for mobile devices, win RT,
> > > etc.
> > > > >> The
> > > > >> > are
> > > > >> > > > > many
> > > > >> > > > > classes that Lucene.net uses from the full framework that
> > > would
> > > > >> not
> > > > >> > be
> > > > >> > > > > accessible in other versions of the .NET Framework. It
> also
> > > > might
> > > > >> > > > require
> > > > >> > > > > a design that differs even more from its parent project.
> > > > >> > > > >
> > > > >> > > > > It might be wise to poll what users most desire in the
> next
> > > > >> version
> > > > >> > > > through
> > > > >> > > > > jira or user voice.
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> > > > >> > itamar@code972.com
> > > > >> > > > > >wrote:
> > > > >> > > > >
> > > > >> > > > > > inline
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> > > > >> pirwin@feature23.com>
> > > > >> > > > wrote:
> > > > >> > > > > >
> > > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been a
> TFS
> > > guy
> > > > >> for
> > > > >> > so
> > > > >> > > > > long
> > > > >> > > > > > > :-)
> > > > >> > > > > > >
> > > > >> > > > > > > So to recap, the branch_3x will be used for any
> patches
> > or
> > > > >> > anything
> > > > >> > > > to
> > > > >> > > > > > the
> > > > >> > > > > > > current 3.0.3 release, while trunk is what we will
> > branch
> > > > from
> > > > >> > for
> > > > >> > > 4x
> > > > >> > > > > > dev.
> > > > >> > > > > > > Correct?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Yes - we can branch from it for 3.6 development if
> anyone
> > > will
> > > > >> be
> > > > >> > > > > > interested in that
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal
> with
> > > the
> > > > >> > github
> > > > >> > > > > sync?
> > > > >> > > > > > > Who could diagnose that?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Not sure, Apache Infra, basically. Just use the apache
> > repo
> > > > for
> > > > >> now
> > > > >> > > > while
> > > > >> > > > > > we get that sorted out.
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> > > > >> > > > itamar@code972.com
> > > > >> > > > > > > >wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > > Ok, haven't noticed that branch. Just use it then
> for
> > > 3.x
> > > > >> > > > > development.
> > > > >> > > > > > > WRT
> > > > >> > > > > > > > v4, yeah - just fork the repo and work on whatever
> > > branch.
> > > > >> When
> > > > >> > > you
> > > > >> > > > > > send
> > > > >> > > > > > > us
> > > > >> > > > > > > > PRs we will merge either to master or to a dedicated
> > > repo.
> > > > >> For
> > > > >> > > now
> > > > >> > > > it
> > > > >> > > > > > > > doesn't really matter, thats the beauty of git.
> > > > >> > > > > > > >
> > > > >> > > > > > > > I pushed a new Version.cs file, you should see it on
> > the
> > > > >> apache
> > > > >> > > > > servers
> > > > >> > > > > > > > (github sync seems to be off)
> > > > >> > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> > > > >> > > pirwin@feature23.com>
> > > > >> > > > > > > wrote:
> > > > >> > > > > > > >
> > > > >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3
> > > version
> > > > >> of
> > > > >> > the
> > > > >> > > > > > > Analysis
> > > > >> > > > > > > > > namespace.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Not sure the checkout command is what you intended
> > --
> > > > you
> > > > >> > might
> > > > >> > > > > have
> > > > >> > > > > > > > meant
> > > > >> > > > > > > > > trunk instead of master, and that would create a
> new
> > > > "3x"
> > > > >> > > branch,
> > > > >> > > > > > when
> > > > >> > > > > > > > > there's already a "branch_3x" and that would be
> > > > >> misnamed...
> > > > >> > so
> > > > >> > > > > maybe
> > > > >> > > > > > > > > checkout -b branch_4x trunk and start there aiming
> > for
> > > > >> lucene
> > > > >> > > > 4.3.x
> > > > >> > > > > > > > > compatibility?
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Also, does someone with commit rights to the
> > upstream
> > > > >> want to
> > > > >> > > > > create
> > > > >> > > > > > > the
> > > > >> > > > > > > > > necessary Version.cs entries, so that we're not
> all
> > > > >> trying to
> > > > >> > > > > create
> > > > >> > > > > > > them
> > > > >> > > > > > > > > and dealing with a merge?
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Paul
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar
> Syn-Hershko <
> > > > >> > > > > > itamar@code972.com
> > > > >> > > > > > > > > >wrote:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > > Unless people here have a specific reason to use
> > > > 3.6.2 I
> > > > >> > > would
> > > > >> > > > > > highly
> > > > >> > > > > > > > > > recommed putting all the efforts we can towards
> v4
> > > > >> > otherwise
> > > > >> > > we
> > > > >> > > > > > will
> > > > >> > > > > > > > > never
> > > > >> > > > > > > > > > make it...
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > Fork the repo from apache servers or github
> (same
> > > > repo,
> > > > >> > > > different
> > > > >> > > > > > > > > remotes)
> > > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that
> should
> > > work
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> > > > >> > > > > pirwin@feature23.com>
> > > > >> > > > > > > > > wrote:
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > > Itamar,
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > I agree that from scratch is not the best way
> to
> > > do
> > > > >> it, I
> > > > >> > > > just
> > > > >> > > > > > > > thought
> > > > >> > > > > > > > > > that
> > > > >> > > > > > > > > > > was the "decision" that was made from the
> > > discussion
> > > > >> > > > previously
> > > > >> > > > > > for
> > > > >> > > > > > > > the
> > > > >> > > > > > > > > > 4.x
> > > > >> > > > > > > > > > > work. An incremental approach will be much
> > better.
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > I've created a branch of the branch_3x branch
> on
> > > my
> > > > >> fork
> > > > >> > > and
> > > > >> > > > > will
> > > > >> > > > > > > > begin
> > > > >> > > > > > > > > > > working on bringing the Analysis namespace up
> to
> > > > >> speed to
> > > > >> > > > > 3.6.2.
> > > > >> > > > > > If
> > > > >> > > > > > > > > > anyone
> > > > >> > > > > > > > > > > wants to pull it or just reuse parts once I'm
> > > done,
> > > > >> have
> > > > >> > at
> > > > >> > > > it.
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > If I shouldn't have branched off the branch_3x
> > > > branch,
> > > > >> > > please
> > > > >> > > > > let
> > > > >> > > > > > > me
> > > > >> > > > > > > > > know
> > > > >> > > > > > > > > > > what I should have branched from (trunk?)
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > Paul
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
> > > Syn-Hershko <
> > > > >> > > > > > > > itamar@code972.com
> > > > >> > > > > > > > > > > >wrote:
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > > Thanks Prescott for bringing this up again
> :)
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > Paul, the problem is no one can really know
> > what
> > > > it
> > > > >> > would
> > > > >> > > > > take
> > > > >> > > > > > > > until
> > > > >> > > > > > > > > > they
> > > > >> > > > > > > > > > > > have deep dived into the work, and even then
> > > > >> decisions
> > > > >> > > > could
> > > > >> > > > > > and
> > > > >> > > > > > > > will
> > > > >> > > > > > > > > > > > change. I will strongly advise against
> > starting
> > > > from
> > > > >> > > > scratch,
> > > > >> > > > > > > > > although
> > > > >> > > > > > > > > > I
> > > > >> > > > > > > > > > > do
> > > > >> > > > > > > > > > > > think a lot in the current structure should
> > > > change,
> > > > >> but
> > > > >> > > its
> > > > >> > > > > > going
> > > > >> > > > > > > > to
> > > > >> > > > > > > > > be
> > > > >> > > > > > > > > > > > much easier to change it in place,
> refactoring
> > > > where
> > > > >> > > > needed,
> > > > >> > > > > > than
> > > > >> > > > > > > > > > > starting
> > > > >> > > > > > > > > > > > all over again. Once we kicked this off I
> > > > personally
> > > > >> > will
> > > > >> > > > be
> > > > >> > > > > > > happy
> > > > >> > > > > > > > > with
> > > > >> > > > > > > > > > > you
> > > > >> > > > > > > > > > > > taking the analysis part of Lucene and
> porting
> > > it,
> > > > >> its
> > > > >> > > > pretty
> > > > >> > > > > > > much
> > > > >> > > > > > > > > self
> > > > >> > > > > > > > > > > > contained.
> > > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a
> fork
> > > and
> > > > >> send
> > > > >> > > us
> > > > >> > > > > PRs,
> > > > >> > > > > > > its
> > > > >> > > > > > > > > > much
> > > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > Marcos, porting class by class is the
> fastest
> > > way
> > > > >> to do
> > > > >> > > > this,
> > > > >> > > > > > we
> > > > >> > > > > > > > can
> > > > >> > > > > > > > > > then
> > > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing
> using
> > > > .NET
> > > > >> > > > > constructs.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > That said, I think the way to go is create a
> > > > branch
> > > > >> out
> > > > >> > > of
> > > > >> > > > > the
> > > > >> > > > > > > > > current
> > > > >> > > > > > > > > > > git
> > > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
> > > working
> > > > on
> > > > >> > > master
> > > > >> > > > > > > > towards a
> > > > >> > > > > > > > > > 4.3
> > > > >> > > > > > > > > > > > compatible version. The actual port should
> be
> > > > using
> > > > >> a
> > > > >> > > > process
> > > > >> > > > > > > that
> > > > >> > > > > > > > > > > ensures
> > > > >> > > > > > > > > > > > all Java classes are ported with their
> tests,
> > > and
> > > > >> that
> > > > >> > > > those
> > > > >> > > > > > > tests
> > > > >> > > > > > > > > > pass -
> > > > >> > > > > > > > > > > > but I'm against committing any Java code to
> > our
> > > > >> > > > repositories.
> > > > >> > > > > > The
> > > > >> > > > > > > > > > process
> > > > >> > > > > > > > > > > > should probably be working on classes in
> some
> > > > order
> > > > >> > > > > > > > (alphabetically,
> > > > >> > > > > > > > > or
> > > > >> > > > > > > > > > > > core classes first) and getting each class
> to
> > > > >> compile
> > > > >> > > > before
> > > > >> > > > > > > moving
> > > > >> > > > > > > > > > > > forward. I don't mind about the project not
> > > being
> > > > >> > > > compilable
> > > > >> > > > > > for
> > > > >> > > > > > > a
> > > > >> > > > > > > > > > month
> > > > >> > > > > > > > > > > or
> > > > >> > > > > > > > > > > > two.
> > > > >> > > > > > > > > > > > Once this is done a process of .NETifying
> and
> > > > >> proofing
> > > > >> > > the
> > > > >> > > > > code
> > > > >> > > > > > > can
> > > > >> > > > > > > > > be
> > > > >> > > > > > > > > > > > started, at which point we will already
> have a
> > > > >> working
> > > > >> > v4
> > > > >> > > > > > version
> > > > >> > > > > > > > so
> > > > >> > > > > > > > > it
> > > > >> > > > > > > > > > > > will be easier to keep up with the Java
> > project.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > The first step IMO is to stabilize the test
> > > suite
> > > > so
> > > > >> > > tests
> > > > >> > > > > > could
> > > > >> > > > > > > > more
> > > > >> > > > > > > > > > or
> > > > >> > > > > > > > > > > > less be copied and pasted (e.g. implementing
> > > > >> Java-like
> > > > >> > > > > > > assertEquals
> > > > >> > > > > > > > > > > methods
> > > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to work
> > with
> > > > >> than
> > > > >> > > > > NUnit). I
> > > > >> > > > > > > > > already
> > > > >> > > > > > > > > > > did
> > > > >> > > > > > > > > > > > some work there but there's still a lot to
> do.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > Unfortunately I can't dedicate time myself
> at
> > > this
> > > > >> > point,
> > > > >> > > > > but I
> > > > >> > > > > > > > > should
> > > > >> > > > > > > > > > be
> > > > >> > > > > > > > > > > > back in business in August, at which point I
> > can
> > > > >> > dedicate
> > > > >> > > > > > several
> > > > >> > > > > > > > > > hours a
> > > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
> > closely
> > > > and
> > > > >> > even
> > > > >> > > > > > > coordinate
> > > > >> > > > > > > > > the
> > > > >> > > > > > > > > > > > work to some extent.
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos
> Lima <
> > > > >> > > > > > > > > marcoslimagon@gmail.com
> > > > >> > > > > > > > > > > > >wrote:
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > It really sounds good to me, this is a
> kick
> > > > start
> > > > >> > =). I
> > > > >> > > > > > haven't
> > > > >> > > > > > > > > > > > contributed
> > > > >> > > > > > > > > > > > > anything
> > > > >> > > > > > > > > > > > > yet, but I would like to help you all to
> get
> > > > this
> > > > >> job
> > > > >> > > > done.
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > I'm completely agree with Paul and
> Prescott.
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > I know that there is a high commitment for
> > > keep
> > > > >> the
> > > > >> > > > > > > > > > retrocompatibility
> > > > >> > > > > > > > > > > on
> > > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
> > changes
> > > > >> every
> > > > >> > > > > release?
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
> > version
> > > > >> from a
> > > > >> > > > > Lucene
> > > > >> > > > > > > > > version,
> > > > >> > > > > > > > > > > > > right? If the Lucene API gets only minor
> > > changes
> > > > >> > every
> > > > >> > > > > stable
> > > > >> > > > > > > > > release
> > > > >> > > > > > > > > > > (or
> > > > >> > > > > > > > > > > > > keep most of its source-code), we could
> > > compare
> > > > >> the
> > > > >> > > > > versions,
> > > > >> > > > > > > > check
> > > > >> > > > > > > > > > the
> > > > >> > > > > > > > > > > > > differences and bring them to Lucene.Net.
> > > > Again, I
> > > > >> > > > haven't
> > > > >> > > > > > > > > > contributed
> > > > >> > > > > > > > > > > > with
> > > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
> > idea).
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > What's your approach for implement simple
> > > > >> performance
> > > > >> > > > > > > > improvements
> > > > >> > > > > > > > > > > > (without
> > > > >> > > > > > > > > > > > > adding references or changing methods
> > > > signatures)?
> > > > >> > Does
> > > > >> > > > it
> > > > >> > > > > > > could
> > > > >> > > > > > > > be
> > > > >> > > > > > > > > > > done,
> > > > >> > > > > > > > > > > > > or "follow the java version only"?
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <pirwin@feature23.com
> >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > This is just an "outsider" suggestion
> as I
> > > > >> haven't
> > > > >> > > > > > > contributed
> > > > >> > > > > > > > > > > anything
> > > > >> > > > > > > > > > > > > > yet, although I will definitely help
> with
> > > the
> > > > >> 4.x
> > > > >> > > work
> > > > >> > > > > as I
> > > > >> > > > > > > > have
> > > > >> > > > > > > > > a
> > > > >> > > > > > > > > > > > vested
> > > > >> > > > > > > > > > > > > > interest in seeing that get completed. I
> > > think
> > > > >> > there
> > > > >> > > > > should
> > > > >> > > > > > > be
> > > > >> > > > > > > > > one
> > > > >> > > > > > > > > > > > person
> > > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
> > structure
> > > > and
> > > > >> > > > workflow
> > > > >> > > > > > will
> > > > >> > > > > > > > > look
> > > > >> > > > > > > > > > > like
> > > > >> > > > > > > > > > > > > to
> > > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going to
> > be
> > > > >> > starting
> > > > >> > > > from
> > > > >> > > > > > > > scratch
> > > > >> > > > > > > > > > as
> > > > >> > > > > > > > > > > a
> > > > >> > > > > > > > > > > > > > fresh port, that person should set up
> the
> > > > >> project,
> > > > >> > > get
> > > > >> > > > > > > > everything
> > > > >> > > > > > > > > > > going
> > > > >> > > > > > > > > > > > > in
> > > > >> > > > > > > > > > > > > > source control, create the folder
> > structure,
> > > > >> maybe
> > > > >> > > stub
> > > > >> > > > > out
> > > > >> > > > > > > > some
> > > > >> > > > > > > > > > > > classes,
> > > > >> > > > > > > > > > > > > > etc. Then divide and conquer with anyone
> > > > >> interested
> > > > >> > > in
> > > > >> > > > > > > > > > contributing,
> > > > >> > > > > > > > > > > > > > perhaps by namespace.
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > I like the idea of throwing the java
> code
> > in
> > > > >> there
> > > > >> > so
> > > > >> > > > > it's
> > > > >> > > > > > > easy
> > > > >> > > > > > > > > to
> > > > >> > > > > > > > > > > > > > reference.
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > Again, I can work on
> Lucene.Net.Documents,
> > > > >> > > > > > > Lucene.Net.Analysis,
> > > > >> > > > > > > > > or
> > > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others, those
> > are
> > > > >> just
> > > > >> > the
> > > > >> > > > > ones
> > > > >> > > > > > > I'm
> > > > >> > > > > > > > > most
> > > > >> > > > > > > > > > > > > > familiar with the inner workings. Tell
> me
> > > what
> > > > >> to
> > > > >> > do
> > > > >> > > > and
> > > > >> > > > > > I'll
> > > > >> > > > > > > > get
> > > > >> > > > > > > > > > > > started
> > > > >> > > > > > > > > > > > > > on my fork.
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > Paul Irwin
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott
> > > > Nasser
> > > > >> <
> > > > >> > > > > > > > > > > geobmx540@hotmail.com
> > > > >> > > > > > > > > > > > > > >wrote:
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > > > Hey guys -
> > > > >> > > > > > > > > > > > > > > I know I've been MIA a little while.
> We
> > > > have a
> > > > >> > > board
> > > > >> > > > > > report
> > > > >> > > > > > > > due
> > > > >> > > > > > > > > > > soon
> > > > >> > > > > > > > > > > > -
> > > > >> > > > > > > > > > > > > I
> > > > >> > > > > > > > > > > > > > > think it prudent that we advise them
> > that
> > > we
> > > > >> seem
> > > > >> > > to
> > > > >> > > > > have
> > > > >> > > > > > > > > stalled
> > > > >> > > > > > > > > > > > > > somewhat.
> > > > >> > > > > > > > > > > > > > > We've got a few low hanging items out
> of
> > > of
> > > > >> jira
> > > > >> > > and
> > > > >> > > > > have
> > > > >> > > > > > > > been
> > > > >> > > > > > > > > > > > > responsive
> > > > >> > > > > > > > > > > > > > > on the mailing list to community
> > > questions,
> > > > >> but I
> > > > >> > > > don't
> > > > >> > > > > > > think
> > > > >> > > > > > > > > > we've
> > > > >> > > > > > > > > > > > > done
> > > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
> > > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
> > start
> > > us
> > > > >> back
> > > > >> > > up
> > > > >> > > > > > moving
> > > > >> > > > > > > > > > > forward.
> > > > >> > > > > > > > > > > > > What
> > > > >> > > > > > > > > > > > > > > is the best way to accomplish this? If
> > we
> > > > took
> > > > >> > the
> > > > >> > > > java
> > > > >> > > > > > > > lucene
> > > > >> > > > > > > > > > 4.0
> > > > >> > > > > > > > > > > > code
> > > > >> > > > > > > > > > > > > > and
> > > > >> > > > > > > > > > > > > > > committed that java to our branch and
> > then
> > > > >> just
> > > > >> > let
> > > > >> > > > > > people
> > > > >> > > > > > > > pull
> > > > >> > > > > > > > > > > that
> > > > >> > > > > > > > > > > > > down
> > > > >> > > > > > > > > > > > > > > and being changing / modifying is that
> > one
> > > > >> way to
> > > > >> > > > maybe
> > > > >> > > > > > > make
> > > > >> > > > > > > > > some
> > > > >> > > > > > > > > > > > > forward
> > > > >> > > > > > > > > > > > > > > progress?
> > > > >> > > > > > > > > > > > > > > ~P
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > --
> > > > >> > > > > > > > > > > > > --
> > > > >> > > > > > > > > > > > > Marcos Lima
> > > > >> > > > > > > > > > > > > Software Developer/Tech Lead
> > > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
> > > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > --
> > > > >> > > > --
> > > > >> > > > Marcos Lima
> > > > >> > > > Software Developer/Tech Lead
> > > > >> > > > marcoslimagon@gmail.com
> > > > >> > > > tel: +55 (19) 9798-9335
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> --
> > > > >> Marcos Lima
> > > > >> Software Developer/Tech Lead
> > > > >> marcoslimagon@gmail.com
> > > > >> tel: +55 (19) 9798-9335
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Lucene 4.0
Posted by Itamar Syn-Hershko <it...@code972.com>.
Great
You can build you Query objects on your own to execute a search, you don't
actually have to use QueryParser for that
On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pi...@feature23.com> wrote:
> Hey all, sorry it's been a little while, but I wanted to let you know that
> although I took a few weeks off from it, I now have a 4.3.1 equivalent
> Lucene.net core building and able to write a simple index in Lucene 4.2
> codec and read in things like the number of documents and whatnot. Since
> QueryParser has been moved to a separate module in Lucene Java 4.x, I
> haven't ported that yet so I haven't done a real search, and I only built
> the index using a quick port of KeywordAnalyzer which all those analyzers
> have also moved to another module. But this is definitely good progress and
> should be a launch point for finishing a 4.3/4.4 port.
>
> You can see my fork/branch here:
> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note: like I
> said, only core builds now, no modules/tests build, so only open the
> Lucene.Net.Core.sln)
>
> I'm sure it's riddled with bugs, but I hope this can help kickstart the
> community into finishing the 4.3/4.4 port. Let me know if you have any
> questions, thanks!
>
>
> On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > Paul, that's awesome. I will need some more time to go over this thread
> and
> > your work to give actual feedback, SUPER busy at the moment
> >
> >
> > On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com>
> wrote:
> >
> > > All,
> > >
> > > My colleagues and I have made good progress on porting Lucene 4.3's
> core
> > > library before, during, and after the hackathon last week. We now only
> > have
> > > some remaining items in Search, Index, and Codecs namespaces (plus a
> few
> > > other minor ones here and there). I expect to be done by the end of the
> > > weekend. Analysis, Documents, Store, Util (except some FST and Packed),
> > and
> > > the root Codecs and Codecs.PerField namespaces are all now "done".
> > >
> > > Again, my goal is to only get a buildable, experimental build of
> > Lucene.net
> > > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not porting
> > new
> > > javadoc comments or unit tests right now, due to the vast amount of
> code
> > > that needs to be written just to get it to compile. If this work ends
> up
> > > becoming a pull request, great, otherwise it should help accelerate a
> > port
> > > of 4.3.x since the bulk of the work on core will already be done and
> > > contributors can use it as a reference. And again, we're taking the
> > > pragmatic approach of porting class-by-class, namespace-by-namespace,
> > with
> > > the understanding that until we're done the project won't build.
> > >
> > > Once complete, I also will work on updating the Analyzers contrib
> module
> > > and porting the QueryParsers contrib module, which I feel should be
> > > included in the core NuGet package for Lucene.net as the core library
> is
> > > now (post-4.0) practically useless (or atleast not turn-key) without
> > them.
> > > You can check out the code on my fork/branch here:
> > > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> > >
> > > In particular, I'd like some feedback on my work on ByteBuffer,
> > > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For the
> > MMap
> > > support, I created a ByteBuffer subclass that uses .NET 4's
> > > MemoryMappedFile support which should emulate the Java nio stuff pretty
> > > well, but required some creative shuffling of the code to make it work
> > due
> > > to lifecycle management.
> > >
> > > I'll update again this weekend or next week, when we should have
> wrapped
> > up
> > > most of the main hacking on porting the core code.
> > >
> > > Paul
> > > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com>
> > wrote:
> > >
> > > > Marcos,
> > > >
> > > > That would be helpful. As far as I can tell, the 3.0 java code is
> only
> > on
> > > > SVN here, before the lucene and solr projects were bundled together:
> > > > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> > > >
> > > > The SVN for 4.3 java is here:
> > > > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> > > > And the GitHub for 4.3 java is here:
> > > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> > > >
> > > > My fork/branch of Lucene.net for the 4.3 port is here:
> > > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> > > >
> > > > My fork is the "upstream" fork for my team members, and i'm remote
> > > merging
> > > > their changes in from their forks while they fetch/merge from mine to
> > get
> > > > everyone else's changes, rather than using pull requests. James and I
> > > have
> > > > been working the past few days on the Util namespace ahead of
> tonight's
> > > > hackathon since that namespace is in common with the rest of the
> > > > namespaces. Tonight, we'll have at least 8 guys that I know of
> hacking
> > on
> > > > porting 4.3, each with a different namespace or part of a namespace.
> > > Since
> > > > we're going class-by-class, namespace-by-namespace, the project does
> > not
> > > > build as it is. Once we finish doing a translation of each file, then
> > > we'll
> > > > hammer out any remaining issues and get it to build again. I'm hoping
> > > that
> > > > we can get at least 75% done with Core tonight. Wish us luck!
> > > >
> > > > But one thing to keep in mind is it looks like much functionality has
> > > been
> > > > moved out of core into the contrib modules, especially around
> analysis,
> > > for
> > > > 4.0+. For example, there are no built-in analyzers in core anymore.
> So
> > > when
> > > > this is all done, we may want to include at least the analysis
> contrib
> > > > module in with the standard core NuGet package, because otherwise
> it's
> > > > practically useless unless you roll your own analyzer.
> > > >
> > > > Paul
> > > >
> > > >
> > > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <
> marcoslimagon@gmail.com
> > > >wrote:
> > > >
> > > >> Hi everyone!
> > > >>
> > > >> Does someone know where can I find the 3.0.3 release from
> > Lucene(java)?
> > > >>
> > > >> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0 and
> > > make
> > > >> the diff between then and get all changes between releases... I
> gonna
> > > >> publish it here soon. (If you think there is another important
> > release,
> > > >> let
> > > >> me know)
> > > >>
> > > >> Paul, are you dealing (i`m not sure about this word, sorry) with
> 4.3.0
> > > >> port
> > > >> for .Net on github (last email)?
> > > >>
> > > >> See you,
> > > >>
> > > >>
> > > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> > > >>
> > > >> > Thanks for the discussion points, Michael.
> > > >> >
> > > >> > I would vote for not worrying about trying to achieve portable
> > > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
> > > >> completed.
> > > >> > Otherwise it may delay the project and stall it further. That's
> just
> > > my
> > > >> > $0.02 based on my admittedly selfish need for 4.x features.
> > > >> >
> > > >> > I have started porting the changes from the core library (from the
> > > >> > java lucene_solr_4_3 branch) in my fork on github in a separate
> > > branch.
> > > >> > Since I need 4.3 ASAP, I am just going to keep going on my port
> > until
> > > >> > there's changes to pull from upstream to work from. Also due to my
> > > time
> > > >> > constraints, I am not fully documenting new methods that I'm
> adding.
> > > >> But if
> > > >> > anyone wants to pull/copy/reference my changes while porting,
> that's
> > > >> > awesome. My branch currently does not build as I'm primarily going
> > > >> > class-by-class, starting with the util namespace. Once we get the
> > ball
> > > >> > rolling on a community effort, I'll stop my rogue work and join
> in.
> > > But
> > > >> > hopefully my work will be useful to someone, if not as a pull
> > request
> > > >> then
> > > >> > as a reference. I'm also going to be holding a hackathon this week
> > > with
> > > >> my
> > > >> > colleagues where we're all going to work on the port. I'm
> comparing
> > > >> files
> > > >> > and making changes as necessary, rather than starting from
> scratch.
> > My
> > > >> > repo/branch is here:
> > > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> > > >> >
> > > >> > Paul
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> > > >> > mherndon@michaelherndon.com> wrote:
> > > >> >
> > > >> > > the guithub.com repo is a mirror to the git mirror that apache
> > > >> > maintains.
> > > >> > >
> > > >> > > The was some work at one time to move the official svn
> repository
> > to
> > > >> > start
> > > >> > > using git one instead. Was that actually finalized or not?
> > > >> > >
> > > >> > > The Lucene.Net_4e (e for experimental) is an old branch to see
> > what
> > > >> kind
> > > >> > of
> > > >> > > work was involved using a portable libraries project. Some of it
> > can
> > > >> > still
> > > >> > > be used but will need to be validated against the current
> version
> > of
> > > >> > Java's
> > > >> > > Lucene. It was also using .net 4.
> > > >> > >
> > > >> > > clean branch vs current. Its going to depend on what we
> > support.
> > > >> If
> > > >> > you
> > > >> > > support windows mobile 8, win RT, then the current code in trunk
> > > will
> > > >> not
> > > >> > > compile against those versions of the framework which would a
> > > >> frustrating
> > > >> > > starting point, then you couldn't even run tests, which would
> make
> > > >> taking
> > > >> > > patches very difficult. Supporting those can almost mean larger
> > > gaps
> > > >> in
> > > >> > > design between Lucene.Net and its parent project.
> > > >> > >
> > > >> > > Also the structure has changed significantly between the
> branches
> > > and
> > > >> > the
> > > >> > > side of the code base of Lucene 4 is bigger, uses Java 6, and
> > seems
> > > >> > > significantly different. That doesn't mean you can't cherry
> pick
> > > >> stuff
> > > >> > > from the other tags/branches that would still work as is. A
> clean
> > > >> branch
> > > >> > > would also make it easier to get our build / tool chain in order
> > as
> > > >> you
> > > >> > can
> > > >> > > then do them incrementally versus having to do all the stuff
> that
> > I
> > > >> did
> > > >> > for
> > > >> > > the 3x branch which saps energy and desire to code. It could
> > also
> > > >> make
> > > >> > it
> > > >> > > easier to see which classes have been ported or not.
> > > >> > >
> > > >> > > The major downside to a clean branch is extra work it requires
> and
> > > the
> > > >> > > start up cost in time and energy of getting it in order, which
> can
> > > be
> > > >> > > daunting / intimidating and lower morale. And generally you want
> > to
> > > >> use
> > > >> > > take your legacy code and refactor instead of in someways
> starting
> > > >> over.
> > > >> > >
> > > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do
> something
> > > >> similar
> > > >> > > to
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> > > >> > > where it tracks what needs to get ported / what has been ported.
> > > >> > >
> > > >> > > What are we going to support in the next version?
> > > >> > >
> > > >> > > Who is going to work on the next version?
> > > >> > >
> > > >> > > What would make the most sense and what would invigorate the
> > > >> community to
> > > >> > > get involved more and lower the barrier to entry?
> > > >> > >
> > > >> > > I think those are the questions that would make a lot of the
> > > decisions
> > > >> > for
> > > >> > > us so that we can get back to work on lucene.net.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> > > marcoslimagon@gmail.com
> > > >> > > >wrote:
> > > >> > >
> > > >> > > > Regarding the new branch, I'm a rookie with ASF projects...
> > > >> > > >
> > > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> > > >> > > > https://github.com/apache/lucene.net points to the same
> > > repository?
> > > >> > > (This
> > > >> > > > is new for me, pretty good) Which of them do you recommend
> (i'm
> > > used
> > > >> > with
> > > >> > > > SVN and its patterns).
> > > >> > > >
> > > >> > > > I'm checking the subversion right now.
> > > >> > > >
> > > >> > > > I can see the branches/Lucene.Net_4e. I think this is a old
> > > branch,
> > > >> i`m
> > > >> > > not
> > > >> > > > sure about its current status.
> > > >> > > >
> > > >> > > > Will we wipe the current solution from /trunk and start a new
> > one?
> > > >> > > >
> > > >> > > > Thanks,
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
> > > >> > > >
> > > >> > > > > We may be forced to start with a clean/empty branch if
> people
> > > >> still
> > > >> > > want
> > > >> > > > to
> > > >> > > > > attempt supporting lucene.net for mobile devices, win RT,
> > etc.
> > > >> The
> > > >> > are
> > > >> > > > > many
> > > >> > > > > classes that Lucene.net uses from the full framework that
> > would
> > > >> not
> > > >> > be
> > > >> > > > > accessible in other versions of the .NET Framework. It also
> > > might
> > > >> > > > require
> > > >> > > > > a design that differs even more from its parent project.
> > > >> > > > >
> > > >> > > > > It might be wise to poll what users most desire in the next
> > > >> version
> > > >> > > > through
> > > >> > > > > jira or user voice.
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> > > >> > itamar@code972.com
> > > >> > > > > >wrote:
> > > >> > > > >
> > > >> > > > > > inline
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> > > >> pirwin@feature23.com>
> > > >> > > > wrote:
> > > >> > > > > >
> > > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been a TFS
> > guy
> > > >> for
> > > >> > so
> > > >> > > > > long
> > > >> > > > > > > :-)
> > > >> > > > > > >
> > > >> > > > > > > So to recap, the branch_3x will be used for any patches
> or
> > > >> > anything
> > > >> > > > to
> > > >> > > > > > the
> > > >> > > > > > > current 3.0.3 release, while trunk is what we will
> branch
> > > from
> > > >> > for
> > > >> > > 4x
> > > >> > > > > > dev.
> > > >> > > > > > > Correct?
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > > Yes - we can branch from it for 3.6 development if anyone
> > will
> > > >> be
> > > >> > > > > > interested in that
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > >
> > > >> > > > > > > Thanks for pushing the Version.cs. What's the deal with
> > the
> > > >> > github
> > > >> > > > > sync?
> > > >> > > > > > > Who could diagnose that?
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > > Not sure, Apache Infra, basically. Just use the apache
> repo
> > > for
> > > >> now
> > > >> > > > while
> > > >> > > > > > we get that sorted out.
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> > > >> > > > itamar@code972.com
> > > >> > > > > > > >wrote:
> > > >> > > > > > >
> > > >> > > > > > > > Ok, haven't noticed that branch. Just use it then for
> > 3.x
> > > >> > > > > development.
> > > >> > > > > > > WRT
> > > >> > > > > > > > v4, yeah - just fork the repo and work on whatever
> > branch.
> > > >> When
> > > >> > > you
> > > >> > > > > > send
> > > >> > > > > > > us
> > > >> > > > > > > > PRs we will merge either to master or to a dedicated
> > repo.
> > > >> For
> > > >> > > now
> > > >> > > > it
> > > >> > > > > > > > doesn't really matter, thats the beauty of git.
> > > >> > > > > > > >
> > > >> > > > > > > > I pushed a new Version.cs file, you should see it on
> the
> > > >> apache
> > > >> > > > > servers
> > > >> > > > > > > > (github sync seems to be off)
> > > >> > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> > > >> > > pirwin@feature23.com>
> > > >> > > > > > > wrote:
> > > >> > > > > > > >
> > > >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3
> > version
> > > >> of
> > > >> > the
> > > >> > > > > > > Analysis
> > > >> > > > > > > > > namespace.
> > > >> > > > > > > > >
> > > >> > > > > > > > > Not sure the checkout command is what you intended
> --
> > > you
> > > >> > might
> > > >> > > > > have
> > > >> > > > > > > > meant
> > > >> > > > > > > > > trunk instead of master, and that would create a new
> > > "3x"
> > > >> > > branch,
> > > >> > > > > > when
> > > >> > > > > > > > > there's already a "branch_3x" and that would be
> > > >> misnamed...
> > > >> > so
> > > >> > > > > maybe
> > > >> > > > > > > > > checkout -b branch_4x trunk and start there aiming
> for
> > > >> lucene
> > > >> > > > 4.3.x
> > > >> > > > > > > > > compatibility?
> > > >> > > > > > > > >
> > > >> > > > > > > > > Also, does someone with commit rights to the
> upstream
> > > >> want to
> > > >> > > > > create
> > > >> > > > > > > the
> > > >> > > > > > > > > necessary Version.cs entries, so that we're not all
> > > >> trying to
> > > >> > > > > create
> > > >> > > > > > > them
> > > >> > > > > > > > > and dealing with a merge?
> > > >> > > > > > > > >
> > > >> > > > > > > > > Paul
> > > >> > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> > > >> > > > > > itamar@code972.com
> > > >> > > > > > > > > >wrote:
> > > >> > > > > > > > >
> > > >> > > > > > > > > > Unless people here have a specific reason to use
> > > 3.6.2 I
> > > >> > > would
> > > >> > > > > > highly
> > > >> > > > > > > > > > recommed putting all the efforts we can towards v4
> > > >> > otherwise
> > > >> > > we
> > > >> > > > > > will
> > > >> > > > > > > > > never
> > > >> > > > > > > > > > make it...
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > Fork the repo from apache servers or github (same
> > > repo,
> > > >> > > > different
> > > >> > > > > > > > > remotes)
> > > >> > > > > > > > > > and checkout -b 3x -t origin/master , that should
> > work
> > > >> > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> > > >> > > > > pirwin@feature23.com>
> > > >> > > > > > > > > wrote:
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > > Itamar,
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > I agree that from scratch is not the best way to
> > do
> > > >> it, I
> > > >> > > > just
> > > >> > > > > > > > thought
> > > >> > > > > > > > > > that
> > > >> > > > > > > > > > > was the "decision" that was made from the
> > discussion
> > > >> > > > previously
> > > >> > > > > > for
> > > >> > > > > > > > the
> > > >> > > > > > > > > > 4.x
> > > >> > > > > > > > > > > work. An incremental approach will be much
> better.
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > I've created a branch of the branch_3x branch on
> > my
> > > >> fork
> > > >> > > and
> > > >> > > > > will
> > > >> > > > > > > > begin
> > > >> > > > > > > > > > > working on bringing the Analysis namespace up to
> > > >> speed to
> > > >> > > > > 3.6.2.
> > > >> > > > > > If
> > > >> > > > > > > > > > anyone
> > > >> > > > > > > > > > > wants to pull it or just reuse parts once I'm
> > done,
> > > >> have
> > > >> > at
> > > >> > > > it.
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > If I shouldn't have branched off the branch_3x
> > > branch,
> > > >> > > please
> > > >> > > > > let
> > > >> > > > > > > me
> > > >> > > > > > > > > know
> > > >> > > > > > > > > > > what I should have branched from (trunk?)
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > Paul
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
> > Syn-Hershko <
> > > >> > > > > > > > itamar@code972.com
> > > >> > > > > > > > > > > >wrote:
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > > Thanks Prescott for bringing this up again :)
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > Paul, the problem is no one can really know
> what
> > > it
> > > >> > would
> > > >> > > > > take
> > > >> > > > > > > > until
> > > >> > > > > > > > > > they
> > > >> > > > > > > > > > > > have deep dived into the work, and even then
> > > >> decisions
> > > >> > > > could
> > > >> > > > > > and
> > > >> > > > > > > > will
> > > >> > > > > > > > > > > > change. I will strongly advise against
> starting
> > > from
> > > >> > > > scratch,
> > > >> > > > > > > > > although
> > > >> > > > > > > > > > I
> > > >> > > > > > > > > > > do
> > > >> > > > > > > > > > > > think a lot in the current structure should
> > > change,
> > > >> but
> > > >> > > its
> > > >> > > > > > going
> > > >> > > > > > > > to
> > > >> > > > > > > > > be
> > > >> > > > > > > > > > > > much easier to change it in place, refactoring
> > > where
> > > >> > > > needed,
> > > >> > > > > > than
> > > >> > > > > > > > > > > starting
> > > >> > > > > > > > > > > > all over again. Once we kicked this off I
> > > personally
> > > >> > will
> > > >> > > > be
> > > >> > > > > > > happy
> > > >> > > > > > > > > with
> > > >> > > > > > > > > > > you
> > > >> > > > > > > > > > > > taking the analysis part of Lucene and porting
> > it,
> > > >> its
> > > >> > > > pretty
> > > >> > > > > > > much
> > > >> > > > > > > > > self
> > > >> > > > > > > > > > > > contained.
> > > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a fork
> > and
> > > >> send
> > > >> > > us
> > > >> > > > > PRs,
> > > >> > > > > > > its
> > > >> > > > > > > > > > much
> > > >> > > > > > > > > > > > more straight forward than the v4 upgrade
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > Marcos, porting class by class is the fastest
> > way
> > > >> to do
> > > >> > > > this,
> > > >> > > > > > we
> > > >> > > > > > > > can
> > > >> > > > > > > > > > then
> > > >> > > > > > > > > > > > concentrate on .NETifying and optimizing using
> > > .NET
> > > >> > > > > constructs.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > That said, I think the way to go is create a
> > > branch
> > > >> out
> > > >> > > of
> > > >> > > > > the
> > > >> > > > > > > > > current
> > > >> > > > > > > > > > > git
> > > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
> > working
> > > on
> > > >> > > master
> > > >> > > > > > > > towards a
> > > >> > > > > > > > > > 4.3
> > > >> > > > > > > > > > > > compatible version. The actual port should be
> > > using
> > > >> a
> > > >> > > > process
> > > >> > > > > > > that
> > > >> > > > > > > > > > > ensures
> > > >> > > > > > > > > > > > all Java classes are ported with their tests,
> > and
> > > >> that
> > > >> > > > those
> > > >> > > > > > > tests
> > > >> > > > > > > > > > pass -
> > > >> > > > > > > > > > > > but I'm against committing any Java code to
> our
> > > >> > > > repositories.
> > > >> > > > > > The
> > > >> > > > > > > > > > process
> > > >> > > > > > > > > > > > should probably be working on classes in some
> > > order
> > > >> > > > > > > > (alphabetically,
> > > >> > > > > > > > > or
> > > >> > > > > > > > > > > > core classes first) and getting each class to
> > > >> compile
> > > >> > > > before
> > > >> > > > > > > moving
> > > >> > > > > > > > > > > > forward. I don't mind about the project not
> > being
> > > >> > > > compilable
> > > >> > > > > > for
> > > >> > > > > > > a
> > > >> > > > > > > > > > month
> > > >> > > > > > > > > > > or
> > > >> > > > > > > > > > > > two.
> > > >> > > > > > > > > > > > Once this is done a process of .NETifying and
> > > >> proofing
> > > >> > > the
> > > >> > > > > code
> > > >> > > > > > > can
> > > >> > > > > > > > > be
> > > >> > > > > > > > > > > > started, at which point we will already have a
> > > >> working
> > > >> > v4
> > > >> > > > > > version
> > > >> > > > > > > > so
> > > >> > > > > > > > > it
> > > >> > > > > > > > > > > > will be easier to keep up with the Java
> project.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > The first step IMO is to stabilize the test
> > suite
> > > so
> > > >> > > tests
> > > >> > > > > > could
> > > >> > > > > > > > more
> > > >> > > > > > > > > > or
> > > >> > > > > > > > > > > > less be copied and pasted (e.g. implementing
> > > >> Java-like
> > > >> > > > > > > assertEquals
> > > >> > > > > > > > > > > methods
> > > >> > > > > > > > > > > > etc; I find xUnit to be much easier to work
> with
> > > >> than
> > > >> > > > > NUnit). I
> > > >> > > > > > > > > already
> > > >> > > > > > > > > > > did
> > > >> > > > > > > > > > > > some work there but there's still a lot to do.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > Unfortunately I can't dedicate time myself at
> > this
> > > >> > point,
> > > >> > > > > but I
> > > >> > > > > > > > > should
> > > >> > > > > > > > > > be
> > > >> > > > > > > > > > > > back in business in August, at which point I
> can
> > > >> > dedicate
> > > >> > > > > > several
> > > >> > > > > > > > > > hours a
> > > >> > > > > > > > > > > > week. Until then I'll be happy to watch
> closely
> > > and
> > > >> > even
> > > >> > > > > > > coordinate
> > > >> > > > > > > > > the
> > > >> > > > > > > > > > > > work to some extent.
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > > >> > > > > > > > > marcoslimagon@gmail.com
> > > >> > > > > > > > > > > > >wrote:
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > > It really sounds good to me, this is a kick
> > > start
> > > >> > =). I
> > > >> > > > > > haven't
> > > >> > > > > > > > > > > > contributed
> > > >> > > > > > > > > > > > > anything
> > > >> > > > > > > > > > > > > yet, but I would like to help you all to get
> > > this
> > > >> job
> > > >> > > > done.
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > I'm completely agree with Paul and Prescott.
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > I know that there is a high commitment for
> > keep
> > > >> the
> > > >> > > > > > > > > > retrocompatibility
> > > >> > > > > > > > > > > on
> > > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big
> changes
> > > >> every
> > > >> > > > > release?
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable
> version
> > > >> from a
> > > >> > > > > Lucene
> > > >> > > > > > > > > version,
> > > >> > > > > > > > > > > > > right? If the Lucene API gets only minor
> > changes
> > > >> > every
> > > >> > > > > stable
> > > >> > > > > > > > > release
> > > >> > > > > > > > > > > (or
> > > >> > > > > > > > > > > > > keep most of its source-code), we could
> > compare
> > > >> the
> > > >> > > > > versions,
> > > >> > > > > > > > check
> > > >> > > > > > > > > > the
> > > >> > > > > > > > > > > > > differences and bring them to Lucene.Net.
> > > Again, I
> > > >> > > > haven't
> > > >> > > > > > > > > > contributed
> > > >> > > > > > > > > > > > with
> > > >> > > > > > > > > > > > > yet, so I don't know how it is (just an
> idea).
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > What's your approach for implement simple
> > > >> performance
> > > >> > > > > > > > improvements
> > > >> > > > > > > > > > > > (without
> > > >> > > > > > > > > > > > > adding references or changing methods
> > > signatures)?
> > > >> > Does
> > > >> > > > it
> > > >> > > > > > > could
> > > >> > > > > > > > be
> > > >> > > > > > > > > > > done,
> > > >> > > > > > > > > > > > > or "follow the java version only"?
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > This is just an "outsider" suggestion as I
> > > >> haven't
> > > >> > > > > > > contributed
> > > >> > > > > > > > > > > anything
> > > >> > > > > > > > > > > > > > yet, although I will definitely help with
> > the
> > > >> 4.x
> > > >> > > work
> > > >> > > > > as I
> > > >> > > > > > > > have
> > > >> > > > > > > > > a
> > > >> > > > > > > > > > > > vested
> > > >> > > > > > > > > > > > > > interest in seeing that get completed. I
> > think
> > > >> > there
> > > >> > > > > should
> > > >> > > > > > > be
> > > >> > > > > > > > > one
> > > >> > > > > > > > > > > > person
> > > >> > > > > > > > > > > > > > (or perhaps two) guiding what the
> structure
> > > and
> > > >> > > > workflow
> > > >> > > > > > will
> > > >> > > > > > > > > look
> > > >> > > > > > > > > > > like
> > > >> > > > > > > > > > > > > to
> > > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going to
> be
> > > >> > starting
> > > >> > > > from
> > > >> > > > > > > > scratch
> > > >> > > > > > > > > > as
> > > >> > > > > > > > > > > a
> > > >> > > > > > > > > > > > > > fresh port, that person should set up the
> > > >> project,
> > > >> > > get
> > > >> > > > > > > > everything
> > > >> > > > > > > > > > > going
> > > >> > > > > > > > > > > > > in
> > > >> > > > > > > > > > > > > > source control, create the folder
> structure,
> > > >> maybe
> > > >> > > stub
> > > >> > > > > out
> > > >> > > > > > > > some
> > > >> > > > > > > > > > > > classes,
> > > >> > > > > > > > > > > > > > etc. Then divide and conquer with anyone
> > > >> interested
> > > >> > > in
> > > >> > > > > > > > > > contributing,
> > > >> > > > > > > > > > > > > > perhaps by namespace.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > I like the idea of throwing the java code
> in
> > > >> there
> > > >> > so
> > > >> > > > > it's
> > > >> > > > > > > easy
> > > >> > > > > > > > > to
> > > >> > > > > > > > > > > > > > reference.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > Again, I can work on Lucene.Net.Documents,
> > > >> > > > > > > Lucene.Net.Analysis,
> > > >> > > > > > > > > or
> > > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others, those
> are
> > > >> just
> > > >> > the
> > > >> > > > > ones
> > > >> > > > > > > I'm
> > > >> > > > > > > > > most
> > > >> > > > > > > > > > > > > > familiar with the inner workings. Tell me
> > what
> > > >> to
> > > >> > do
> > > >> > > > and
> > > >> > > > > > I'll
> > > >> > > > > > > > get
> > > >> > > > > > > > > > > > started
> > > >> > > > > > > > > > > > > > on my fork.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > Paul Irwin
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott
> > > Nasser
> > > >> <
> > > >> > > > > > > > > > > geobmx540@hotmail.com
> > > >> > > > > > > > > > > > > > >wrote:
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > > Hey guys -
> > > >> > > > > > > > > > > > > > > I know I've been MIA a little while. We
> > > have a
> > > >> > > board
> > > >> > > > > > report
> > > >> > > > > > > > due
> > > >> > > > > > > > > > > soon
> > > >> > > > > > > > > > > > -
> > > >> > > > > > > > > > > > > I
> > > >> > > > > > > > > > > > > > > think it prudent that we advise them
> that
> > we
> > > >> seem
> > > >> > > to
> > > >> > > > > have
> > > >> > > > > > > > > stalled
> > > >> > > > > > > > > > > > > > somewhat.
> > > >> > > > > > > > > > > > > > > We've got a few low hanging items out of
> > of
> > > >> jira
> > > >> > > and
> > > >> > > > > have
> > > >> > > > > > > > been
> > > >> > > > > > > > > > > > > responsive
> > > >> > > > > > > > > > > > > > > on the mailing list to community
> > questions,
> > > >> but I
> > > >> > > > don't
> > > >> > > > > > > think
> > > >> > > > > > > > > > we've
> > > >> > > > > > > > > > > > > done
> > > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
> > > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and
> start
> > us
> > > >> back
> > > >> > > up
> > > >> > > > > > moving
> > > >> > > > > > > > > > > forward.
> > > >> > > > > > > > > > > > > What
> > > >> > > > > > > > > > > > > > > is the best way to accomplish this? If
> we
> > > took
> > > >> > the
> > > >> > > > java
> > > >> > > > > > > > lucene
> > > >> > > > > > > > > > 4.0
> > > >> > > > > > > > > > > > code
> > > >> > > > > > > > > > > > > > and
> > > >> > > > > > > > > > > > > > > committed that java to our branch and
> then
> > > >> just
> > > >> > let
> > > >> > > > > > people
> > > >> > > > > > > > pull
> > > >> > > > > > > > > > > that
> > > >> > > > > > > > > > > > > down
> > > >> > > > > > > > > > > > > > > and being changing / modifying is that
> one
> > > >> way to
> > > >> > > > maybe
> > > >> > > > > > > make
> > > >> > > > > > > > > some
> > > >> > > > > > > > > > > > > forward
> > > >> > > > > > > > > > > > > > > progress?
> > > >> > > > > > > > > > > > > > > ~P
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > --
> > > >> > > > > > > > > > > > > --
> > > >> > > > > > > > > > > > > Marcos Lima
> > > >> > > > > > > > > > > > > Software Developer/Tech Lead
> > > >> > > > > > > > > > > > > marcoslimagon@gmail.com
> > > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > --
> > > >> > > > --
> > > >> > > > Marcos Lima
> > > >> > > > Software Developer/Tech Lead
> > > >> > > > marcoslimagon@gmail.com
> > > >> > > > tel: +55 (19) 9798-9335
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> --
> > > >> Marcos Lima
> > > >> Software Developer/Tech Lead
> > > >> marcoslimagon@gmail.com
> > > >> tel: +55 (19) 9798-9335
> > > >>
> > > >
> > > >
> > >
> >
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Hey all, sorry it's been a little while, but I wanted to let you know that
although I took a few weeks off from it, I now have a 4.3.1 equivalent
Lucene.net core building and able to write a simple index in Lucene 4.2
codec and read in things like the number of documents and whatnot. Since
QueryParser has been moved to a separate module in Lucene Java 4.x, I
haven't ported that yet so I haven't done a real search, and I only built
the index using a quick port of KeywordAnalyzer which all those analyzers
have also moved to another module. But this is definitely good progress and
should be a launch point for finishing a 4.3/4.4 port.
You can see my fork/branch here:
https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note: like I
said, only core builds now, no modules/tests build, so only open the
Lucene.Net.Core.sln)
I'm sure it's riddled with bugs, but I hope this can help kickstart the
community into finishing the 4.3/4.4 port. Let me know if you have any
questions, thanks!
On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <it...@code972.com>wrote:
> Paul, that's awesome. I will need some more time to go over this thread and
> your work to give actual feedback, SUPER busy at the moment
>
>
> On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com> wrote:
>
> > All,
> >
> > My colleagues and I have made good progress on porting Lucene 4.3's core
> > library before, during, and after the hackathon last week. We now only
> have
> > some remaining items in Search, Index, and Codecs namespaces (plus a few
> > other minor ones here and there). I expect to be done by the end of the
> > weekend. Analysis, Documents, Store, Util (except some FST and Packed),
> and
> > the root Codecs and Codecs.PerField namespaces are all now "done".
> >
> > Again, my goal is to only get a buildable, experimental build of
> Lucene.net
> > with 4.3.0 (now 4.3.1) compatibility. We are intentionally not porting
> new
> > javadoc comments or unit tests right now, due to the vast amount of code
> > that needs to be written just to get it to compile. If this work ends up
> > becoming a pull request, great, otherwise it should help accelerate a
> port
> > of 4.3.x since the bulk of the work on core will already be done and
> > contributors can use it as a reference. And again, we're taking the
> > pragmatic approach of porting class-by-class, namespace-by-namespace,
> with
> > the understanding that until we're done the project won't build.
> >
> > Once complete, I also will work on updating the Analyzers contrib module
> > and porting the QueryParsers contrib module, which I feel should be
> > included in the core NuGet package for Lucene.net as the core library is
> > now (post-4.0) practically useless (or atleast not turn-key) without
> them.
> > You can check out the code on my fork/branch here:
> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >
> > In particular, I'd like some feedback on my work on ByteBuffer,
> > MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For the
> MMap
> > support, I created a ByteBuffer subclass that uses .NET 4's
> > MemoryMappedFile support which should emulate the Java nio stuff pretty
> > well, but required some creative shuffling of the code to make it work
> due
> > to lifecycle management.
> >
> > I'll update again this weekend or next week, when we should have wrapped
> up
> > most of the main hacking on porting the core code.
> >
> > Paul
> > On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >
> > > Marcos,
> > >
> > > That would be helpful. As far as I can tell, the 3.0 java code is only
> on
> > > SVN here, before the lucene and solr projects were bundled together:
> > > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> > >
> > > The SVN for 4.3 java is here:
> > > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> > > And the GitHub for 4.3 java is here:
> > > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> > >
> > > My fork/branch of Lucene.net for the 4.3 port is here:
> > > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> > >
> > > My fork is the "upstream" fork for my team members, and i'm remote
> > merging
> > > their changes in from their forks while they fetch/merge from mine to
> get
> > > everyone else's changes, rather than using pull requests. James and I
> > have
> > > been working the past few days on the Util namespace ahead of tonight's
> > > hackathon since that namespace is in common with the rest of the
> > > namespaces. Tonight, we'll have at least 8 guys that I know of hacking
> on
> > > porting 4.3, each with a different namespace or part of a namespace.
> > Since
> > > we're going class-by-class, namespace-by-namespace, the project does
> not
> > > build as it is. Once we finish doing a translation of each file, then
> > we'll
> > > hammer out any remaining issues and get it to build again. I'm hoping
> > that
> > > we can get at least 75% done with Core tonight. Wish us luck!
> > >
> > > But one thing to keep in mind is it looks like much functionality has
> > been
> > > moved out of core into the contrib modules, especially around analysis,
> > for
> > > 4.0+. For example, there are no built-in analyzers in core anymore. So
> > when
> > > this is all done, we may want to include at least the analysis contrib
> > > module in with the standard core NuGet package, because otherwise it's
> > > practically useless unless you roll your own analyzer.
> > >
> > > Paul
> > >
> > >
> > > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <marcoslimagon@gmail.com
> > >wrote:
> > >
> > >> Hi everyone!
> > >>
> > >> Does someone know where can I find the 3.0.3 release from
> Lucene(java)?
> > >>
> > >> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0 and
> > make
> > >> the diff between then and get all changes between releases... I gonna
> > >> publish it here soon. (If you think there is another important
> release,
> > >> let
> > >> me know)
> > >>
> > >> Paul, are you dealing (i`m not sure about this word, sorry) with 4.3.0
> > >> port
> > >> for .Net on github (last email)?
> > >>
> > >> See you,
> > >>
> > >>
> > >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> > >>
> > >> > Thanks for the discussion points, Michael.
> > >> >
> > >> > I would vote for not worrying about trying to achieve portable
> > >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
> > >> completed.
> > >> > Otherwise it may delay the project and stall it further. That's just
> > my
> > >> > $0.02 based on my admittedly selfish need for 4.x features.
> > >> >
> > >> > I have started porting the changes from the core library (from the
> > >> > java lucene_solr_4_3 branch) in my fork on github in a separate
> > branch.
> > >> > Since I need 4.3 ASAP, I am just going to keep going on my port
> until
> > >> > there's changes to pull from upstream to work from. Also due to my
> > time
> > >> > constraints, I am not fully documenting new methods that I'm adding.
> > >> But if
> > >> > anyone wants to pull/copy/reference my changes while porting, that's
> > >> > awesome. My branch currently does not build as I'm primarily going
> > >> > class-by-class, starting with the util namespace. Once we get the
> ball
> > >> > rolling on a community effort, I'll stop my rogue work and join in.
> > But
> > >> > hopefully my work will be useful to someone, if not as a pull
> request
> > >> then
> > >> > as a reference. I'm also going to be holding a hackathon this week
> > with
> > >> my
> > >> > colleagues where we're all going to work on the port. I'm comparing
> > >> files
> > >> > and making changes as necessary, rather than starting from scratch.
> My
> > >> > repo/branch is here:
> > >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> > >> >
> > >> > Paul
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> > >> > mherndon@michaelherndon.com> wrote:
> > >> >
> > >> > > the guithub.com repo is a mirror to the git mirror that apache
> > >> > maintains.
> > >> > >
> > >> > > The was some work at one time to move the official svn repository
> to
> > >> > start
> > >> > > using git one instead. Was that actually finalized or not?
> > >> > >
> > >> > > The Lucene.Net_4e (e for experimental) is an old branch to see
> what
> > >> kind
> > >> > of
> > >> > > work was involved using a portable libraries project. Some of it
> can
> > >> > still
> > >> > > be used but will need to be validated against the current version
> of
> > >> > Java's
> > >> > > Lucene. It was also using .net 4.
> > >> > >
> > >> > > clean branch vs current. Its going to depend on what we
> support.
> > >> If
> > >> > you
> > >> > > support windows mobile 8, win RT, then the current code in trunk
> > will
> > >> not
> > >> > > compile against those versions of the framework which would a
> > >> frustrating
> > >> > > starting point, then you couldn't even run tests, which would make
> > >> taking
> > >> > > patches very difficult. Supporting those can almost mean larger
> > gaps
> > >> in
> > >> > > design between Lucene.Net and its parent project.
> > >> > >
> > >> > > Also the structure has changed significantly between the branches
> > and
> > >> > the
> > >> > > side of the code base of Lucene 4 is bigger, uses Java 6, and
> seems
> > >> > > significantly different. That doesn't mean you can't cherry pick
> > >> stuff
> > >> > > from the other tags/branches that would still work as is. A clean
> > >> branch
> > >> > > would also make it easier to get our build / tool chain in order
> as
> > >> you
> > >> > can
> > >> > > then do them incrementally versus having to do all the stuff that
> I
> > >> did
> > >> > for
> > >> > > the 3x branch which saps energy and desire to code. It could
> also
> > >> make
> > >> > it
> > >> > > easier to see which classes have been ported or not.
> > >> > >
> > >> > > The major downside to a clean branch is extra work it requires and
> > the
> > >> > > start up cost in time and energy of getting it in order, which can
> > be
> > >> > > daunting / intimidating and lower morale. And generally you want
> to
> > >> use
> > >> > > take your legacy code and refactor instead of in someways starting
> > >> over.
> > >> > >
> > >> > > Are we going to port lucene 4 or 4.3 ? If so I can do something
> > >> similar
> > >> > > to
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> > >> > > where it tracks what needs to get ported / what has been ported.
> > >> > >
> > >> > > What are we going to support in the next version?
> > >> > >
> > >> > > Who is going to work on the next version?
> > >> > >
> > >> > > What would make the most sense and what would invigorate the
> > >> community to
> > >> > > get involved more and lower the barrier to entry?
> > >> > >
> > >> > > I think those are the questions that would make a lot of the
> > decisions
> > >> > for
> > >> > > us so that we can get back to work on lucene.net.
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> > marcoslimagon@gmail.com
> > >> > > >wrote:
> > >> > >
> > >> > > > Regarding the new branch, I'm a rookie with ASF projects...
> > >> > > >
> > >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> > >> > > > https://github.com/apache/lucene.net points to the same
> > repository?
> > >> > > (This
> > >> > > > is new for me, pretty good) Which of them do you recommend (i'm
> > used
> > >> > with
> > >> > > > SVN and its patterns).
> > >> > > >
> > >> > > > I'm checking the subversion right now.
> > >> > > >
> > >> > > > I can see the branches/Lucene.Net_4e. I think this is a old
> > branch,
> > >> i`m
> > >> > > not
> > >> > > > sure about its current status.
> > >> > > >
> > >> > > > Will we wipe the current solution from /trunk and start a new
> one?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
> > >> > > >
> > >> > > > > We may be forced to start with a clean/empty branch if people
> > >> still
> > >> > > want
> > >> > > > to
> > >> > > > > attempt supporting lucene.net for mobile devices, win RT,
> etc.
> > >> The
> > >> > are
> > >> > > > > many
> > >> > > > > classes that Lucene.net uses from the full framework that
> would
> > >> not
> > >> > be
> > >> > > > > accessible in other versions of the .NET Framework. It also
> > might
> > >> > > > require
> > >> > > > > a design that differs even more from its parent project.
> > >> > > > >
> > >> > > > > It might be wise to poll what users most desire in the next
> > >> version
> > >> > > > through
> > >> > > > > jira or user voice.
> > >> > > > >
> > >> > > > >
> > >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> > >> > itamar@code972.com
> > >> > > > > >wrote:
> > >> > > > >
> > >> > > > > > inline
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> > >> pirwin@feature23.com>
> > >> > > > wrote:
> > >> > > > > >
> > >> > > > > > > Ah, I gotcha. Still getting used to git, I've been a TFS
> guy
> > >> for
> > >> > so
> > >> > > > > long
> > >> > > > > > > :-)
> > >> > > > > > >
> > >> > > > > > > So to recap, the branch_3x will be used for any patches or
> > >> > anything
> > >> > > > to
> > >> > > > > > the
> > >> > > > > > > current 3.0.3 release, while trunk is what we will branch
> > from
> > >> > for
> > >> > > 4x
> > >> > > > > > dev.
> > >> > > > > > > Correct?
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > Yes - we can branch from it for 3.6 development if anyone
> will
> > >> be
> > >> > > > > > interested in that
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > > Thanks for pushing the Version.cs. What's the deal with
> the
> > >> > github
> > >> > > > > sync?
> > >> > > > > > > Who could diagnose that?
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > Not sure, Apache Infra, basically. Just use the apache repo
> > for
> > >> now
> > >> > > > while
> > >> > > > > > we get that sorted out.
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> > >> > > > itamar@code972.com
> > >> > > > > > > >wrote:
> > >> > > > > > >
> > >> > > > > > > > Ok, haven't noticed that branch. Just use it then for
> 3.x
> > >> > > > > development.
> > >> > > > > > > WRT
> > >> > > > > > > > v4, yeah - just fork the repo and work on whatever
> branch.
> > >> When
> > >> > > you
> > >> > > > > > send
> > >> > > > > > > us
> > >> > > > > > > > PRs we will merge either to master or to a dedicated
> repo.
> > >> For
> > >> > > now
> > >> > > > it
> > >> > > > > > > > doesn't really matter, thats the beauty of git.
> > >> > > > > > > >
> > >> > > > > > > > I pushed a new Version.cs file, you should see it on the
> > >> apache
> > >> > > > > servers
> > >> > > > > > > > (github sync seems to be off)
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> > >> > > pirwin@feature23.com>
> > >> > > > > > > wrote:
> > >> > > > > > > >
> > >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3
> version
> > >> of
> > >> > the
> > >> > > > > > > Analysis
> > >> > > > > > > > > namespace.
> > >> > > > > > > > >
> > >> > > > > > > > > Not sure the checkout command is what you intended --
> > you
> > >> > might
> > >> > > > > have
> > >> > > > > > > > meant
> > >> > > > > > > > > trunk instead of master, and that would create a new
> > "3x"
> > >> > > branch,
> > >> > > > > > when
> > >> > > > > > > > > there's already a "branch_3x" and that would be
> > >> misnamed...
> > >> > so
> > >> > > > > maybe
> > >> > > > > > > > > checkout -b branch_4x trunk and start there aiming for
> > >> lucene
> > >> > > > 4.3.x
> > >> > > > > > > > > compatibility?
> > >> > > > > > > > >
> > >> > > > > > > > > Also, does someone with commit rights to the upstream
> > >> want to
> > >> > > > > create
> > >> > > > > > > the
> > >> > > > > > > > > necessary Version.cs entries, so that we're not all
> > >> trying to
> > >> > > > > create
> > >> > > > > > > them
> > >> > > > > > > > > and dealing with a merge?
> > >> > > > > > > > >
> > >> > > > > > > > > Paul
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> > >> > > > > > itamar@code972.com
> > >> > > > > > > > > >wrote:
> > >> > > > > > > > >
> > >> > > > > > > > > > Unless people here have a specific reason to use
> > 3.6.2 I
> > >> > > would
> > >> > > > > > highly
> > >> > > > > > > > > > recommed putting all the efforts we can towards v4
> > >> > otherwise
> > >> > > we
> > >> > > > > > will
> > >> > > > > > > > > never
> > >> > > > > > > > > > make it...
> > >> > > > > > > > > >
> > >> > > > > > > > > > Fork the repo from apache servers or github (same
> > repo,
> > >> > > > different
> > >> > > > > > > > > remotes)
> > >> > > > > > > > > > and checkout -b 3x -t origin/master , that should
> work
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> > >> > > > > pirwin@feature23.com>
> > >> > > > > > > > > wrote:
> > >> > > > > > > > > >
> > >> > > > > > > > > > > Itamar,
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > I agree that from scratch is not the best way to
> do
> > >> it, I
> > >> > > > just
> > >> > > > > > > > thought
> > >> > > > > > > > > > that
> > >> > > > > > > > > > > was the "decision" that was made from the
> discussion
> > >> > > > previously
> > >> > > > > > for
> > >> > > > > > > > the
> > >> > > > > > > > > > 4.x
> > >> > > > > > > > > > > work. An incremental approach will be much better.
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > I've created a branch of the branch_3x branch on
> my
> > >> fork
> > >> > > and
> > >> > > > > will
> > >> > > > > > > > begin
> > >> > > > > > > > > > > working on bringing the Analysis namespace up to
> > >> speed to
> > >> > > > > 3.6.2.
> > >> > > > > > If
> > >> > > > > > > > > > anyone
> > >> > > > > > > > > > > wants to pull it or just reuse parts once I'm
> done,
> > >> have
> > >> > at
> > >> > > > it.
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > If I shouldn't have branched off the branch_3x
> > branch,
> > >> > > please
> > >> > > > > let
> > >> > > > > > > me
> > >> > > > > > > > > know
> > >> > > > > > > > > > > what I should have branched from (trunk?)
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > Paul
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
> Syn-Hershko <
> > >> > > > > > > > itamar@code972.com
> > >> > > > > > > > > > > >wrote:
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > > Thanks Prescott for bringing this up again :)
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > Paul, the problem is no one can really know what
> > it
> > >> > would
> > >> > > > > take
> > >> > > > > > > > until
> > >> > > > > > > > > > they
> > >> > > > > > > > > > > > have deep dived into the work, and even then
> > >> decisions
> > >> > > > could
> > >> > > > > > and
> > >> > > > > > > > will
> > >> > > > > > > > > > > > change. I will strongly advise against starting
> > from
> > >> > > > scratch,
> > >> > > > > > > > > although
> > >> > > > > > > > > > I
> > >> > > > > > > > > > > do
> > >> > > > > > > > > > > > think a lot in the current structure should
> > change,
> > >> but
> > >> > > its
> > >> > > > > > going
> > >> > > > > > > > to
> > >> > > > > > > > > be
> > >> > > > > > > > > > > > much easier to change it in place, refactoring
> > where
> > >> > > > needed,
> > >> > > > > > than
> > >> > > > > > > > > > > starting
> > >> > > > > > > > > > > > all over again. Once we kicked this off I
> > personally
> > >> > will
> > >> > > > be
> > >> > > > > > > happy
> > >> > > > > > > > > with
> > >> > > > > > > > > > > you
> > >> > > > > > > > > > > > taking the analysis part of Lucene and porting
> it,
> > >> its
> > >> > > > pretty
> > >> > > > > > > much
> > >> > > > > > > > > self
> > >> > > > > > > > > > > > contained.
> > >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a fork
> and
> > >> send
> > >> > > us
> > >> > > > > PRs,
> > >> > > > > > > its
> > >> > > > > > > > > > much
> > >> > > > > > > > > > > > more straight forward than the v4 upgrade
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > Marcos, porting class by class is the fastest
> way
> > >> to do
> > >> > > > this,
> > >> > > > > > we
> > >> > > > > > > > can
> > >> > > > > > > > > > then
> > >> > > > > > > > > > > > concentrate on .NETifying and optimizing using
> > .NET
> > >> > > > > constructs.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > That said, I think the way to go is create a
> > branch
> > >> out
> > >> > > of
> > >> > > > > the
> > >> > > > > > > > > current
> > >> > > > > > > > > > > git
> > >> > > > > > > > > > > > master HEAD and label it "3.x", and start
> working
> > on
> > >> > > master
> > >> > > > > > > > towards a
> > >> > > > > > > > > > 4.3
> > >> > > > > > > > > > > > compatible version. The actual port should be
> > using
> > >> a
> > >> > > > process
> > >> > > > > > > that
> > >> > > > > > > > > > > ensures
> > >> > > > > > > > > > > > all Java classes are ported with their tests,
> and
> > >> that
> > >> > > > those
> > >> > > > > > > tests
> > >> > > > > > > > > > pass -
> > >> > > > > > > > > > > > but I'm against committing any Java code to our
> > >> > > > repositories.
> > >> > > > > > The
> > >> > > > > > > > > > process
> > >> > > > > > > > > > > > should probably be working on classes in some
> > order
> > >> > > > > > > > (alphabetically,
> > >> > > > > > > > > or
> > >> > > > > > > > > > > > core classes first) and getting each class to
> > >> compile
> > >> > > > before
> > >> > > > > > > moving
> > >> > > > > > > > > > > > forward. I don't mind about the project not
> being
> > >> > > > compilable
> > >> > > > > > for
> > >> > > > > > > a
> > >> > > > > > > > > > month
> > >> > > > > > > > > > > or
> > >> > > > > > > > > > > > two.
> > >> > > > > > > > > > > > Once this is done a process of .NETifying and
> > >> proofing
> > >> > > the
> > >> > > > > code
> > >> > > > > > > can
> > >> > > > > > > > > be
> > >> > > > > > > > > > > > started, at which point we will already have a
> > >> working
> > >> > v4
> > >> > > > > > version
> > >> > > > > > > > so
> > >> > > > > > > > > it
> > >> > > > > > > > > > > > will be easier to keep up with the Java project.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > The first step IMO is to stabilize the test
> suite
> > so
> > >> > > tests
> > >> > > > > > could
> > >> > > > > > > > more
> > >> > > > > > > > > > or
> > >> > > > > > > > > > > > less be copied and pasted (e.g. implementing
> > >> Java-like
> > >> > > > > > > assertEquals
> > >> > > > > > > > > > > methods
> > >> > > > > > > > > > > > etc; I find xUnit to be much easier to work with
> > >> than
> > >> > > > > NUnit). I
> > >> > > > > > > > > already
> > >> > > > > > > > > > > did
> > >> > > > > > > > > > > > some work there but there's still a lot to do.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > Unfortunately I can't dedicate time myself at
> this
> > >> > point,
> > >> > > > > but I
> > >> > > > > > > > > should
> > >> > > > > > > > > > be
> > >> > > > > > > > > > > > back in business in August, at which point I can
> > >> > dedicate
> > >> > > > > > several
> > >> > > > > > > > > > hours a
> > >> > > > > > > > > > > > week. Until then I'll be happy to watch closely
> > and
> > >> > even
> > >> > > > > > > coordinate
> > >> > > > > > > > > the
> > >> > > > > > > > > > > > work to some extent.
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > >> > > > > > > > > marcoslimagon@gmail.com
> > >> > > > > > > > > > > > >wrote:
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > > It really sounds good to me, this is a kick
> > start
> > >> > =). I
> > >> > > > > > haven't
> > >> > > > > > > > > > > > contributed
> > >> > > > > > > > > > > > > anything
> > >> > > > > > > > > > > > > yet, but I would like to help you all to get
> > this
> > >> job
> > >> > > > done.
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > I'm completely agree with Paul and Prescott.
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > I know that there is a high commitment for
> keep
> > >> the
> > >> > > > > > > > > > retrocompatibility
> > >> > > > > > > > > > > on
> > >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big changes
> > >> every
> > >> > > > > release?
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable version
> > >> from a
> > >> > > > > Lucene
> > >> > > > > > > > > version,
> > >> > > > > > > > > > > > > right? If the Lucene API gets only minor
> changes
> > >> > every
> > >> > > > > stable
> > >> > > > > > > > > release
> > >> > > > > > > > > > > (or
> > >> > > > > > > > > > > > > keep most of its source-code), we could
> compare
> > >> the
> > >> > > > > versions,
> > >> > > > > > > > check
> > >> > > > > > > > > > the
> > >> > > > > > > > > > > > > differences and bring them to Lucene.Net.
> > Again, I
> > >> > > > haven't
> > >> > > > > > > > > > contributed
> > >> > > > > > > > > > > > with
> > >> > > > > > > > > > > > > yet, so I don't know how it is (just an idea).
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > What's your approach for implement simple
> > >> performance
> > >> > > > > > > > improvements
> > >> > > > > > > > > > > > (without
> > >> > > > > > > > > > > > > adding references or changing methods
> > signatures)?
> > >> > Does
> > >> > > > it
> > >> > > > > > > could
> > >> > > > > > > > be
> > >> > > > > > > > > > > done,
> > >> > > > > > > > > > > > > or "follow the java version only"?
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > This is just an "outsider" suggestion as I
> > >> haven't
> > >> > > > > > > contributed
> > >> > > > > > > > > > > anything
> > >> > > > > > > > > > > > > > yet, although I will definitely help with
> the
> > >> 4.x
> > >> > > work
> > >> > > > > as I
> > >> > > > > > > > have
> > >> > > > > > > > > a
> > >> > > > > > > > > > > > vested
> > >> > > > > > > > > > > > > > interest in seeing that get completed. I
> think
> > >> > there
> > >> > > > > should
> > >> > > > > > > be
> > >> > > > > > > > > one
> > >> > > > > > > > > > > > person
> > >> > > > > > > > > > > > > > (or perhaps two) guiding what the structure
> > and
> > >> > > > workflow
> > >> > > > > > will
> > >> > > > > > > > > look
> > >> > > > > > > > > > > like
> > >> > > > > > > > > > > > > to
> > >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going to be
> > >> > starting
> > >> > > > from
> > >> > > > > > > > scratch
> > >> > > > > > > > > > as
> > >> > > > > > > > > > > a
> > >> > > > > > > > > > > > > > fresh port, that person should set up the
> > >> project,
> > >> > > get
> > >> > > > > > > > everything
> > >> > > > > > > > > > > going
> > >> > > > > > > > > > > > > in
> > >> > > > > > > > > > > > > > source control, create the folder structure,
> > >> maybe
> > >> > > stub
> > >> > > > > out
> > >> > > > > > > > some
> > >> > > > > > > > > > > > classes,
> > >> > > > > > > > > > > > > > etc. Then divide and conquer with anyone
> > >> interested
> > >> > > in
> > >> > > > > > > > > > contributing,
> > >> > > > > > > > > > > > > > perhaps by namespace.
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > I like the idea of throwing the java code in
> > >> there
> > >> > so
> > >> > > > > it's
> > >> > > > > > > easy
> > >> > > > > > > > > to
> > >> > > > > > > > > > > > > > reference.
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > Again, I can work on Lucene.Net.Documents,
> > >> > > > > > > Lucene.Net.Analysis,
> > >> > > > > > > > > or
> > >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others, those are
> > >> just
> > >> > the
> > >> > > > > ones
> > >> > > > > > > I'm
> > >> > > > > > > > > most
> > >> > > > > > > > > > > > > > familiar with the inner workings. Tell me
> what
> > >> to
> > >> > do
> > >> > > > and
> > >> > > > > > I'll
> > >> > > > > > > > get
> > >> > > > > > > > > > > > started
> > >> > > > > > > > > > > > > > on my fork.
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > Paul Irwin
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott
> > Nasser
> > >> <
> > >> > > > > > > > > > > geobmx540@hotmail.com
> > >> > > > > > > > > > > > > > >wrote:
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > > > > Hey guys -
> > >> > > > > > > > > > > > > > > I know I've been MIA a little while. We
> > have a
> > >> > > board
> > >> > > > > > report
> > >> > > > > > > > due
> > >> > > > > > > > > > > soon
> > >> > > > > > > > > > > > -
> > >> > > > > > > > > > > > > I
> > >> > > > > > > > > > > > > > > think it prudent that we advise them that
> we
> > >> seem
> > >> > > to
> > >> > > > > have
> > >> > > > > > > > > stalled
> > >> > > > > > > > > > > > > > somewhat.
> > >> > > > > > > > > > > > > > > We've got a few low hanging items out of
> of
> > >> jira
> > >> > > and
> > >> > > > > have
> > >> > > > > > > > been
> > >> > > > > > > > > > > > > responsive
> > >> > > > > > > > > > > > > > > on the mailing list to community
> questions,
> > >> but I
> > >> > > > don't
> > >> > > > > > > think
> > >> > > > > > > > > > we've
> > >> > > > > > > > > > > > > done
> > >> > > > > > > > > > > > > > > anything to move forward with 4.0.
> > >> > > > > > > > > > > > > > > To that end - I'd like to *try* and start
> us
> > >> back
> > >> > > up
> > >> > > > > > moving
> > >> > > > > > > > > > > forward.
> > >> > > > > > > > > > > > > What
> > >> > > > > > > > > > > > > > > is the best way to accomplish this? If we
> > took
> > >> > the
> > >> > > > java
> > >> > > > > > > > lucene
> > >> > > > > > > > > > 4.0
> > >> > > > > > > > > > > > code
> > >> > > > > > > > > > > > > > and
> > >> > > > > > > > > > > > > > > committed that java to our branch and then
> > >> just
> > >> > let
> > >> > > > > > people
> > >> > > > > > > > pull
> > >> > > > > > > > > > > that
> > >> > > > > > > > > > > > > down
> > >> > > > > > > > > > > > > > > and being changing / modifying is that one
> > >> way to
> > >> > > > maybe
> > >> > > > > > > make
> > >> > > > > > > > > some
> > >> > > > > > > > > > > > > forward
> > >> > > > > > > > > > > > > > > progress?
> > >> > > > > > > > > > > > > > > ~P
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > --
> > >> > > > > > > > > > > > > --
> > >> > > > > > > > > > > > > Marcos Lima
> > >> > > > > > > > > > > > > Software Developer/Tech Lead
> > >> > > > > > > > > > > > > marcoslimagon@gmail.com
> > >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > --
> > >> > > > Marcos Lima
> > >> > > > Software Developer/Tech Lead
> > >> > > > marcoslimagon@gmail.com
> > >> > > > tel: +55 (19) 9798-9335
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> --
> > >> Marcos Lima
> > >> Software Developer/Tech Lead
> > >> marcoslimagon@gmail.com
> > >> tel: +55 (19) 9798-9335
> > >>
> > >
> > >
> >
>
Re: Lucene 4.0
Posted by Itamar Syn-Hershko <it...@code972.com>.
Paul, that's awesome. I will need some more time to go over this thread and
your work to give actual feedback, SUPER busy at the moment
On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pi...@feature23.com> wrote:
> All,
>
> My colleagues and I have made good progress on porting Lucene 4.3's core
> library before, during, and after the hackathon last week. We now only have
> some remaining items in Search, Index, and Codecs namespaces (plus a few
> other minor ones here and there). I expect to be done by the end of the
> weekend. Analysis, Documents, Store, Util (except some FST and Packed), and
> the root Codecs and Codecs.PerField namespaces are all now "done".
>
> Again, my goal is to only get a buildable, experimental build of Lucene.net
> with 4.3.0 (now 4.3.1) compatibility. We are intentionally not porting new
> javadoc comments or unit tests right now, due to the vast amount of code
> that needs to be written just to get it to compile. If this work ends up
> becoming a pull request, great, otherwise it should help accelerate a port
> of 4.3.x since the bulk of the work on core will already be done and
> contributors can use it as a reference. And again, we're taking the
> pragmatic approach of porting class-by-class, namespace-by-namespace, with
> the understanding that until we're done the project won't build.
>
> Once complete, I also will work on updating the Analyzers contrib module
> and porting the QueryParsers contrib module, which I feel should be
> included in the core NuGet package for Lucene.net as the core library is
> now (post-4.0) practically useless (or atleast not turn-key) without them.
> You can check out the code on my fork/branch here:
> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
> In particular, I'd like some feedback on my work on ByteBuffer,
> MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For the MMap
> support, I created a ByteBuffer subclass that uses .NET 4's
> MemoryMappedFile support which should emulate the Java nio stuff pretty
> well, but required some creative shuffling of the code to make it work due
> to lifecycle management.
>
> I'll update again this weekend or next week, when we should have wrapped up
> most of the main hacking on porting the core code.
>
> Paul
> On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com> wrote:
>
> > Marcos,
> >
> > That would be helpful. As far as I can tell, the 3.0 java code is only on
> > SVN here, before the lucene and solr projects were bundled together:
> > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> >
> > The SVN for 4.3 java is here:
> > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> > And the GitHub for 4.3 java is here:
> > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> >
> > My fork/branch of Lucene.net for the 4.3 port is here:
> > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> >
> > My fork is the "upstream" fork for my team members, and i'm remote
> merging
> > their changes in from their forks while they fetch/merge from mine to get
> > everyone else's changes, rather than using pull requests. James and I
> have
> > been working the past few days on the Util namespace ahead of tonight's
> > hackathon since that namespace is in common with the rest of the
> > namespaces. Tonight, we'll have at least 8 guys that I know of hacking on
> > porting 4.3, each with a different namespace or part of a namespace.
> Since
> > we're going class-by-class, namespace-by-namespace, the project does not
> > build as it is. Once we finish doing a translation of each file, then
> we'll
> > hammer out any remaining issues and get it to build again. I'm hoping
> that
> > we can get at least 75% done with Core tonight. Wish us luck!
> >
> > But one thing to keep in mind is it looks like much functionality has
> been
> > moved out of core into the contrib modules, especially around analysis,
> for
> > 4.0+. For example, there are no built-in analyzers in core anymore. So
> when
> > this is all done, we may want to include at least the analysis contrib
> > module in with the standard core NuGet package, because otherwise it's
> > practically useless unless you roll your own analyzer.
> >
> > Paul
> >
> >
> > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <marcoslimagon@gmail.com
> >wrote:
> >
> >> Hi everyone!
> >>
> >> Does someone know where can I find the 3.0.3 release from Lucene(java)?
> >>
> >> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0 and
> make
> >> the diff between then and get all changes between releases... I gonna
> >> publish it here soon. (If you think there is another important release,
> >> let
> >> me know)
> >>
> >> Paul, are you dealing (i`m not sure about this word, sorry) with 4.3.0
> >> port
> >> for .Net on github (last email)?
> >>
> >> See you,
> >>
> >>
> >> 2013/6/10 Paul Irwin <pi...@feature23.com>
> >>
> >> > Thanks for the discussion points, Michael.
> >> >
> >> > I would vote for not worrying about trying to achieve portable
> >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
> >> completed.
> >> > Otherwise it may delay the project and stall it further. That's just
> my
> >> > $0.02 based on my admittedly selfish need for 4.x features.
> >> >
> >> > I have started porting the changes from the core library (from the
> >> > java lucene_solr_4_3 branch) in my fork on github in a separate
> branch.
> >> > Since I need 4.3 ASAP, I am just going to keep going on my port until
> >> > there's changes to pull from upstream to work from. Also due to my
> time
> >> > constraints, I am not fully documenting new methods that I'm adding.
> >> But if
> >> > anyone wants to pull/copy/reference my changes while porting, that's
> >> > awesome. My branch currently does not build as I'm primarily going
> >> > class-by-class, starting with the util namespace. Once we get the ball
> >> > rolling on a community effort, I'll stop my rogue work and join in.
> But
> >> > hopefully my work will be useful to someone, if not as a pull request
> >> then
> >> > as a reference. I'm also going to be holding a hackathon this week
> with
> >> my
> >> > colleagues where we're all going to work on the port. I'm comparing
> >> files
> >> > and making changes as necessary, rather than starting from scratch. My
> >> > repo/branch is here:
> >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >> >
> >> > Paul
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> >> > mherndon@michaelherndon.com> wrote:
> >> >
> >> > > the guithub.com repo is a mirror to the git mirror that apache
> >> > maintains.
> >> > >
> >> > > The was some work at one time to move the official svn repository to
> >> > start
> >> > > using git one instead. Was that actually finalized or not?
> >> > >
> >> > > The Lucene.Net_4e (e for experimental) is an old branch to see what
> >> kind
> >> > of
> >> > > work was involved using a portable libraries project. Some of it can
> >> > still
> >> > > be used but will need to be validated against the current version of
> >> > Java's
> >> > > Lucene. It was also using .net 4.
> >> > >
> >> > > clean branch vs current. Its going to depend on what we support.
> >> If
> >> > you
> >> > > support windows mobile 8, win RT, then the current code in trunk
> will
> >> not
> >> > > compile against those versions of the framework which would a
> >> frustrating
> >> > > starting point, then you couldn't even run tests, which would make
> >> taking
> >> > > patches very difficult. Supporting those can almost mean larger
> gaps
> >> in
> >> > > design between Lucene.Net and its parent project.
> >> > >
> >> > > Also the structure has changed significantly between the branches
> and
> >> > the
> >> > > side of the code base of Lucene 4 is bigger, uses Java 6, and seems
> >> > > significantly different. That doesn't mean you can't cherry pick
> >> stuff
> >> > > from the other tags/branches that would still work as is. A clean
> >> branch
> >> > > would also make it easier to get our build / tool chain in order as
> >> you
> >> > can
> >> > > then do them incrementally versus having to do all the stuff that I
> >> did
> >> > for
> >> > > the 3x branch which saps energy and desire to code. It could also
> >> make
> >> > it
> >> > > easier to see which classes have been ported or not.
> >> > >
> >> > > The major downside to a clean branch is extra work it requires and
> the
> >> > > start up cost in time and energy of getting it in order, which can
> be
> >> > > daunting / intimidating and lower morale. And generally you want to
> >> use
> >> > > take your legacy code and refactor instead of in someways starting
> >> over.
> >> > >
> >> > > Are we going to port lucene 4 or 4.3 ? If so I can do something
> >> similar
> >> > > to
> >> > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> >> > > where it tracks what needs to get ported / what has been ported.
> >> > >
> >> > > What are we going to support in the next version?
> >> > >
> >> > > Who is going to work on the next version?
> >> > >
> >> > > What would make the most sense and what would invigorate the
> >> community to
> >> > > get involved more and lower the barrier to entry?
> >> > >
> >> > > I think those are the questions that would make a lot of the
> decisions
> >> > for
> >> > > us so that we can get back to work on lucene.net.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> marcoslimagon@gmail.com
> >> > > >wrote:
> >> > >
> >> > > > Regarding the new branch, I'm a rookie with ASF projects...
> >> > > >
> >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> >> > > > https://github.com/apache/lucene.net points to the same
> repository?
> >> > > (This
> >> > > > is new for me, pretty good) Which of them do you recommend (i'm
> used
> >> > with
> >> > > > SVN and its patterns).
> >> > > >
> >> > > > I'm checking the subversion right now.
> >> > > >
> >> > > > I can see the branches/Lucene.Net_4e. I think this is a old
> branch,
> >> i`m
> >> > > not
> >> > > > sure about its current status.
> >> > > >
> >> > > > Will we wipe the current solution from /trunk and start a new one?
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
> >> > > >
> >> > > > > We may be forced to start with a clean/empty branch if people
> >> still
> >> > > want
> >> > > > to
> >> > > > > attempt supporting lucene.net for mobile devices, win RT, etc.
> >> The
> >> > are
> >> > > > > many
> >> > > > > classes that Lucene.net uses from the full framework that would
> >> not
> >> > be
> >> > > > > accessible in other versions of the .NET Framework. It also
> might
> >> > > > require
> >> > > > > a design that differs even more from its parent project.
> >> > > > >
> >> > > > > It might be wise to poll what users most desire in the next
> >> version
> >> > > > through
> >> > > > > jira or user voice.
> >> > > > >
> >> > > > >
> >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> >> > itamar@code972.com
> >> > > > > >wrote:
> >> > > > >
> >> > > > > > inline
> >> > > > > >
> >> > > > > >
> >> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
> >> pirwin@feature23.com>
> >> > > > wrote:
> >> > > > > >
> >> > > > > > > Ah, I gotcha. Still getting used to git, I've been a TFS guy
> >> for
> >> > so
> >> > > > > long
> >> > > > > > > :-)
> >> > > > > > >
> >> > > > > > > So to recap, the branch_3x will be used for any patches or
> >> > anything
> >> > > > to
> >> > > > > > the
> >> > > > > > > current 3.0.3 release, while trunk is what we will branch
> from
> >> > for
> >> > > 4x
> >> > > > > > dev.
> >> > > > > > > Correct?
> >> > > > > > >
> >> > > > > >
> >> > > > > > Yes - we can branch from it for 3.6 development if anyone will
> >> be
> >> > > > > > interested in that
> >> > > > > >
> >> > > > > >
> >> > > > > > >
> >> > > > > > > Thanks for pushing the Version.cs. What's the deal with the
> >> > github
> >> > > > > sync?
> >> > > > > > > Who could diagnose that?
> >> > > > > > >
> >> > > > > >
> >> > > > > > Not sure, Apache Infra, basically. Just use the apache repo
> for
> >> now
> >> > > > while
> >> > > > > > we get that sorted out.
> >> > > > > >
> >> > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> >> > > > itamar@code972.com
> >> > > > > > > >wrote:
> >> > > > > > >
> >> > > > > > > > Ok, haven't noticed that branch. Just use it then for 3.x
> >> > > > > development.
> >> > > > > > > WRT
> >> > > > > > > > v4, yeah - just fork the repo and work on whatever branch.
> >> When
> >> > > you
> >> > > > > > send
> >> > > > > > > us
> >> > > > > > > > PRs we will merge either to master or to a dedicated repo.
> >> For
> >> > > now
> >> > > > it
> >> > > > > > > > doesn't really matter, thats the beauty of git.
> >> > > > > > > >
> >> > > > > > > > I pushed a new Version.cs file, you should see it on the
> >> apache
> >> > > > > servers
> >> > > > > > > > (github sync seems to be off)
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> >> > > pirwin@feature23.com>
> >> > > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3 version
> >> of
> >> > the
> >> > > > > > > Analysis
> >> > > > > > > > > namespace.
> >> > > > > > > > >
> >> > > > > > > > > Not sure the checkout command is what you intended --
> you
> >> > might
> >> > > > > have
> >> > > > > > > > meant
> >> > > > > > > > > trunk instead of master, and that would create a new
> "3x"
> >> > > branch,
> >> > > > > > when
> >> > > > > > > > > there's already a "branch_3x" and that would be
> >> misnamed...
> >> > so
> >> > > > > maybe
> >> > > > > > > > > checkout -b branch_4x trunk and start there aiming for
> >> lucene
> >> > > > 4.3.x
> >> > > > > > > > > compatibility?
> >> > > > > > > > >
> >> > > > > > > > > Also, does someone with commit rights to the upstream
> >> want to
> >> > > > > create
> >> > > > > > > the
> >> > > > > > > > > necessary Version.cs entries, so that we're not all
> >> trying to
> >> > > > > create
> >> > > > > > > them
> >> > > > > > > > > and dealing with a merge?
> >> > > > > > > > >
> >> > > > > > > > > Paul
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> >> > > > > > itamar@code972.com
> >> > > > > > > > > >wrote:
> >> > > > > > > > >
> >> > > > > > > > > > Unless people here have a specific reason to use
> 3.6.2 I
> >> > > would
> >> > > > > > highly
> >> > > > > > > > > > recommed putting all the efforts we can towards v4
> >> > otherwise
> >> > > we
> >> > > > > > will
> >> > > > > > > > > never
> >> > > > > > > > > > make it...
> >> > > > > > > > > >
> >> > > > > > > > > > Fork the repo from apache servers or github (same
> repo,
> >> > > > different
> >> > > > > > > > > remotes)
> >> > > > > > > > > > and checkout -b 3x -t origin/master , that should work
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> >> > > > > pirwin@feature23.com>
> >> > > > > > > > > wrote:
> >> > > > > > > > > >
> >> > > > > > > > > > > Itamar,
> >> > > > > > > > > > >
> >> > > > > > > > > > > I agree that from scratch is not the best way to do
> >> it, I
> >> > > > just
> >> > > > > > > > thought
> >> > > > > > > > > > that
> >> > > > > > > > > > > was the "decision" that was made from the discussion
> >> > > > previously
> >> > > > > > for
> >> > > > > > > > the
> >> > > > > > > > > > 4.x
> >> > > > > > > > > > > work. An incremental approach will be much better.
> >> > > > > > > > > > >
> >> > > > > > > > > > > I've created a branch of the branch_3x branch on my
> >> fork
> >> > > and
> >> > > > > will
> >> > > > > > > > begin
> >> > > > > > > > > > > working on bringing the Analysis namespace up to
> >> speed to
> >> > > > > 3.6.2.
> >> > > > > > If
> >> > > > > > > > > > anyone
> >> > > > > > > > > > > wants to pull it or just reuse parts once I'm done,
> >> have
> >> > at
> >> > > > it.
> >> > > > > > > > > > >
> >> > > > > > > > > > > If I shouldn't have branched off the branch_3x
> branch,
> >> > > please
> >> > > > > let
> >> > > > > > > me
> >> > > > > > > > > know
> >> > > > > > > > > > > what I should have branched from (trunk?)
> >> > > > > > > > > > >
> >> > > > > > > > > > > Paul
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <
> >> > > > > > > > itamar@code972.com
> >> > > > > > > > > > > >wrote:
> >> > > > > > > > > > >
> >> > > > > > > > > > > > Thanks Prescott for bringing this up again :)
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Paul, the problem is no one can really know what
> it
> >> > would
> >> > > > > take
> >> > > > > > > > until
> >> > > > > > > > > > they
> >> > > > > > > > > > > > have deep dived into the work, and even then
> >> decisions
> >> > > > could
> >> > > > > > and
> >> > > > > > > > will
> >> > > > > > > > > > > > change. I will strongly advise against starting
> from
> >> > > > scratch,
> >> > > > > > > > > although
> >> > > > > > > > > > I
> >> > > > > > > > > > > do
> >> > > > > > > > > > > > think a lot in the current structure should
> change,
> >> but
> >> > > its
> >> > > > > > going
> >> > > > > > > > to
> >> > > > > > > > > be
> >> > > > > > > > > > > > much easier to change it in place, refactoring
> where
> >> > > > needed,
> >> > > > > > than
> >> > > > > > > > > > > starting
> >> > > > > > > > > > > > all over again. Once we kicked this off I
> personally
> >> > will
> >> > > > be
> >> > > > > > > happy
> >> > > > > > > > > with
> >> > > > > > > > > > > you
> >> > > > > > > > > > > > taking the analysis part of Lucene and porting it,
> >> its
> >> > > > pretty
> >> > > > > > > much
> >> > > > > > > > > self
> >> > > > > > > > > > > > contained.
> >> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a fork and
> >> send
> >> > > us
> >> > > > > PRs,
> >> > > > > > > its
> >> > > > > > > > > > much
> >> > > > > > > > > > > > more straight forward than the v4 upgrade
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Marcos, porting class by class is the fastest way
> >> to do
> >> > > > this,
> >> > > > > > we
> >> > > > > > > > can
> >> > > > > > > > > > then
> >> > > > > > > > > > > > concentrate on .NETifying and optimizing using
> .NET
> >> > > > > constructs.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > That said, I think the way to go is create a
> branch
> >> out
> >> > > of
> >> > > > > the
> >> > > > > > > > > current
> >> > > > > > > > > > > git
> >> > > > > > > > > > > > master HEAD and label it "3.x", and start working
> on
> >> > > master
> >> > > > > > > > towards a
> >> > > > > > > > > > 4.3
> >> > > > > > > > > > > > compatible version. The actual port should be
> using
> >> a
> >> > > > process
> >> > > > > > > that
> >> > > > > > > > > > > ensures
> >> > > > > > > > > > > > all Java classes are ported with their tests, and
> >> that
> >> > > > those
> >> > > > > > > tests
> >> > > > > > > > > > pass -
> >> > > > > > > > > > > > but I'm against committing any Java code to our
> >> > > > repositories.
> >> > > > > > The
> >> > > > > > > > > > process
> >> > > > > > > > > > > > should probably be working on classes in some
> order
> >> > > > > > > > (alphabetically,
> >> > > > > > > > > or
> >> > > > > > > > > > > > core classes first) and getting each class to
> >> compile
> >> > > > before
> >> > > > > > > moving
> >> > > > > > > > > > > > forward. I don't mind about the project not being
> >> > > > compilable
> >> > > > > > for
> >> > > > > > > a
> >> > > > > > > > > > month
> >> > > > > > > > > > > or
> >> > > > > > > > > > > > two.
> >> > > > > > > > > > > > Once this is done a process of .NETifying and
> >> proofing
> >> > > the
> >> > > > > code
> >> > > > > > > can
> >> > > > > > > > > be
> >> > > > > > > > > > > > started, at which point we will already have a
> >> working
> >> > v4
> >> > > > > > version
> >> > > > > > > > so
> >> > > > > > > > > it
> >> > > > > > > > > > > > will be easier to keep up with the Java project.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > The first step IMO is to stabilize the test suite
> so
> >> > > tests
> >> > > > > > could
> >> > > > > > > > more
> >> > > > > > > > > > or
> >> > > > > > > > > > > > less be copied and pasted (e.g. implementing
> >> Java-like
> >> > > > > > > assertEquals
> >> > > > > > > > > > > methods
> >> > > > > > > > > > > > etc; I find xUnit to be much easier to work with
> >> than
> >> > > > > NUnit). I
> >> > > > > > > > > already
> >> > > > > > > > > > > did
> >> > > > > > > > > > > > some work there but there's still a lot to do.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Unfortunately I can't dedicate time myself at this
> >> > point,
> >> > > > > but I
> >> > > > > > > > > should
> >> > > > > > > > > > be
> >> > > > > > > > > > > > back in business in August, at which point I can
> >> > dedicate
> >> > > > > > several
> >> > > > > > > > > > hours a
> >> > > > > > > > > > > > week. Until then I'll be happy to watch closely
> and
> >> > even
> >> > > > > > > coordinate
> >> > > > > > > > > the
> >> > > > > > > > > > > > work to some extent.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> >> > > > > > > > > marcoslimagon@gmail.com
> >> > > > > > > > > > > > >wrote:
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > > It really sounds good to me, this is a kick
> start
> >> > =). I
> >> > > > > > haven't
> >> > > > > > > > > > > > contributed
> >> > > > > > > > > > > > > anything
> >> > > > > > > > > > > > > yet, but I would like to help you all to get
> this
> >> job
> >> > > > done.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > I'm completely agree with Paul and Prescott.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > I know that there is a high commitment for keep
> >> the
> >> > > > > > > > > > retrocompatibility
> >> > > > > > > > > > > on
> >> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big changes
> >> every
> >> > > > > release?
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > Is the Lucene.Net a port from a stable version
> >> from a
> >> > > > > Lucene
> >> > > > > > > > > version,
> >> > > > > > > > > > > > > right? If the Lucene API gets only minor changes
> >> > every
> >> > > > > stable
> >> > > > > > > > > release
> >> > > > > > > > > > > (or
> >> > > > > > > > > > > > > keep most of its source-code), we could compare
> >> the
> >> > > > > versions,
> >> > > > > > > > check
> >> > > > > > > > > > the
> >> > > > > > > > > > > > > differences and bring them to Lucene.Net.
> Again, I
> >> > > > haven't
> >> > > > > > > > > > contributed
> >> > > > > > > > > > > > with
> >> > > > > > > > > > > > > yet, so I don't know how it is (just an idea).
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > What's your approach for implement simple
> >> performance
> >> > > > > > > > improvements
> >> > > > > > > > > > > > (without
> >> > > > > > > > > > > > > adding references or changing methods
> signatures)?
> >> > Does
> >> > > > it
> >> > > > > > > could
> >> > > > > > > > be
> >> > > > > > > > > > > done,
> >> > > > > > > > > > > > > or "follow the java version only"?
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > > This is just an "outsider" suggestion as I
> >> haven't
> >> > > > > > > contributed
> >> > > > > > > > > > > anything
> >> > > > > > > > > > > > > > yet, although I will definitely help with the
> >> 4.x
> >> > > work
> >> > > > > as I
> >> > > > > > > > have
> >> > > > > > > > > a
> >> > > > > > > > > > > > vested
> >> > > > > > > > > > > > > > interest in seeing that get completed. I think
> >> > there
> >> > > > > should
> >> > > > > > > be
> >> > > > > > > > > one
> >> > > > > > > > > > > > person
> >> > > > > > > > > > > > > > (or perhaps two) guiding what the structure
> and
> >> > > > workflow
> >> > > > > > will
> >> > > > > > > > > look
> >> > > > > > > > > > > like
> >> > > > > > > > > > > > > to
> >> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going to be
> >> > starting
> >> > > > from
> >> > > > > > > > scratch
> >> > > > > > > > > > as
> >> > > > > > > > > > > a
> >> > > > > > > > > > > > > > fresh port, that person should set up the
> >> project,
> >> > > get
> >> > > > > > > > everything
> >> > > > > > > > > > > going
> >> > > > > > > > > > > > > in
> >> > > > > > > > > > > > > > source control, create the folder structure,
> >> maybe
> >> > > stub
> >> > > > > out
> >> > > > > > > > some
> >> > > > > > > > > > > > classes,
> >> > > > > > > > > > > > > > etc. Then divide and conquer with anyone
> >> interested
> >> > > in
> >> > > > > > > > > > contributing,
> >> > > > > > > > > > > > > > perhaps by namespace.
> >> > > > > > > > > > > > > >
> >> > > > > > > > > > > > > > I like the idea of throwing the java code in
> >> there
> >> > so
> >> > > > > it's
> >> > > > > > > easy
> >> > > > > > > > > to
> >> > > > > > > > > > > > > > reference.
> >> > > > > > > > > > > > > >
> >> > > > > > > > > > > > > > Again, I can work on Lucene.Net.Documents,
> >> > > > > > > Lucene.Net.Analysis,
> >> > > > > > > > > or
> >> > > > > > > > > > > > > > Lucene.Net.Store -- or any others, those are
> >> just
> >> > the
> >> > > > > ones
> >> > > > > > > I'm
> >> > > > > > > > > most
> >> > > > > > > > > > > > > > familiar with the inner workings. Tell me what
> >> to
> >> > do
> >> > > > and
> >> > > > > > I'll
> >> > > > > > > > get
> >> > > > > > > > > > > > started
> >> > > > > > > > > > > > > > on my fork.
> >> > > > > > > > > > > > > >
> >> > > > > > > > > > > > > > Paul Irwin
> >> > > > > > > > > > > > > >
> >> > > > > > > > > > > > > >
> >> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott
> Nasser
> >> <
> >> > > > > > > > > > > geobmx540@hotmail.com
> >> > > > > > > > > > > > > > >wrote:
> >> > > > > > > > > > > > > >
> >> > > > > > > > > > > > > > > Hey guys -
> >> > > > > > > > > > > > > > > I know I've been MIA a little while. We
> have a
> >> > > board
> >> > > > > > report
> >> > > > > > > > due
> >> > > > > > > > > > > soon
> >> > > > > > > > > > > > -
> >> > > > > > > > > > > > > I
> >> > > > > > > > > > > > > > > think it prudent that we advise them that we
> >> seem
> >> > > to
> >> > > > > have
> >> > > > > > > > > stalled
> >> > > > > > > > > > > > > > somewhat.
> >> > > > > > > > > > > > > > > We've got a few low hanging items out of of
> >> jira
> >> > > and
> >> > > > > have
> >> > > > > > > > been
> >> > > > > > > > > > > > > responsive
> >> > > > > > > > > > > > > > > on the mailing list to community questions,
> >> but I
> >> > > > don't
> >> > > > > > > think
> >> > > > > > > > > > we've
> >> > > > > > > > > > > > > done
> >> > > > > > > > > > > > > > > anything to move forward with 4.0.
> >> > > > > > > > > > > > > > > To that end - I'd like to *try* and start us
> >> back
> >> > > up
> >> > > > > > moving
> >> > > > > > > > > > > forward.
> >> > > > > > > > > > > > > What
> >> > > > > > > > > > > > > > > is the best way to accomplish this? If we
> took
> >> > the
> >> > > > java
> >> > > > > > > > lucene
> >> > > > > > > > > > 4.0
> >> > > > > > > > > > > > code
> >> > > > > > > > > > > > > > and
> >> > > > > > > > > > > > > > > committed that java to our branch and then
> >> just
> >> > let
> >> > > > > > people
> >> > > > > > > > pull
> >> > > > > > > > > > > that
> >> > > > > > > > > > > > > down
> >> > > > > > > > > > > > > > > and being changing / modifying is that one
> >> way to
> >> > > > maybe
> >> > > > > > > make
> >> > > > > > > > > some
> >> > > > > > > > > > > > > forward
> >> > > > > > > > > > > > > > > progress?
> >> > > > > > > > > > > > > > > ~P
> >> > > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > --
> >> > > > > > > > > > > > > --
> >> > > > > > > > > > > > > Marcos Lima
> >> > > > > > > > > > > > > Software Developer/Tech Lead
> >> > > > > > > > > > > > > marcoslimagon@gmail.com
> >> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > --
> >> > > > Marcos Lima
> >> > > > Software Developer/Tech Lead
> >> > > > marcoslimagon@gmail.com
> >> > > > tel: +55 (19) 9798-9335
> >> > > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> --
> >> Marcos Lima
> >> Software Developer/Tech Lead
> >> marcoslimagon@gmail.com
> >> tel: +55 (19) 9798-9335
> >>
> >
> >
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
All,
My colleagues and I have made good progress on porting Lucene 4.3's core
library before, during, and after the hackathon last week. We now only have
some remaining items in Search, Index, and Codecs namespaces (plus a few
other minor ones here and there). I expect to be done by the end of the
weekend. Analysis, Documents, Store, Util (except some FST and Packed), and
the root Codecs and Codecs.PerField namespaces are all now "done".
Again, my goal is to only get a buildable, experimental build of Lucene.net
with 4.3.0 (now 4.3.1) compatibility. We are intentionally not porting new
javadoc comments or unit tests right now, due to the vast amount of code
that needs to be written just to get it to compile. If this work ends up
becoming a pull request, great, otherwise it should help accelerate a port
of 4.3.x since the bulk of the work on core will already be done and
contributors can use it as a reference. And again, we're taking the
pragmatic approach of porting class-by-class, namespace-by-namespace, with
the understanding that until we're done the project won't build.
Once complete, I also will work on updating the Analyzers contrib module
and porting the QueryParsers contrib module, which I feel should be
included in the core NuGet package for Lucene.net as the core library is
now (post-4.0) practically useless (or atleast not turn-key) without them.
You can check out the code on my fork/branch here:
https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
In particular, I'd like some feedback on my work on ByteBuffer,
MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For the MMap
support, I created a ByteBuffer subclass that uses .NET 4's
MemoryMappedFile support which should emulate the Java nio stuff pretty
well, but required some creative shuffling of the code to make it work due
to lifecycle management.
I'll update again this weekend or next week, when we should have wrapped up
most of the main hacking on porting the core code.
Paul
On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pi...@feature23.com> wrote:
> Marcos,
>
> That would be helpful. As far as I can tell, the 3.0 java code is only on
> SVN here, before the lucene and solr projects were bundled together:
> http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
>
> The SVN for 4.3 java is here:
> http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> And the GitHub for 4.3 java is here:
> https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
>
> My fork/branch of Lucene.net for the 4.3 port is here:
> https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
>
> My fork is the "upstream" fork for my team members, and i'm remote merging
> their changes in from their forks while they fetch/merge from mine to get
> everyone else's changes, rather than using pull requests. James and I have
> been working the past few days on the Util namespace ahead of tonight's
> hackathon since that namespace is in common with the rest of the
> namespaces. Tonight, we'll have at least 8 guys that I know of hacking on
> porting 4.3, each with a different namespace or part of a namespace. Since
> we're going class-by-class, namespace-by-namespace, the project does not
> build as it is. Once we finish doing a translation of each file, then we'll
> hammer out any remaining issues and get it to build again. I'm hoping that
> we can get at least 75% done with Core tonight. Wish us luck!
>
> But one thing to keep in mind is it looks like much functionality has been
> moved out of core into the contrib modules, especially around analysis, for
> 4.0+. For example, there are no built-in analyzers in core anymore. So when
> this is all done, we may want to include at least the analysis contrib
> module in with the standard core NuGet package, because otherwise it's
> practically useless unless you roll your own analyzer.
>
> Paul
>
>
> On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <ma...@gmail.com>wrote:
>
>> Hi everyone!
>>
>> Does someone know where can I find the 3.0.3 release from Lucene(java)?
>>
>> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0 and make
>> the diff between then and get all changes between releases... I gonna
>> publish it here soon. (If you think there is another important release,
>> let
>> me know)
>>
>> Paul, are you dealing (i`m not sure about this word, sorry) with 4.3.0
>> port
>> for .Net on github (last email)?
>>
>> See you,
>>
>>
>> 2013/6/10 Paul Irwin <pi...@feature23.com>
>>
>> > Thanks for the discussion points, Michael.
>> >
>> > I would vote for not worrying about trying to achieve portable
>> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
>> completed.
>> > Otherwise it may delay the project and stall it further. That's just my
>> > $0.02 based on my admittedly selfish need for 4.x features.
>> >
>> > I have started porting the changes from the core library (from the
>> > java lucene_solr_4_3 branch) in my fork on github in a separate branch.
>> > Since I need 4.3 ASAP, I am just going to keep going on my port until
>> > there's changes to pull from upstream to work from. Also due to my time
>> > constraints, I am not fully documenting new methods that I'm adding.
>> But if
>> > anyone wants to pull/copy/reference my changes while porting, that's
>> > awesome. My branch currently does not build as I'm primarily going
>> > class-by-class, starting with the util namespace. Once we get the ball
>> > rolling on a community effort, I'll stop my rogue work and join in. But
>> > hopefully my work will be useful to someone, if not as a pull request
>> then
>> > as a reference. I'm also going to be holding a hackathon this week with
>> my
>> > colleagues where we're all going to work on the port. I'm comparing
>> files
>> > and making changes as necessary, rather than starting from scratch. My
>> > repo/branch is here:
>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>> >
>> > Paul
>> >
>> >
>> >
>> >
>> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
>> > mherndon@michaelherndon.com> wrote:
>> >
>> > > the guithub.com repo is a mirror to the git mirror that apache
>> > maintains.
>> > >
>> > > The was some work at one time to move the official svn repository to
>> > start
>> > > using git one instead. Was that actually finalized or not?
>> > >
>> > > The Lucene.Net_4e (e for experimental) is an old branch to see what
>> kind
>> > of
>> > > work was involved using a portable libraries project. Some of it can
>> > still
>> > > be used but will need to be validated against the current version of
>> > Java's
>> > > Lucene. It was also using .net 4.
>> > >
>> > > clean branch vs current. Its going to depend on what we support.
>> If
>> > you
>> > > support windows mobile 8, win RT, then the current code in trunk will
>> not
>> > > compile against those versions of the framework which would a
>> frustrating
>> > > starting point, then you couldn't even run tests, which would make
>> taking
>> > > patches very difficult. Supporting those can almost mean larger gaps
>> in
>> > > design between Lucene.Net and its parent project.
>> > >
>> > > Also the structure has changed significantly between the branches and
>> > the
>> > > side of the code base of Lucene 4 is bigger, uses Java 6, and seems
>> > > significantly different. That doesn't mean you can't cherry pick
>> stuff
>> > > from the other tags/branches that would still work as is. A clean
>> branch
>> > > would also make it easier to get our build / tool chain in order as
>> you
>> > can
>> > > then do them incrementally versus having to do all the stuff that I
>> did
>> > for
>> > > the 3x branch which saps energy and desire to code. It could also
>> make
>> > it
>> > > easier to see which classes have been ported or not.
>> > >
>> > > The major downside to a clean branch is extra work it requires and the
>> > > start up cost in time and energy of getting it in order, which can be
>> > > daunting / intimidating and lower morale. And generally you want to
>> use
>> > > take your legacy code and refactor instead of in someways starting
>> over.
>> > >
>> > > Are we going to port lucene 4 or 4.3 ? If so I can do something
>> similar
>> > > to
>> > >
>> > >
>> >
>> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
>> > > where it tracks what needs to get ported / what has been ported.
>> > >
>> > > What are we going to support in the next version?
>> > >
>> > > Who is going to work on the next version?
>> > >
>> > > What would make the most sense and what would invigorate the
>> community to
>> > > get involved more and lower the barrier to entry?
>> > >
>> > > I think those are the questions that would make a lot of the decisions
>> > for
>> > > us so that we can get back to work on lucene.net.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <marcoslimagon@gmail.com
>> > > >wrote:
>> > >
>> > > > Regarding the new branch, I'm a rookie with ASF projects...
>> > > >
>> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
>> > > > https://github.com/apache/lucene.net points to the same repository?
>> > > (This
>> > > > is new for me, pretty good) Which of them do you recommend (i'm used
>> > with
>> > > > SVN and its patterns).
>> > > >
>> > > > I'm checking the subversion right now.
>> > > >
>> > > > I can see the branches/Lucene.Net_4e. I think this is a old branch,
>> i`m
>> > > not
>> > > > sure about its current status.
>> > > >
>> > > > Will we wipe the current solution from /trunk and start a new one?
>> > > >
>> > > > Thanks,
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
>> > > >
>> > > > > We may be forced to start with a clean/empty branch if people
>> still
>> > > want
>> > > > to
>> > > > > attempt supporting lucene.net for mobile devices, win RT, etc.
>> The
>> > are
>> > > > > many
>> > > > > classes that Lucene.net uses from the full framework that would
>> not
>> > be
>> > > > > accessible in other versions of the .NET Framework. It also might
>> > > > require
>> > > > > a design that differs even more from its parent project.
>> > > > >
>> > > > > It might be wise to poll what users most desire in the next
>> version
>> > > > through
>> > > > > jira or user voice.
>> > > > >
>> > > > >
>> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
>> > itamar@code972.com
>> > > > > >wrote:
>> > > > >
>> > > > > > inline
>> > > > > >
>> > > > > >
>> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <
>> pirwin@feature23.com>
>> > > > wrote:
>> > > > > >
>> > > > > > > Ah, I gotcha. Still getting used to git, I've been a TFS guy
>> for
>> > so
>> > > > > long
>> > > > > > > :-)
>> > > > > > >
>> > > > > > > So to recap, the branch_3x will be used for any patches or
>> > anything
>> > > > to
>> > > > > > the
>> > > > > > > current 3.0.3 release, while trunk is what we will branch from
>> > for
>> > > 4x
>> > > > > > dev.
>> > > > > > > Correct?
>> > > > > > >
>> > > > > >
>> > > > > > Yes - we can branch from it for 3.6 development if anyone will
>> be
>> > > > > > interested in that
>> > > > > >
>> > > > > >
>> > > > > > >
>> > > > > > > Thanks for pushing the Version.cs. What's the deal with the
>> > github
>> > > > > sync?
>> > > > > > > Who could diagnose that?
>> > > > > > >
>> > > > > >
>> > > > > > Not sure, Apache Infra, basically. Just use the apache repo for
>> now
>> > > > while
>> > > > > > we get that sorted out.
>> > > > > >
>> > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
>> > > > itamar@code972.com
>> > > > > > > >wrote:
>> > > > > > >
>> > > > > > > > Ok, haven't noticed that branch. Just use it then for 3.x
>> > > > > development.
>> > > > > > > WRT
>> > > > > > > > v4, yeah - just fork the repo and work on whatever branch.
>> When
>> > > you
>> > > > > > send
>> > > > > > > us
>> > > > > > > > PRs we will merge either to master or to a dedicated repo.
>> For
>> > > now
>> > > > it
>> > > > > > > > doesn't really matter, thats the beauty of git.
>> > > > > > > >
>> > > > > > > > I pushed a new Version.cs file, you should see it on the
>> apache
>> > > > > servers
>> > > > > > > > (github sync seems to be off)
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
>> > > pirwin@feature23.com>
>> > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3 version
>> of
>> > the
>> > > > > > > Analysis
>> > > > > > > > > namespace.
>> > > > > > > > >
>> > > > > > > > > Not sure the checkout command is what you intended -- you
>> > might
>> > > > > have
>> > > > > > > > meant
>> > > > > > > > > trunk instead of master, and that would create a new "3x"
>> > > branch,
>> > > > > > when
>> > > > > > > > > there's already a "branch_3x" and that would be
>> misnamed...
>> > so
>> > > > > maybe
>> > > > > > > > > checkout -b branch_4x trunk and start there aiming for
>> lucene
>> > > > 4.3.x
>> > > > > > > > > compatibility?
>> > > > > > > > >
>> > > > > > > > > Also, does someone with commit rights to the upstream
>> want to
>> > > > > create
>> > > > > > > the
>> > > > > > > > > necessary Version.cs entries, so that we're not all
>> trying to
>> > > > > create
>> > > > > > > them
>> > > > > > > > > and dealing with a merge?
>> > > > > > > > >
>> > > > > > > > > Paul
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
>> > > > > > itamar@code972.com
>> > > > > > > > > >wrote:
>> > > > > > > > >
>> > > > > > > > > > Unless people here have a specific reason to use 3.6.2 I
>> > > would
>> > > > > > highly
>> > > > > > > > > > recommed putting all the efforts we can towards v4
>> > otherwise
>> > > we
>> > > > > > will
>> > > > > > > > > never
>> > > > > > > > > > make it...
>> > > > > > > > > >
>> > > > > > > > > > Fork the repo from apache servers or github (same repo,
>> > > > different
>> > > > > > > > > remotes)
>> > > > > > > > > > and checkout -b 3x -t origin/master , that should work
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
>> > > > > pirwin@feature23.com>
>> > > > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > > Itamar,
>> > > > > > > > > > >
>> > > > > > > > > > > I agree that from scratch is not the best way to do
>> it, I
>> > > > just
>> > > > > > > > thought
>> > > > > > > > > > that
>> > > > > > > > > > > was the "decision" that was made from the discussion
>> > > > previously
>> > > > > > for
>> > > > > > > > the
>> > > > > > > > > > 4.x
>> > > > > > > > > > > work. An incremental approach will be much better.
>> > > > > > > > > > >
>> > > > > > > > > > > I've created a branch of the branch_3x branch on my
>> fork
>> > > and
>> > > > > will
>> > > > > > > > begin
>> > > > > > > > > > > working on bringing the Analysis namespace up to
>> speed to
>> > > > > 3.6.2.
>> > > > > > If
>> > > > > > > > > > anyone
>> > > > > > > > > > > wants to pull it or just reuse parts once I'm done,
>> have
>> > at
>> > > > it.
>> > > > > > > > > > >
>> > > > > > > > > > > If I shouldn't have branched off the branch_3x branch,
>> > > please
>> > > > > let
>> > > > > > > me
>> > > > > > > > > know
>> > > > > > > > > > > what I should have branched from (trunk?)
>> > > > > > > > > > >
>> > > > > > > > > > > Paul
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <
>> > > > > > > > itamar@code972.com
>> > > > > > > > > > > >wrote:
>> > > > > > > > > > >
>> > > > > > > > > > > > Thanks Prescott for bringing this up again :)
>> > > > > > > > > > > >
>> > > > > > > > > > > > Paul, the problem is no one can really know what it
>> > would
>> > > > > take
>> > > > > > > > until
>> > > > > > > > > > they
>> > > > > > > > > > > > have deep dived into the work, and even then
>> decisions
>> > > > could
>> > > > > > and
>> > > > > > > > will
>> > > > > > > > > > > > change. I will strongly advise against starting from
>> > > > scratch,
>> > > > > > > > > although
>> > > > > > > > > > I
>> > > > > > > > > > > do
>> > > > > > > > > > > > think a lot in the current structure should change,
>> but
>> > > its
>> > > > > > going
>> > > > > > > > to
>> > > > > > > > > be
>> > > > > > > > > > > > much easier to change it in place, refactoring where
>> > > > needed,
>> > > > > > than
>> > > > > > > > > > > starting
>> > > > > > > > > > > > all over again. Once we kicked this off I personally
>> > will
>> > > > be
>> > > > > > > happy
>> > > > > > > > > with
>> > > > > > > > > > > you
>> > > > > > > > > > > > taking the analysis part of Lucene and porting it,
>> its
>> > > > pretty
>> > > > > > > much
>> > > > > > > > > self
>> > > > > > > > > > > > contained.
>> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a fork and
>> send
>> > > us
>> > > > > PRs,
>> > > > > > > its
>> > > > > > > > > > much
>> > > > > > > > > > > > more straight forward than the v4 upgrade
>> > > > > > > > > > > >
>> > > > > > > > > > > > Marcos, porting class by class is the fastest way
>> to do
>> > > > this,
>> > > > > > we
>> > > > > > > > can
>> > > > > > > > > > then
>> > > > > > > > > > > > concentrate on .NETifying and optimizing using .NET
>> > > > > constructs.
>> > > > > > > > > > > >
>> > > > > > > > > > > > That said, I think the way to go is create a branch
>> out
>> > > of
>> > > > > the
>> > > > > > > > > current
>> > > > > > > > > > > git
>> > > > > > > > > > > > master HEAD and label it "3.x", and start working on
>> > > master
>> > > > > > > > towards a
>> > > > > > > > > > 4.3
>> > > > > > > > > > > > compatible version. The actual port should be using
>> a
>> > > > process
>> > > > > > > that
>> > > > > > > > > > > ensures
>> > > > > > > > > > > > all Java classes are ported with their tests, and
>> that
>> > > > those
>> > > > > > > tests
>> > > > > > > > > > pass -
>> > > > > > > > > > > > but I'm against committing any Java code to our
>> > > > repositories.
>> > > > > > The
>> > > > > > > > > > process
>> > > > > > > > > > > > should probably be working on classes in some order
>> > > > > > > > (alphabetically,
>> > > > > > > > > or
>> > > > > > > > > > > > core classes first) and getting each class to
>> compile
>> > > > before
>> > > > > > > moving
>> > > > > > > > > > > > forward. I don't mind about the project not being
>> > > > compilable
>> > > > > > for
>> > > > > > > a
>> > > > > > > > > > month
>> > > > > > > > > > > or
>> > > > > > > > > > > > two.
>> > > > > > > > > > > > Once this is done a process of .NETifying and
>> proofing
>> > > the
>> > > > > code
>> > > > > > > can
>> > > > > > > > > be
>> > > > > > > > > > > > started, at which point we will already have a
>> working
>> > v4
>> > > > > > version
>> > > > > > > > so
>> > > > > > > > > it
>> > > > > > > > > > > > will be easier to keep up with the Java project.
>> > > > > > > > > > > >
>> > > > > > > > > > > > The first step IMO is to stabilize the test suite so
>> > > tests
>> > > > > > could
>> > > > > > > > more
>> > > > > > > > > > or
>> > > > > > > > > > > > less be copied and pasted (e.g. implementing
>> Java-like
>> > > > > > > assertEquals
>> > > > > > > > > > > methods
>> > > > > > > > > > > > etc; I find xUnit to be much easier to work with
>> than
>> > > > > NUnit). I
>> > > > > > > > > already
>> > > > > > > > > > > did
>> > > > > > > > > > > > some work there but there's still a lot to do.
>> > > > > > > > > > > >
>> > > > > > > > > > > > Unfortunately I can't dedicate time myself at this
>> > point,
>> > > > > but I
>> > > > > > > > > should
>> > > > > > > > > > be
>> > > > > > > > > > > > back in business in August, at which point I can
>> > dedicate
>> > > > > > several
>> > > > > > > > > > hours a
>> > > > > > > > > > > > week. Until then I'll be happy to watch closely and
>> > even
>> > > > > > > coordinate
>> > > > > > > > > the
>> > > > > > > > > > > > work to some extent.
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
>> > > > > > > > > marcoslimagon@gmail.com
>> > > > > > > > > > > > >wrote:
>> > > > > > > > > > > >
>> > > > > > > > > > > > > It really sounds good to me, this is a kick start
>> > =). I
>> > > > > > haven't
>> > > > > > > > > > > > contributed
>> > > > > > > > > > > > > anything
>> > > > > > > > > > > > > yet, but I would like to help you all to get this
>> job
>> > > > done.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > I'm completely agree with Paul and Prescott.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > I know that there is a high commitment for keep
>> the
>> > > > > > > > > > retrocompatibility
>> > > > > > > > > > > on
>> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big changes
>> every
>> > > > > release?
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > Is the Lucene.Net a port from a stable version
>> from a
>> > > > > Lucene
>> > > > > > > > > version,
>> > > > > > > > > > > > > right? If the Lucene API gets only minor changes
>> > every
>> > > > > stable
>> > > > > > > > > release
>> > > > > > > > > > > (or
>> > > > > > > > > > > > > keep most of its source-code), we could compare
>> the
>> > > > > versions,
>> > > > > > > > check
>> > > > > > > > > > the
>> > > > > > > > > > > > > differences and bring them to Lucene.Net. Again, I
>> > > > haven't
>> > > > > > > > > > contributed
>> > > > > > > > > > > > with
>> > > > > > > > > > > > > yet, so I don't know how it is (just an idea).
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > What's your approach for implement simple
>> performance
>> > > > > > > > improvements
>> > > > > > > > > > > > (without
>> > > > > > > > > > > > > adding references or changing methods signatures)?
>> > Does
>> > > > it
>> > > > > > > could
>> > > > > > > > be
>> > > > > > > > > > > done,
>> > > > > > > > > > > > > or "follow the java version only"?
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > > This is just an "outsider" suggestion as I
>> haven't
>> > > > > > > contributed
>> > > > > > > > > > > anything
>> > > > > > > > > > > > > > yet, although I will definitely help with the
>> 4.x
>> > > work
>> > > > > as I
>> > > > > > > > have
>> > > > > > > > > a
>> > > > > > > > > > > > vested
>> > > > > > > > > > > > > > interest in seeing that get completed. I think
>> > there
>> > > > > should
>> > > > > > > be
>> > > > > > > > > one
>> > > > > > > > > > > > person
>> > > > > > > > > > > > > > (or perhaps two) guiding what the structure and
>> > > > workflow
>> > > > > > will
>> > > > > > > > > look
>> > > > > > > > > > > like
>> > > > > > > > > > > > > to
>> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going to be
>> > starting
>> > > > from
>> > > > > > > > scratch
>> > > > > > > > > > as
>> > > > > > > > > > > a
>> > > > > > > > > > > > > > fresh port, that person should set up the
>> project,
>> > > get
>> > > > > > > > everything
>> > > > > > > > > > > going
>> > > > > > > > > > > > > in
>> > > > > > > > > > > > > > source control, create the folder structure,
>> maybe
>> > > stub
>> > > > > out
>> > > > > > > > some
>> > > > > > > > > > > > classes,
>> > > > > > > > > > > > > > etc. Then divide and conquer with anyone
>> interested
>> > > in
>> > > > > > > > > > contributing,
>> > > > > > > > > > > > > > perhaps by namespace.
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > I like the idea of throwing the java code in
>> there
>> > so
>> > > > > it's
>> > > > > > > easy
>> > > > > > > > > to
>> > > > > > > > > > > > > > reference.
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > Again, I can work on Lucene.Net.Documents,
>> > > > > > > Lucene.Net.Analysis,
>> > > > > > > > > or
>> > > > > > > > > > > > > > Lucene.Net.Store -- or any others, those are
>> just
>> > the
>> > > > > ones
>> > > > > > > I'm
>> > > > > > > > > most
>> > > > > > > > > > > > > > familiar with the inner workings. Tell me what
>> to
>> > do
>> > > > and
>> > > > > > I'll
>> > > > > > > > get
>> > > > > > > > > > > > started
>> > > > > > > > > > > > > > on my fork.
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > Paul Irwin
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser
>> <
>> > > > > > > > > > > geobmx540@hotmail.com
>> > > > > > > > > > > > > > >wrote:
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > Hey guys -
>> > > > > > > > > > > > > > > I know I've been MIA a little while. We have a
>> > > board
>> > > > > > report
>> > > > > > > > due
>> > > > > > > > > > > soon
>> > > > > > > > > > > > -
>> > > > > > > > > > > > > I
>> > > > > > > > > > > > > > > think it prudent that we advise them that we
>> seem
>> > > to
>> > > > > have
>> > > > > > > > > stalled
>> > > > > > > > > > > > > > somewhat.
>> > > > > > > > > > > > > > > We've got a few low hanging items out of of
>> jira
>> > > and
>> > > > > have
>> > > > > > > > been
>> > > > > > > > > > > > > responsive
>> > > > > > > > > > > > > > > on the mailing list to community questions,
>> but I
>> > > > don't
>> > > > > > > think
>> > > > > > > > > > we've
>> > > > > > > > > > > > > done
>> > > > > > > > > > > > > > > anything to move forward with 4.0.
>> > > > > > > > > > > > > > > To that end - I'd like to *try* and start us
>> back
>> > > up
>> > > > > > moving
>> > > > > > > > > > > forward.
>> > > > > > > > > > > > > What
>> > > > > > > > > > > > > > > is the best way to accomplish this? If we took
>> > the
>> > > > java
>> > > > > > > > lucene
>> > > > > > > > > > 4.0
>> > > > > > > > > > > > code
>> > > > > > > > > > > > > > and
>> > > > > > > > > > > > > > > committed that java to our branch and then
>> just
>> > let
>> > > > > > people
>> > > > > > > > pull
>> > > > > > > > > > > that
>> > > > > > > > > > > > > down
>> > > > > > > > > > > > > > > and being changing / modifying is that one
>> way to
>> > > > maybe
>> > > > > > > make
>> > > > > > > > > some
>> > > > > > > > > > > > > forward
>> > > > > > > > > > > > > > > progress?
>> > > > > > > > > > > > > > > ~P
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > --
>> > > > > > > > > > > > > --
>> > > > > > > > > > > > > Marcos Lima
>> > > > > > > > > > > > > Software Developer/Tech Lead
>> > > > > > > > > > > > > marcoslimagon@gmail.com
>> > > > > > > > > > > > > tel: +55 (19) 9798-9335
>> > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > --
>> > > > Marcos Lima
>> > > > Software Developer/Tech Lead
>> > > > marcoslimagon@gmail.com
>> > > > tel: +55 (19) 9798-9335
>> > > >
>> > >
>> >
>>
>>
>>
>> --
>> --
>> Marcos Lima
>> Software Developer/Tech Lead
>> marcoslimagon@gmail.com
>> tel: +55 (19) 9798-9335
>>
>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Marcos,
That would be helpful. As far as I can tell, the 3.0 java code is only on
SVN here, before the lucene and solr projects were bundled together:
http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
The SVN for 4.3 java is here:
http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
And the GitHub for 4.3 java is here:
https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
My fork/branch of Lucene.net for the 4.3 port is here:
https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
My fork is the "upstream" fork for my team members, and i'm remote merging
their changes in from their forks while they fetch/merge from mine to get
everyone else's changes, rather than using pull requests. James and I have
been working the past few days on the Util namespace ahead of tonight's
hackathon since that namespace is in common with the rest of the
namespaces. Tonight, we'll have at least 8 guys that I know of hacking on
porting 4.3, each with a different namespace or part of a namespace. Since
we're going class-by-class, namespace-by-namespace, the project does not
build as it is. Once we finish doing a translation of each file, then we'll
hammer out any remaining issues and get it to build again. I'm hoping that
we can get at least 75% done with Core tonight. Wish us luck!
But one thing to keep in mind is it looks like much functionality has been
moved out of core into the contrib modules, especially around analysis, for
4.0+. For example, there are no built-in analyzers in core anymore. So when
this is all done, we may want to include at least the analysis contrib
module in with the standard core NuGet package, because otherwise it's
practically useless unless you roll your own analyzer.
Paul
On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <ma...@gmail.com>wrote:
> Hi everyone!
>
> Does someone know where can I find the 3.0.3 release from Lucene(java)?
>
> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0 and make
> the diff between then and get all changes between releases... I gonna
> publish it here soon. (If you think there is another important release, let
> me know)
>
> Paul, are you dealing (i`m not sure about this word, sorry) with 4.3.0 port
> for .Net on github (last email)?
>
> See you,
>
>
> 2013/6/10 Paul Irwin <pi...@feature23.com>
>
> > Thanks for the discussion points, Michael.
> >
> > I would vote for not worrying about trying to achieve portable
> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
> completed.
> > Otherwise it may delay the project and stall it further. That's just my
> > $0.02 based on my admittedly selfish need for 4.x features.
> >
> > I have started porting the changes from the core library (from the
> > java lucene_solr_4_3 branch) in my fork on github in a separate branch.
> > Since I need 4.3 ASAP, I am just going to keep going on my port until
> > there's changes to pull from upstream to work from. Also due to my time
> > constraints, I am not fully documenting new methods that I'm adding. But
> if
> > anyone wants to pull/copy/reference my changes while porting, that's
> > awesome. My branch currently does not build as I'm primarily going
> > class-by-class, starting with the util namespace. Once we get the ball
> > rolling on a community effort, I'll stop my rogue work and join in. But
> > hopefully my work will be useful to someone, if not as a pull request
> then
> > as a reference. I'm also going to be holding a hackathon this week with
> my
> > colleagues where we're all going to work on the port. I'm comparing files
> > and making changes as necessary, rather than starting from scratch. My
> > repo/branch is here:
> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >
> > Paul
> >
> >
> >
> >
> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> > mherndon@michaelherndon.com> wrote:
> >
> > > the guithub.com repo is a mirror to the git mirror that apache
> > maintains.
> > >
> > > The was some work at one time to move the official svn repository to
> > start
> > > using git one instead. Was that actually finalized or not?
> > >
> > > The Lucene.Net_4e (e for experimental) is an old branch to see what
> kind
> > of
> > > work was involved using a portable libraries project. Some of it can
> > still
> > > be used but will need to be validated against the current version of
> > Java's
> > > Lucene. It was also using .net 4.
> > >
> > > clean branch vs current. Its going to depend on what we support. If
> > you
> > > support windows mobile 8, win RT, then the current code in trunk will
> not
> > > compile against those versions of the framework which would a
> frustrating
> > > starting point, then you couldn't even run tests, which would make
> taking
> > > patches very difficult. Supporting those can almost mean larger gaps
> in
> > > design between Lucene.Net and its parent project.
> > >
> > > Also the structure has changed significantly between the branches and
> > the
> > > side of the code base of Lucene 4 is bigger, uses Java 6, and seems
> > > significantly different. That doesn't mean you can't cherry pick stuff
> > > from the other tags/branches that would still work as is. A clean
> branch
> > > would also make it easier to get our build / tool chain in order as you
> > can
> > > then do them incrementally versus having to do all the stuff that I did
> > for
> > > the 3x branch which saps energy and desire to code. It could also
> make
> > it
> > > easier to see which classes have been ported or not.
> > >
> > > The major downside to a clean branch is extra work it requires and the
> > > start up cost in time and energy of getting it in order, which can be
> > > daunting / intimidating and lower morale. And generally you want to use
> > > take your legacy code and refactor instead of in someways starting
> over.
> > >
> > > Are we going to port lucene 4 or 4.3 ? If so I can do something
> similar
> > > to
> > >
> > >
> >
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> > > where it tracks what needs to get ported / what has been ported.
> > >
> > > What are we going to support in the next version?
> > >
> > > Who is going to work on the next version?
> > >
> > > What would make the most sense and what would invigorate the community
> to
> > > get involved more and lower the barrier to entry?
> > >
> > > I think those are the questions that would make a lot of the decisions
> > for
> > > us so that we can get back to work on lucene.net.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <marcoslimagon@gmail.com
> > > >wrote:
> > >
> > > > Regarding the new branch, I'm a rookie with ASF projects...
> > > >
> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> > > > https://github.com/apache/lucene.net points to the same repository?
> > > (This
> > > > is new for me, pretty good) Which of them do you recommend (i'm used
> > with
> > > > SVN and its patterns).
> > > >
> > > > I'm checking the subversion right now.
> > > >
> > > > I can see the branches/Lucene.Net_4e. I think this is a old branch,
> i`m
> > > not
> > > > sure about its current status.
> > > >
> > > > Will we wipe the current solution from /trunk and start a new one?
> > > >
> > > > Thanks,
> > > >
> > > >
> > > >
> > > >
> > > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
> > > >
> > > > > We may be forced to start with a clean/empty branch if people still
> > > want
> > > > to
> > > > > attempt supporting lucene.net for mobile devices, win RT, etc. The
> > are
> > > > > many
> > > > > classes that Lucene.net uses from the full framework that would not
> > be
> > > > > accessible in other versions of the .NET Framework. It also might
> > > > require
> > > > > a design that differs even more from its parent project.
> > > > >
> > > > > It might be wise to poll what users most desire in the next version
> > > > through
> > > > > jira or user voice.
> > > > >
> > > > >
> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> > itamar@code972.com
> > > > > >wrote:
> > > > >
> > > > > > inline
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <pirwin@feature23.com
> >
> > > > wrote:
> > > > > >
> > > > > > > Ah, I gotcha. Still getting used to git, I've been a TFS guy
> for
> > so
> > > > > long
> > > > > > > :-)
> > > > > > >
> > > > > > > So to recap, the branch_3x will be used for any patches or
> > anything
> > > > to
> > > > > > the
> > > > > > > current 3.0.3 release, while trunk is what we will branch from
> > for
> > > 4x
> > > > > > dev.
> > > > > > > Correct?
> > > > > > >
> > > > > >
> > > > > > Yes - we can branch from it for 3.6 development if anyone will be
> > > > > > interested in that
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Thanks for pushing the Version.cs. What's the deal with the
> > github
> > > > > sync?
> > > > > > > Who could diagnose that?
> > > > > > >
> > > > > >
> > > > > > Not sure, Apache Infra, basically. Just use the apache repo for
> now
> > > > while
> > > > > > we get that sorted out.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> > > > itamar@code972.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Ok, haven't noticed that branch. Just use it then for 3.x
> > > > > development.
> > > > > > > WRT
> > > > > > > > v4, yeah - just fork the repo and work on whatever branch.
> When
> > > you
> > > > > > send
> > > > > > > us
> > > > > > > > PRs we will merge either to master or to a dedicated repo.
> For
> > > now
> > > > it
> > > > > > > > doesn't really matter, thats the beauty of git.
> > > > > > > >
> > > > > > > > I pushed a new Version.cs file, you should see it on the
> apache
> > > > > servers
> > > > > > > > (github sync seems to be off)
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> > > pirwin@feature23.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Thanks Itamar. I can certainly start work on 4.3 version of
> > the
> > > > > > > Analysis
> > > > > > > > > namespace.
> > > > > > > > >
> > > > > > > > > Not sure the checkout command is what you intended -- you
> > might
> > > > > have
> > > > > > > > meant
> > > > > > > > > trunk instead of master, and that would create a new "3x"
> > > branch,
> > > > > > when
> > > > > > > > > there's already a "branch_3x" and that would be misnamed...
> > so
> > > > > maybe
> > > > > > > > > checkout -b branch_4x trunk and start there aiming for
> lucene
> > > > 4.3.x
> > > > > > > > > compatibility?
> > > > > > > > >
> > > > > > > > > Also, does someone with commit rights to the upstream want
> to
> > > > > create
> > > > > > > the
> > > > > > > > > necessary Version.cs entries, so that we're not all trying
> to
> > > > > create
> > > > > > > them
> > > > > > > > > and dealing with a merge?
> > > > > > > > >
> > > > > > > > > Paul
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> > > > > > itamar@code972.com
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > Unless people here have a specific reason to use 3.6.2 I
> > > would
> > > > > > highly
> > > > > > > > > > recommed putting all the efforts we can towards v4
> > otherwise
> > > we
> > > > > > will
> > > > > > > > > never
> > > > > > > > > > make it...
> > > > > > > > > >
> > > > > > > > > > Fork the repo from apache servers or github (same repo,
> > > > different
> > > > > > > > > remotes)
> > > > > > > > > > and checkout -b 3x -t origin/master , that should work
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> > > > > pirwin@feature23.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Itamar,
> > > > > > > > > > >
> > > > > > > > > > > I agree that from scratch is not the best way to do
> it, I
> > > > just
> > > > > > > > thought
> > > > > > > > > > that
> > > > > > > > > > > was the "decision" that was made from the discussion
> > > > previously
> > > > > > for
> > > > > > > > the
> > > > > > > > > > 4.x
> > > > > > > > > > > work. An incremental approach will be much better.
> > > > > > > > > > >
> > > > > > > > > > > I've created a branch of the branch_3x branch on my
> fork
> > > and
> > > > > will
> > > > > > > > begin
> > > > > > > > > > > working on bringing the Analysis namespace up to speed
> to
> > > > > 3.6.2.
> > > > > > If
> > > > > > > > > > anyone
> > > > > > > > > > > wants to pull it or just reuse parts once I'm done,
> have
> > at
> > > > it.
> > > > > > > > > > >
> > > > > > > > > > > If I shouldn't have branched off the branch_3x branch,
> > > please
> > > > > let
> > > > > > > me
> > > > > > > > > know
> > > > > > > > > > > what I should have branched from (trunk?)
> > > > > > > > > > >
> > > > > > > > > > > Paul
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <
> > > > > > > > itamar@code972.com
> > > > > > > > > > > >wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Thanks Prescott for bringing this up again :)
> > > > > > > > > > > >
> > > > > > > > > > > > Paul, the problem is no one can really know what it
> > would
> > > > > take
> > > > > > > > until
> > > > > > > > > > they
> > > > > > > > > > > > have deep dived into the work, and even then
> decisions
> > > > could
> > > > > > and
> > > > > > > > will
> > > > > > > > > > > > change. I will strongly advise against starting from
> > > > scratch,
> > > > > > > > > although
> > > > > > > > > > I
> > > > > > > > > > > do
> > > > > > > > > > > > think a lot in the current structure should change,
> but
> > > its
> > > > > > going
> > > > > > > > to
> > > > > > > > > be
> > > > > > > > > > > > much easier to change it in place, refactoring where
> > > > needed,
> > > > > > than
> > > > > > > > > > > starting
> > > > > > > > > > > > all over again. Once we kicked this off I personally
> > will
> > > > be
> > > > > > > happy
> > > > > > > > > with
> > > > > > > > > > > you
> > > > > > > > > > > > taking the analysis part of Lucene and porting it,
> its
> > > > pretty
> > > > > > > much
> > > > > > > > > self
> > > > > > > > > > > > contained.
> > > > > > > > > > > > Re 3.6.2 work - you can just do that on a fork and
> send
> > > us
> > > > > PRs,
> > > > > > > its
> > > > > > > > > > much
> > > > > > > > > > > > more straight forward than the v4 upgrade
> > > > > > > > > > > >
> > > > > > > > > > > > Marcos, porting class by class is the fastest way to
> do
> > > > this,
> > > > > > we
> > > > > > > > can
> > > > > > > > > > then
> > > > > > > > > > > > concentrate on .NETifying and optimizing using .NET
> > > > > constructs.
> > > > > > > > > > > >
> > > > > > > > > > > > That said, I think the way to go is create a branch
> out
> > > of
> > > > > the
> > > > > > > > > current
> > > > > > > > > > > git
> > > > > > > > > > > > master HEAD and label it "3.x", and start working on
> > > master
> > > > > > > > towards a
> > > > > > > > > > 4.3
> > > > > > > > > > > > compatible version. The actual port should be using a
> > > > process
> > > > > > > that
> > > > > > > > > > > ensures
> > > > > > > > > > > > all Java classes are ported with their tests, and
> that
> > > > those
> > > > > > > tests
> > > > > > > > > > pass -
> > > > > > > > > > > > but I'm against committing any Java code to our
> > > > repositories.
> > > > > > The
> > > > > > > > > > process
> > > > > > > > > > > > should probably be working on classes in some order
> > > > > > > > (alphabetically,
> > > > > > > > > or
> > > > > > > > > > > > core classes first) and getting each class to compile
> > > > before
> > > > > > > moving
> > > > > > > > > > > > forward. I don't mind about the project not being
> > > > compilable
> > > > > > for
> > > > > > > a
> > > > > > > > > > month
> > > > > > > > > > > or
> > > > > > > > > > > > two.
> > > > > > > > > > > > Once this is done a process of .NETifying and
> proofing
> > > the
> > > > > code
> > > > > > > can
> > > > > > > > > be
> > > > > > > > > > > > started, at which point we will already have a
> working
> > v4
> > > > > > version
> > > > > > > > so
> > > > > > > > > it
> > > > > > > > > > > > will be easier to keep up with the Java project.
> > > > > > > > > > > >
> > > > > > > > > > > > The first step IMO is to stabilize the test suite so
> > > tests
> > > > > > could
> > > > > > > > more
> > > > > > > > > > or
> > > > > > > > > > > > less be copied and pasted (e.g. implementing
> Java-like
> > > > > > > assertEquals
> > > > > > > > > > > methods
> > > > > > > > > > > > etc; I find xUnit to be much easier to work with than
> > > > > NUnit). I
> > > > > > > > > already
> > > > > > > > > > > did
> > > > > > > > > > > > some work there but there's still a lot to do.
> > > > > > > > > > > >
> > > > > > > > > > > > Unfortunately I can't dedicate time myself at this
> > point,
> > > > > but I
> > > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > > > back in business in August, at which point I can
> > dedicate
> > > > > > several
> > > > > > > > > > hours a
> > > > > > > > > > > > week. Until then I'll be happy to watch closely and
> > even
> > > > > > > coordinate
> > > > > > > > > the
> > > > > > > > > > > > work to some extent.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > > > > > > > > marcoslimagon@gmail.com
> > > > > > > > > > > > >wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > It really sounds good to me, this is a kick start
> > =). I
> > > > > > haven't
> > > > > > > > > > > > contributed
> > > > > > > > > > > > > anything
> > > > > > > > > > > > > yet, but I would like to help you all to get this
> job
> > > > done.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm completely agree with Paul and Prescott.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I know that there is a high commitment for keep the
> > > > > > > > > > retrocompatibility
> > > > > > > > > > > on
> > > > > > > > > > > > > Lucene. Does Java Lucene API gets big changes every
> > > > > release?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Is the Lucene.Net a port from a stable version
> from a
> > > > > Lucene
> > > > > > > > > version,
> > > > > > > > > > > > > right? If the Lucene API gets only minor changes
> > every
> > > > > stable
> > > > > > > > > release
> > > > > > > > > > > (or
> > > > > > > > > > > > > keep most of its source-code), we could compare the
> > > > > versions,
> > > > > > > > check
> > > > > > > > > > the
> > > > > > > > > > > > > differences and bring them to Lucene.Net. Again, I
> > > > haven't
> > > > > > > > > > contributed
> > > > > > > > > > > > with
> > > > > > > > > > > > > yet, so I don't know how it is (just an idea).
> > > > > > > > > > > > >
> > > > > > > > > > > > > What's your approach for implement simple
> performance
> > > > > > > > improvements
> > > > > > > > > > > > (without
> > > > > > > > > > > > > adding references or changing methods signatures)?
> > Does
> > > > it
> > > > > > > could
> > > > > > > > be
> > > > > > > > > > > done,
> > > > > > > > > > > > > or "follow the java version only"?
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > > > > > > > > > > >
> > > > > > > > > > > > > > This is just an "outsider" suggestion as I
> haven't
> > > > > > > contributed
> > > > > > > > > > > anything
> > > > > > > > > > > > > > yet, although I will definitely help with the 4.x
> > > work
> > > > > as I
> > > > > > > > have
> > > > > > > > > a
> > > > > > > > > > > > vested
> > > > > > > > > > > > > > interest in seeing that get completed. I think
> > there
> > > > > should
> > > > > > > be
> > > > > > > > > one
> > > > > > > > > > > > person
> > > > > > > > > > > > > > (or perhaps two) guiding what the structure and
> > > > workflow
> > > > > > will
> > > > > > > > > look
> > > > > > > > > > > like
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > avoid chaos. If the 4.x work is going to be
> > starting
> > > > from
> > > > > > > > scratch
> > > > > > > > > > as
> > > > > > > > > > > a
> > > > > > > > > > > > > > fresh port, that person should set up the
> project,
> > > get
> > > > > > > > everything
> > > > > > > > > > > going
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > source control, create the folder structure,
> maybe
> > > stub
> > > > > out
> > > > > > > > some
> > > > > > > > > > > > classes,
> > > > > > > > > > > > > > etc. Then divide and conquer with anyone
> interested
> > > in
> > > > > > > > > > contributing,
> > > > > > > > > > > > > > perhaps by namespace.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I like the idea of throwing the java code in
> there
> > so
> > > > > it's
> > > > > > > easy
> > > > > > > > > to
> > > > > > > > > > > > > > reference.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Again, I can work on Lucene.Net.Documents,
> > > > > > > Lucene.Net.Analysis,
> > > > > > > > > or
> > > > > > > > > > > > > > Lucene.Net.Store -- or any others, those are just
> > the
> > > > > ones
> > > > > > > I'm
> > > > > > > > > most
> > > > > > > > > > > > > > familiar with the inner workings. Tell me what to
> > do
> > > > and
> > > > > > I'll
> > > > > > > > get
> > > > > > > > > > > > started
> > > > > > > > > > > > > > on my fork.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Paul Irwin
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > > > > > > > > > > geobmx540@hotmail.com
> > > > > > > > > > > > > > >wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hey guys -
> > > > > > > > > > > > > > > I know I've been MIA a little while. We have a
> > > board
> > > > > > report
> > > > > > > > due
> > > > > > > > > > > soon
> > > > > > > > > > > > -
> > > > > > > > > > > > > I
> > > > > > > > > > > > > > > think it prudent that we advise them that we
> seem
> > > to
> > > > > have
> > > > > > > > > stalled
> > > > > > > > > > > > > > somewhat.
> > > > > > > > > > > > > > > We've got a few low hanging items out of of
> jira
> > > and
> > > > > have
> > > > > > > > been
> > > > > > > > > > > > > responsive
> > > > > > > > > > > > > > > on the mailing list to community questions,
> but I
> > > > don't
> > > > > > > think
> > > > > > > > > > we've
> > > > > > > > > > > > > done
> > > > > > > > > > > > > > > anything to move forward with 4.0.
> > > > > > > > > > > > > > > To that end - I'd like to *try* and start us
> back
> > > up
> > > > > > moving
> > > > > > > > > > > forward.
> > > > > > > > > > > > > What
> > > > > > > > > > > > > > > is the best way to accomplish this? If we took
> > the
> > > > java
> > > > > > > > lucene
> > > > > > > > > > 4.0
> > > > > > > > > > > > code
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > committed that java to our branch and then just
> > let
> > > > > > people
> > > > > > > > pull
> > > > > > > > > > > that
> > > > > > > > > > > > > down
> > > > > > > > > > > > > > > and being changing / modifying is that one way
> to
> > > > maybe
> > > > > > > make
> > > > > > > > > some
> > > > > > > > > > > > > forward
> > > > > > > > > > > > > > > progress?
> > > > > > > > > > > > > > > ~P
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Marcos Lima
> > > > > > > > > > > > > Software Developer/Tech Lead
> > > > > > > > > > > > > marcoslimagon@gmail.com
> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > --
> > > > Marcos Lima
> > > > Software Developer/Tech Lead
> > > > marcoslimagon@gmail.com
> > > > tel: +55 (19) 9798-9335
> > > >
> > >
> >
>
>
>
> --
> --
> Marcos Lima
> Software Developer/Tech Lead
> marcoslimagon@gmail.com
> tel: +55 (19) 9798-9335
>
Re: Lucene 4.0
Posted by Marcos Lima <ma...@gmail.com>.
Hi everyone!
Does someone know where can I find the 3.0.3 release from Lucene(java)?
I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0 and make
the diff between then and get all changes between releases... I gonna
publish it here soon. (If you think there is another important release, let
me know)
Paul, are you dealing (i`m not sure about this word, sorry) with 4.3.0 port
for .Net on github (last email)?
See you,
2013/6/10 Paul Irwin <pi...@feature23.com>
> Thanks for the discussion points, Michael.
>
> I would vote for not worrying about trying to achieve portable
> compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is completed.
> Otherwise it may delay the project and stall it further. That's just my
> $0.02 based on my admittedly selfish need for 4.x features.
>
> I have started porting the changes from the core library (from the
> java lucene_solr_4_3 branch) in my fork on github in a separate branch.
> Since I need 4.3 ASAP, I am just going to keep going on my port until
> there's changes to pull from upstream to work from. Also due to my time
> constraints, I am not fully documenting new methods that I'm adding. But if
> anyone wants to pull/copy/reference my changes while porting, that's
> awesome. My branch currently does not build as I'm primarily going
> class-by-class, starting with the util namespace. Once we get the ball
> rolling on a community effort, I'll stop my rogue work and join in. But
> hopefully my work will be useful to someone, if not as a pull request then
> as a reference. I'm also going to be holding a hackathon this week with my
> colleagues where we're all going to work on the port. I'm comparing files
> and making changes as necessary, rather than starting from scratch. My
> repo/branch is here:
> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
> Paul
>
>
>
>
> On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> mherndon@michaelherndon.com> wrote:
>
> > the guithub.com repo is a mirror to the git mirror that apache
> maintains.
> >
> > The was some work at one time to move the official svn repository to
> start
> > using git one instead. Was that actually finalized or not?
> >
> > The Lucene.Net_4e (e for experimental) is an old branch to see what kind
> of
> > work was involved using a portable libraries project. Some of it can
> still
> > be used but will need to be validated against the current version of
> Java's
> > Lucene. It was also using .net 4.
> >
> > clean branch vs current. Its going to depend on what we support. If
> you
> > support windows mobile 8, win RT, then the current code in trunk will not
> > compile against those versions of the framework which would a frustrating
> > starting point, then you couldn't even run tests, which would make taking
> > patches very difficult. Supporting those can almost mean larger gaps in
> > design between Lucene.Net and its parent project.
> >
> > Also the structure has changed significantly between the branches and
> the
> > side of the code base of Lucene 4 is bigger, uses Java 6, and seems
> > significantly different. That doesn't mean you can't cherry pick stuff
> > from the other tags/branches that would still work as is. A clean branch
> > would also make it easier to get our build / tool chain in order as you
> can
> > then do them incrementally versus having to do all the stuff that I did
> for
> > the 3x branch which saps energy and desire to code. It could also make
> it
> > easier to see which classes have been ported or not.
> >
> > The major downside to a clean branch is extra work it requires and the
> > start up cost in time and energy of getting it in order, which can be
> > daunting / intimidating and lower morale. And generally you want to use
> > take your legacy code and refactor instead of in someways starting over.
> >
> > Are we going to port lucene 4 or 4.3 ? If so I can do something similar
> > to
> >
> >
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> > where it tracks what needs to get ported / what has been ported.
> >
> > What are we going to support in the next version?
> >
> > Who is going to work on the next version?
> >
> > What would make the most sense and what would invigorate the community to
> > get involved more and lower the barrier to entry?
> >
> > I think those are the questions that would make a lot of the decisions
> for
> > us so that we can get back to work on lucene.net.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <marcoslimagon@gmail.com
> > >wrote:
> >
> > > Regarding the new branch, I'm a rookie with ASF projects...
> > >
> > > The https://svn.apache.org/repos/asf/lucene.net/ and
> > > https://github.com/apache/lucene.net points to the same repository?
> > (This
> > > is new for me, pretty good) Which of them do you recommend (i'm used
> with
> > > SVN and its patterns).
> > >
> > > I'm checking the subversion right now.
> > >
> > > I can see the branches/Lucene.Net_4e. I think this is a old branch, i`m
> > not
> > > sure about its current status.
> > >
> > > Will we wipe the current solution from /trunk and start a new one?
> > >
> > > Thanks,
> > >
> > >
> > >
> > >
> > > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
> > >
> > > > We may be forced to start with a clean/empty branch if people still
> > want
> > > to
> > > > attempt supporting lucene.net for mobile devices, win RT, etc. The
> are
> > > > many
> > > > classes that Lucene.net uses from the full framework that would not
> be
> > > > accessible in other versions of the .NET Framework. It also might
> > > require
> > > > a design that differs even more from its parent project.
> > > >
> > > > It might be wise to poll what users most desire in the next version
> > > through
> > > > jira or user voice.
> > > >
> > > >
> > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> itamar@code972.com
> > > > >wrote:
> > > >
> > > > > inline
> > > > >
> > > > >
> > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <pi...@feature23.com>
> > > wrote:
> > > > >
> > > > > > Ah, I gotcha. Still getting used to git, I've been a TFS guy for
> so
> > > > long
> > > > > > :-)
> > > > > >
> > > > > > So to recap, the branch_3x will be used for any patches or
> anything
> > > to
> > > > > the
> > > > > > current 3.0.3 release, while trunk is what we will branch from
> for
> > 4x
> > > > > dev.
> > > > > > Correct?
> > > > > >
> > > > >
> > > > > Yes - we can branch from it for 3.6 development if anyone will be
> > > > > interested in that
> > > > >
> > > > >
> > > > > >
> > > > > > Thanks for pushing the Version.cs. What's the deal with the
> github
> > > > sync?
> > > > > > Who could diagnose that?
> > > > > >
> > > > >
> > > > > Not sure, Apache Infra, basically. Just use the apache repo for now
> > > while
> > > > > we get that sorted out.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> > > itamar@code972.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Ok, haven't noticed that branch. Just use it then for 3.x
> > > > development.
> > > > > > WRT
> > > > > > > v4, yeah - just fork the repo and work on whatever branch. When
> > you
> > > > > send
> > > > > > us
> > > > > > > PRs we will merge either to master or to a dedicated repo. For
> > now
> > > it
> > > > > > > doesn't really matter, thats the beauty of git.
> > > > > > >
> > > > > > > I pushed a new Version.cs file, you should see it on the apache
> > > > servers
> > > > > > > (github sync seems to be off)
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> > pirwin@feature23.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Thanks Itamar. I can certainly start work on 4.3 version of
> the
> > > > > > Analysis
> > > > > > > > namespace.
> > > > > > > >
> > > > > > > > Not sure the checkout command is what you intended -- you
> might
> > > > have
> > > > > > > meant
> > > > > > > > trunk instead of master, and that would create a new "3x"
> > branch,
> > > > > when
> > > > > > > > there's already a "branch_3x" and that would be misnamed...
> so
> > > > maybe
> > > > > > > > checkout -b branch_4x trunk and start there aiming for lucene
> > > 4.3.x
> > > > > > > > compatibility?
> > > > > > > >
> > > > > > > > Also, does someone with commit rights to the upstream want to
> > > > create
> > > > > > the
> > > > > > > > necessary Version.cs entries, so that we're not all trying to
> > > > create
> > > > > > them
> > > > > > > > and dealing with a merge?
> > > > > > > >
> > > > > > > > Paul
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> > > > > itamar@code972.com
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > Unless people here have a specific reason to use 3.6.2 I
> > would
> > > > > highly
> > > > > > > > > recommed putting all the efforts we can towards v4
> otherwise
> > we
> > > > > will
> > > > > > > > never
> > > > > > > > > make it...
> > > > > > > > >
> > > > > > > > > Fork the repo from apache servers or github (same repo,
> > > different
> > > > > > > > remotes)
> > > > > > > > > and checkout -b 3x -t origin/master , that should work
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> > > > pirwin@feature23.com>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Itamar,
> > > > > > > > > >
> > > > > > > > > > I agree that from scratch is not the best way to do it, I
> > > just
> > > > > > > thought
> > > > > > > > > that
> > > > > > > > > > was the "decision" that was made from the discussion
> > > previously
> > > > > for
> > > > > > > the
> > > > > > > > > 4.x
> > > > > > > > > > work. An incremental approach will be much better.
> > > > > > > > > >
> > > > > > > > > > I've created a branch of the branch_3x branch on my fork
> > and
> > > > will
> > > > > > > begin
> > > > > > > > > > working on bringing the Analysis namespace up to speed to
> > > > 3.6.2.
> > > > > If
> > > > > > > > > anyone
> > > > > > > > > > wants to pull it or just reuse parts once I'm done, have
> at
> > > it.
> > > > > > > > > >
> > > > > > > > > > If I shouldn't have branched off the branch_3x branch,
> > please
> > > > let
> > > > > > me
> > > > > > > > know
> > > > > > > > > > what I should have branched from (trunk?)
> > > > > > > > > >
> > > > > > > > > > Paul
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <
> > > > > > > itamar@code972.com
> > > > > > > > > > >wrote:
> > > > > > > > > >
> > > > > > > > > > > Thanks Prescott for bringing this up again :)
> > > > > > > > > > >
> > > > > > > > > > > Paul, the problem is no one can really know what it
> would
> > > > take
> > > > > > > until
> > > > > > > > > they
> > > > > > > > > > > have deep dived into the work, and even then decisions
> > > could
> > > > > and
> > > > > > > will
> > > > > > > > > > > change. I will strongly advise against starting from
> > > scratch,
> > > > > > > > although
> > > > > > > > > I
> > > > > > > > > > do
> > > > > > > > > > > think a lot in the current structure should change, but
> > its
> > > > > going
> > > > > > > to
> > > > > > > > be
> > > > > > > > > > > much easier to change it in place, refactoring where
> > > needed,
> > > > > than
> > > > > > > > > > starting
> > > > > > > > > > > all over again. Once we kicked this off I personally
> will
> > > be
> > > > > > happy
> > > > > > > > with
> > > > > > > > > > you
> > > > > > > > > > > taking the analysis part of Lucene and porting it, its
> > > pretty
> > > > > > much
> > > > > > > > self
> > > > > > > > > > > contained.
> > > > > > > > > > > Re 3.6.2 work - you can just do that on a fork and send
> > us
> > > > PRs,
> > > > > > its
> > > > > > > > > much
> > > > > > > > > > > more straight forward than the v4 upgrade
> > > > > > > > > > >
> > > > > > > > > > > Marcos, porting class by class is the fastest way to do
> > > this,
> > > > > we
> > > > > > > can
> > > > > > > > > then
> > > > > > > > > > > concentrate on .NETifying and optimizing using .NET
> > > > constructs.
> > > > > > > > > > >
> > > > > > > > > > > That said, I think the way to go is create a branch out
> > of
> > > > the
> > > > > > > > current
> > > > > > > > > > git
> > > > > > > > > > > master HEAD and label it "3.x", and start working on
> > master
> > > > > > > towards a
> > > > > > > > > 4.3
> > > > > > > > > > > compatible version. The actual port should be using a
> > > process
> > > > > > that
> > > > > > > > > > ensures
> > > > > > > > > > > all Java classes are ported with their tests, and that
> > > those
> > > > > > tests
> > > > > > > > > pass -
> > > > > > > > > > > but I'm against committing any Java code to our
> > > repositories.
> > > > > The
> > > > > > > > > process
> > > > > > > > > > > should probably be working on classes in some order
> > > > > > > (alphabetically,
> > > > > > > > or
> > > > > > > > > > > core classes first) and getting each class to compile
> > > before
> > > > > > moving
> > > > > > > > > > > forward. I don't mind about the project not being
> > > compilable
> > > > > for
> > > > > > a
> > > > > > > > > month
> > > > > > > > > > or
> > > > > > > > > > > two.
> > > > > > > > > > > Once this is done a process of .NETifying and proofing
> > the
> > > > code
> > > > > > can
> > > > > > > > be
> > > > > > > > > > > started, at which point we will already have a working
> v4
> > > > > version
> > > > > > > so
> > > > > > > > it
> > > > > > > > > > > will be easier to keep up with the Java project.
> > > > > > > > > > >
> > > > > > > > > > > The first step IMO is to stabilize the test suite so
> > tests
> > > > > could
> > > > > > > more
> > > > > > > > > or
> > > > > > > > > > > less be copied and pasted (e.g. implementing Java-like
> > > > > > assertEquals
> > > > > > > > > > methods
> > > > > > > > > > > etc; I find xUnit to be much easier to work with than
> > > > NUnit). I
> > > > > > > > already
> > > > > > > > > > did
> > > > > > > > > > > some work there but there's still a lot to do.
> > > > > > > > > > >
> > > > > > > > > > > Unfortunately I can't dedicate time myself at this
> point,
> > > > but I
> > > > > > > > should
> > > > > > > > > be
> > > > > > > > > > > back in business in August, at which point I can
> dedicate
> > > > > several
> > > > > > > > > hours a
> > > > > > > > > > > week. Until then I'll be happy to watch closely and
> even
> > > > > > coordinate
> > > > > > > > the
> > > > > > > > > > > work to some extent.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > > > > > > > marcoslimagon@gmail.com
> > > > > > > > > > > >wrote:
> > > > > > > > > > >
> > > > > > > > > > > > It really sounds good to me, this is a kick start
> =). I
> > > > > haven't
> > > > > > > > > > > contributed
> > > > > > > > > > > > anything
> > > > > > > > > > > > yet, but I would like to help you all to get this job
> > > done.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm completely agree with Paul and Prescott.
> > > > > > > > > > > >
> > > > > > > > > > > > I know that there is a high commitment for keep the
> > > > > > > > > retrocompatibility
> > > > > > > > > > on
> > > > > > > > > > > > Lucene. Does Java Lucene API gets big changes every
> > > > release?
> > > > > > > > > > > >
> > > > > > > > > > > > Is the Lucene.Net a port from a stable version from a
> > > > Lucene
> > > > > > > > version,
> > > > > > > > > > > > right? If the Lucene API gets only minor changes
> every
> > > > stable
> > > > > > > > release
> > > > > > > > > > (or
> > > > > > > > > > > > keep most of its source-code), we could compare the
> > > > versions,
> > > > > > > check
> > > > > > > > > the
> > > > > > > > > > > > differences and bring them to Lucene.Net. Again, I
> > > haven't
> > > > > > > > > contributed
> > > > > > > > > > > with
> > > > > > > > > > > > yet, so I don't know how it is (just an idea).
> > > > > > > > > > > >
> > > > > > > > > > > > What's your approach for implement simple performance
> > > > > > > improvements
> > > > > > > > > > > (without
> > > > > > > > > > > > adding references or changing methods signatures)?
> Does
> > > it
> > > > > > could
> > > > > > > be
> > > > > > > > > > done,
> > > > > > > > > > > > or "follow the java version only"?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > > > > > > > > > >
> > > > > > > > > > > > > This is just an "outsider" suggestion as I haven't
> > > > > > contributed
> > > > > > > > > > anything
> > > > > > > > > > > > > yet, although I will definitely help with the 4.x
> > work
> > > > as I
> > > > > > > have
> > > > > > > > a
> > > > > > > > > > > vested
> > > > > > > > > > > > > interest in seeing that get completed. I think
> there
> > > > should
> > > > > > be
> > > > > > > > one
> > > > > > > > > > > person
> > > > > > > > > > > > > (or perhaps two) guiding what the structure and
> > > workflow
> > > > > will
> > > > > > > > look
> > > > > > > > > > like
> > > > > > > > > > > > to
> > > > > > > > > > > > > avoid chaos. If the 4.x work is going to be
> starting
> > > from
> > > > > > > scratch
> > > > > > > > > as
> > > > > > > > > > a
> > > > > > > > > > > > > fresh port, that person should set up the project,
> > get
> > > > > > > everything
> > > > > > > > > > going
> > > > > > > > > > > > in
> > > > > > > > > > > > > source control, create the folder structure, maybe
> > stub
> > > > out
> > > > > > > some
> > > > > > > > > > > classes,
> > > > > > > > > > > > > etc. Then divide and conquer with anyone interested
> > in
> > > > > > > > > contributing,
> > > > > > > > > > > > > perhaps by namespace.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I like the idea of throwing the java code in there
> so
> > > > it's
> > > > > > easy
> > > > > > > > to
> > > > > > > > > > > > > reference.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Again, I can work on Lucene.Net.Documents,
> > > > > > Lucene.Net.Analysis,
> > > > > > > > or
> > > > > > > > > > > > > Lucene.Net.Store -- or any others, those are just
> the
> > > > ones
> > > > > > I'm
> > > > > > > > most
> > > > > > > > > > > > > familiar with the inner workings. Tell me what to
> do
> > > and
> > > > > I'll
> > > > > > > get
> > > > > > > > > > > started
> > > > > > > > > > > > > on my fork.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Paul Irwin
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > > > > > > > > > geobmx540@hotmail.com
> > > > > > > > > > > > > >wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hey guys -
> > > > > > > > > > > > > > I know I've been MIA a little while. We have a
> > board
> > > > > report
> > > > > > > due
> > > > > > > > > > soon
> > > > > > > > > > > -
> > > > > > > > > > > > I
> > > > > > > > > > > > > > think it prudent that we advise them that we seem
> > to
> > > > have
> > > > > > > > stalled
> > > > > > > > > > > > > somewhat.
> > > > > > > > > > > > > > We've got a few low hanging items out of of jira
> > and
> > > > have
> > > > > > > been
> > > > > > > > > > > > responsive
> > > > > > > > > > > > > > on the mailing list to community questions, but I
> > > don't
> > > > > > think
> > > > > > > > > we've
> > > > > > > > > > > > done
> > > > > > > > > > > > > > anything to move forward with 4.0.
> > > > > > > > > > > > > > To that end - I'd like to *try* and start us back
> > up
> > > > > moving
> > > > > > > > > > forward.
> > > > > > > > > > > > What
> > > > > > > > > > > > > > is the best way to accomplish this? If we took
> the
> > > java
> > > > > > > lucene
> > > > > > > > > 4.0
> > > > > > > > > > > code
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > committed that java to our branch and then just
> let
> > > > > people
> > > > > > > pull
> > > > > > > > > > that
> > > > > > > > > > > > down
> > > > > > > > > > > > > > and being changing / modifying is that one way to
> > > maybe
> > > > > > make
> > > > > > > > some
> > > > > > > > > > > > forward
> > > > > > > > > > > > > > progress?
> > > > > > > > > > > > > > ~P
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > --
> > > > > > > > > > > > Marcos Lima
> > > > > > > > > > > > Software Developer/Tech Lead
> > > > > > > > > > > > marcoslimagon@gmail.com
> > > > > > > > > > > > tel: +55 (19) 9798-9335
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > --
> > > Marcos Lima
> > > Software Developer/Tech Lead
> > > marcoslimagon@gmail.com
> > > tel: +55 (19) 9798-9335
> > >
> >
>
--
--
Marcos Lima
Software Developer/Tech Lead
marcoslimagon@gmail.com
tel: +55 (19) 9798-9335
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Thanks for the discussion points, Michael.
I would vote for not worrying about trying to achieve portable
compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is completed.
Otherwise it may delay the project and stall it further. That's just my
$0.02 based on my admittedly selfish need for 4.x features.
I have started porting the changes from the core library (from the
java lucene_solr_4_3 branch) in my fork on github in a separate branch.
Since I need 4.3 ASAP, I am just going to keep going on my port until
there's changes to pull from upstream to work from. Also due to my time
constraints, I am not fully documenting new methods that I'm adding. But if
anyone wants to pull/copy/reference my changes while porting, that's
awesome. My branch currently does not build as I'm primarily going
class-by-class, starting with the util namespace. Once we get the ball
rolling on a community effort, I'll stop my rogue work and join in. But
hopefully my work will be useful to someone, if not as a pull request then
as a reference. I'm also going to be holding a hackathon this week with my
colleagues where we're all going to work on the port. I'm comparing files
and making changes as necessary, rather than starting from scratch. My
repo/branch is here:
https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
Paul
On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
mherndon@michaelherndon.com> wrote:
> the guithub.com repo is a mirror to the git mirror that apache maintains.
>
> The was some work at one time to move the official svn repository to start
> using git one instead. Was that actually finalized or not?
>
> The Lucene.Net_4e (e for experimental) is an old branch to see what kind of
> work was involved using a portable libraries project. Some of it can still
> be used but will need to be validated against the current version of Java's
> Lucene. It was also using .net 4.
>
> clean branch vs current. Its going to depend on what we support. If you
> support windows mobile 8, win RT, then the current code in trunk will not
> compile against those versions of the framework which would a frustrating
> starting point, then you couldn't even run tests, which would make taking
> patches very difficult. Supporting those can almost mean larger gaps in
> design between Lucene.Net and its parent project.
>
> Also the structure has changed significantly between the branches and the
> side of the code base of Lucene 4 is bigger, uses Java 6, and seems
> significantly different. That doesn't mean you can't cherry pick stuff
> from the other tags/branches that would still work as is. A clean branch
> would also make it easier to get our build / tool chain in order as you can
> then do them incrementally versus having to do all the stuff that I did for
> the 3x branch which saps energy and desire to code. It could also make it
> easier to see which classes have been ported or not.
>
> The major downside to a clean branch is extra work it requires and the
> start up cost in time and energy of getting it in order, which can be
> daunting / intimidating and lower morale. And generally you want to use
> take your legacy code and refactor instead of in someways starting over.
>
> Are we going to port lucene 4 or 4.3 ? If so I can do something similar
> to
>
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> where it tracks what needs to get ported / what has been ported.
>
> What are we going to support in the next version?
>
> Who is going to work on the next version?
>
> What would make the most sense and what would invigorate the community to
> get involved more and lower the barrier to entry?
>
> I think those are the questions that would make a lot of the decisions for
> us so that we can get back to work on lucene.net.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <marcoslimagon@gmail.com
> >wrote:
>
> > Regarding the new branch, I'm a rookie with ASF projects...
> >
> > The https://svn.apache.org/repos/asf/lucene.net/ and
> > https://github.com/apache/lucene.net points to the same repository?
> (This
> > is new for me, pretty good) Which of them do you recommend (i'm used with
> > SVN and its patterns).
> >
> > I'm checking the subversion right now.
> >
> > I can see the branches/Lucene.Net_4e. I think this is a old branch, i`m
> not
> > sure about its current status.
> >
> > Will we wipe the current solution from /trunk and start a new one?
> >
> > Thanks,
> >
> >
> >
> >
> > 2013/6/6 mherndon michael <mh...@michaelherndon.com>
> >
> > > We may be forced to start with a clean/empty branch if people still
> want
> > to
> > > attempt supporting lucene.net for mobile devices, win RT, etc. The are
> > > many
> > > classes that Lucene.net uses from the full framework that would not be
> > > accessible in other versions of the .NET Framework. It also might
> > require
> > > a design that differs even more from its parent project.
> > >
> > > It might be wise to poll what users most desire in the next version
> > through
> > > jira or user voice.
> > >
> > >
> > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <itamar@code972.com
> > > >wrote:
> > >
> > > > inline
> > > >
> > > >
> > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <pi...@feature23.com>
> > wrote:
> > > >
> > > > > Ah, I gotcha. Still getting used to git, I've been a TFS guy for so
> > > long
> > > > > :-)
> > > > >
> > > > > So to recap, the branch_3x will be used for any patches or anything
> > to
> > > > the
> > > > > current 3.0.3 release, while trunk is what we will branch from for
> 4x
> > > > dev.
> > > > > Correct?
> > > > >
> > > >
> > > > Yes - we can branch from it for 3.6 development if anyone will be
> > > > interested in that
> > > >
> > > >
> > > > >
> > > > > Thanks for pushing the Version.cs. What's the deal with the github
> > > sync?
> > > > > Who could diagnose that?
> > > > >
> > > >
> > > > Not sure, Apache Infra, basically. Just use the apache repo for now
> > while
> > > > we get that sorted out.
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> > itamar@code972.com
> > > > > >wrote:
> > > > >
> > > > > > Ok, haven't noticed that branch. Just use it then for 3.x
> > > development.
> > > > > WRT
> > > > > > v4, yeah - just fork the repo and work on whatever branch. When
> you
> > > > send
> > > > > us
> > > > > > PRs we will merge either to master or to a dedicated repo. For
> now
> > it
> > > > > > doesn't really matter, thats the beauty of git.
> > > > > >
> > > > > > I pushed a new Version.cs file, you should see it on the apache
> > > servers
> > > > > > (github sync seems to be off)
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> pirwin@feature23.com>
> > > > > wrote:
> > > > > >
> > > > > > > Thanks Itamar. I can certainly start work on 4.3 version of the
> > > > > Analysis
> > > > > > > namespace.
> > > > > > >
> > > > > > > Not sure the checkout command is what you intended -- you might
> > > have
> > > > > > meant
> > > > > > > trunk instead of master, and that would create a new "3x"
> branch,
> > > > when
> > > > > > > there's already a "branch_3x" and that would be misnamed... so
> > > maybe
> > > > > > > checkout -b branch_4x trunk and start there aiming for lucene
> > 4.3.x
> > > > > > > compatibility?
> > > > > > >
> > > > > > > Also, does someone with commit rights to the upstream want to
> > > create
> > > > > the
> > > > > > > necessary Version.cs entries, so that we're not all trying to
> > > create
> > > > > them
> > > > > > > and dealing with a merge?
> > > > > > >
> > > > > > > Paul
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> > > > itamar@code972.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Unless people here have a specific reason to use 3.6.2 I
> would
> > > > highly
> > > > > > > > recommed putting all the efforts we can towards v4 otherwise
> we
> > > > will
> > > > > > > never
> > > > > > > > make it...
> > > > > > > >
> > > > > > > > Fork the repo from apache servers or github (same repo,
> > different
> > > > > > > remotes)
> > > > > > > > and checkout -b 3x -t origin/master , that should work
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> > > pirwin@feature23.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Itamar,
> > > > > > > > >
> > > > > > > > > I agree that from scratch is not the best way to do it, I
> > just
> > > > > > thought
> > > > > > > > that
> > > > > > > > > was the "decision" that was made from the discussion
> > previously
> > > > for
> > > > > > the
> > > > > > > > 4.x
> > > > > > > > > work. An incremental approach will be much better.
> > > > > > > > >
> > > > > > > > > I've created a branch of the branch_3x branch on my fork
> and
> > > will
> > > > > > begin
> > > > > > > > > working on bringing the Analysis namespace up to speed to
> > > 3.6.2.
> > > > If
> > > > > > > > anyone
> > > > > > > > > wants to pull it or just reuse parts once I'm done, have at
> > it.
> > > > > > > > >
> > > > > > > > > If I shouldn't have branched off the branch_3x branch,
> please
> > > let
> > > > > me
> > > > > > > know
> > > > > > > > > what I should have branched from (trunk?)
> > > > > > > > >
> > > > > > > > > Paul
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <
> > > > > > itamar@code972.com
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > Thanks Prescott for bringing this up again :)
> > > > > > > > > >
> > > > > > > > > > Paul, the problem is no one can really know what it would
> > > take
> > > > > > until
> > > > > > > > they
> > > > > > > > > > have deep dived into the work, and even then decisions
> > could
> > > > and
> > > > > > will
> > > > > > > > > > change. I will strongly advise against starting from
> > scratch,
> > > > > > > although
> > > > > > > > I
> > > > > > > > > do
> > > > > > > > > > think a lot in the current structure should change, but
> its
> > > > going
> > > > > > to
> > > > > > > be
> > > > > > > > > > much easier to change it in place, refactoring where
> > needed,
> > > > than
> > > > > > > > > starting
> > > > > > > > > > all over again. Once we kicked this off I personally will
> > be
> > > > > happy
> > > > > > > with
> > > > > > > > > you
> > > > > > > > > > taking the analysis part of Lucene and porting it, its
> > pretty
> > > > > much
> > > > > > > self
> > > > > > > > > > contained.
> > > > > > > > > > Re 3.6.2 work - you can just do that on a fork and send
> us
> > > PRs,
> > > > > its
> > > > > > > > much
> > > > > > > > > > more straight forward than the v4 upgrade
> > > > > > > > > >
> > > > > > > > > > Marcos, porting class by class is the fastest way to do
> > this,
> > > > we
> > > > > > can
> > > > > > > > then
> > > > > > > > > > concentrate on .NETifying and optimizing using .NET
> > > constructs.
> > > > > > > > > >
> > > > > > > > > > That said, I think the way to go is create a branch out
> of
> > > the
> > > > > > > current
> > > > > > > > > git
> > > > > > > > > > master HEAD and label it "3.x", and start working on
> master
> > > > > > towards a
> > > > > > > > 4.3
> > > > > > > > > > compatible version. The actual port should be using a
> > process
> > > > > that
> > > > > > > > > ensures
> > > > > > > > > > all Java classes are ported with their tests, and that
> > those
> > > > > tests
> > > > > > > > pass -
> > > > > > > > > > but I'm against committing any Java code to our
> > repositories.
> > > > The
> > > > > > > > process
> > > > > > > > > > should probably be working on classes in some order
> > > > > > (alphabetically,
> > > > > > > or
> > > > > > > > > > core classes first) and getting each class to compile
> > before
> > > > > moving
> > > > > > > > > > forward. I don't mind about the project not being
> > compilable
> > > > for
> > > > > a
> > > > > > > > month
> > > > > > > > > or
> > > > > > > > > > two.
> > > > > > > > > > Once this is done a process of .NETifying and proofing
> the
> > > code
> > > > > can
> > > > > > > be
> > > > > > > > > > started, at which point we will already have a working v4
> > > > version
> > > > > > so
> > > > > > > it
> > > > > > > > > > will be easier to keep up with the Java project.
> > > > > > > > > >
> > > > > > > > > > The first step IMO is to stabilize the test suite so
> tests
> > > > could
> > > > > > more
> > > > > > > > or
> > > > > > > > > > less be copied and pasted (e.g. implementing Java-like
> > > > > assertEquals
> > > > > > > > > methods
> > > > > > > > > > etc; I find xUnit to be much easier to work with than
> > > NUnit). I
> > > > > > > already
> > > > > > > > > did
> > > > > > > > > > some work there but there's still a lot to do.
> > > > > > > > > >
> > > > > > > > > > Unfortunately I can't dedicate time myself at this point,
> > > but I
> > > > > > > should
> > > > > > > > be
> > > > > > > > > > back in business in August, at which point I can dedicate
> > > > several
> > > > > > > > hours a
> > > > > > > > > > week. Until then I'll be happy to watch closely and even
> > > > > coordinate
> > > > > > > the
> > > > > > > > > > work to some extent.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > > > > > > marcoslimagon@gmail.com
> > > > > > > > > > >wrote:
> > > > > > > > > >
> > > > > > > > > > > It really sounds good to me, this is a kick start =). I
> > > > haven't
> > > > > > > > > > contributed
> > > > > > > > > > > anything
> > > > > > > > > > > yet, but I would like to help you all to get this job
> > done.
> > > > > > > > > > >
> > > > > > > > > > > I'm completely agree with Paul and Prescott.
> > > > > > > > > > >
> > > > > > > > > > > I know that there is a high commitment for keep the
> > > > > > > > retrocompatibility
> > > > > > > > > on
> > > > > > > > > > > Lucene. Does Java Lucene API gets big changes every
> > > release?
> > > > > > > > > > >
> > > > > > > > > > > Is the Lucene.Net a port from a stable version from a
> > > Lucene
> > > > > > > version,
> > > > > > > > > > > right? If the Lucene API gets only minor changes every
> > > stable
> > > > > > > release
> > > > > > > > > (or
> > > > > > > > > > > keep most of its source-code), we could compare the
> > > versions,
> > > > > > check
> > > > > > > > the
> > > > > > > > > > > differences and bring them to Lucene.Net. Again, I
> > haven't
> > > > > > > > contributed
> > > > > > > > > > with
> > > > > > > > > > > yet, so I don't know how it is (just an idea).
> > > > > > > > > > >
> > > > > > > > > > > What's your approach for implement simple performance
> > > > > > improvements
> > > > > > > > > > (without
> > > > > > > > > > > adding references or changing methods signatures)? Does
> > it
> > > > > could
> > > > > > be
> > > > > > > > > done,
> > > > > > > > > > > or "follow the java version only"?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > > > > > > > > >
> > > > > > > > > > > > This is just an "outsider" suggestion as I haven't
> > > > > contributed
> > > > > > > > > anything
> > > > > > > > > > > > yet, although I will definitely help with the 4.x
> work
> > > as I
> > > > > > have
> > > > > > > a
> > > > > > > > > > vested
> > > > > > > > > > > > interest in seeing that get completed. I think there
> > > should
> > > > > be
> > > > > > > one
> > > > > > > > > > person
> > > > > > > > > > > > (or perhaps two) guiding what the structure and
> > workflow
> > > > will
> > > > > > > look
> > > > > > > > > like
> > > > > > > > > > > to
> > > > > > > > > > > > avoid chaos. If the 4.x work is going to be starting
> > from
> > > > > > scratch
> > > > > > > > as
> > > > > > > > > a
> > > > > > > > > > > > fresh port, that person should set up the project,
> get
> > > > > > everything
> > > > > > > > > going
> > > > > > > > > > > in
> > > > > > > > > > > > source control, create the folder structure, maybe
> stub
> > > out
> > > > > > some
> > > > > > > > > > classes,
> > > > > > > > > > > > etc. Then divide and conquer with anyone interested
> in
> > > > > > > > contributing,
> > > > > > > > > > > > perhaps by namespace.
> > > > > > > > > > > >
> > > > > > > > > > > > I like the idea of throwing the java code in there so
> > > it's
> > > > > easy
> > > > > > > to
> > > > > > > > > > > > reference.
> > > > > > > > > > > >
> > > > > > > > > > > > Again, I can work on Lucene.Net.Documents,
> > > > > Lucene.Net.Analysis,
> > > > > > > or
> > > > > > > > > > > > Lucene.Net.Store -- or any others, those are just the
> > > ones
> > > > > I'm
> > > > > > > most
> > > > > > > > > > > > familiar with the inner workings. Tell me what to do
> > and
> > > > I'll
> > > > > > get
> > > > > > > > > > started
> > > > > > > > > > > > on my fork.
> > > > > > > > > > > >
> > > > > > > > > > > > Paul Irwin
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > > > > > > > > geobmx540@hotmail.com
> > > > > > > > > > > > >wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hey guys -
> > > > > > > > > > > > > I know I've been MIA a little while. We have a
> board
> > > > report
> > > > > > due
> > > > > > > > > soon
> > > > > > > > > > -
> > > > > > > > > > > I
> > > > > > > > > > > > > think it prudent that we advise them that we seem
> to
> > > have
> > > > > > > stalled
> > > > > > > > > > > > somewhat.
> > > > > > > > > > > > > We've got a few low hanging items out of of jira
> and
> > > have
> > > > > > been
> > > > > > > > > > > responsive
> > > > > > > > > > > > > on the mailing list to community questions, but I
> > don't
> > > > > think
> > > > > > > > we've
> > > > > > > > > > > done
> > > > > > > > > > > > > anything to move forward with 4.0.
> > > > > > > > > > > > > To that end - I'd like to *try* and start us back
> up
> > > > moving
> > > > > > > > > forward.
> > > > > > > > > > > What
> > > > > > > > > > > > > is the best way to accomplish this? If we took the
> > java
> > > > > > lucene
> > > > > > > > 4.0
> > > > > > > > > > code
> > > > > > > > > > > > and
> > > > > > > > > > > > > committed that java to our branch and then just let
> > > > people
> > > > > > pull
> > > > > > > > > that
> > > > > > > > > > > down
> > > > > > > > > > > > > and being changing / modifying is that one way to
> > maybe
> > > > > make
> > > > > > > some
> > > > > > > > > > > forward
> > > > > > > > > > > > > progress?
> > > > > > > > > > > > > ~P
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > --
> > > > > > > > > > > Marcos Lima
> > > > > > > > > > > Software Developer/Tech Lead
> > > > > > > > > > > marcoslimagon@gmail.com
> > > > > > > > > > > tel: +55 (19) 9798-9335
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > --
> > Marcos Lima
> > Software Developer/Tech Lead
> > marcoslimagon@gmail.com
> > tel: +55 (19) 9798-9335
> >
>
Re: Lucene 4.0
Posted by mherndon michael <mh...@michaelherndon.com>.
the guithub.com repo is a mirror to the git mirror that apache maintains.
The was some work at one time to move the official svn repository to start
using git one instead. Was that actually finalized or not?
The Lucene.Net_4e (e for experimental) is an old branch to see what kind of
work was involved using a portable libraries project. Some of it can still
be used but will need to be validated against the current version of Java's
Lucene. It was also using .net 4.
clean branch vs current. Its going to depend on what we support. If you
support windows mobile 8, win RT, then the current code in trunk will not
compile against those versions of the framework which would a frustrating
starting point, then you couldn't even run tests, which would make taking
patches very difficult. Supporting those can almost mean larger gaps in
design between Lucene.Net and its parent project.
Also the structure has changed significantly between the branches and the
side of the code base of Lucene 4 is bigger, uses Java 6, and seems
significantly different. That doesn't mean you can't cherry pick stuff
from the other tags/branches that would still work as is. A clean branch
would also make it easier to get our build / tool chain in order as you can
then do them incrementally versus having to do all the stuff that I did for
the 3x branch which saps energy and desire to code. It could also make it
easier to see which classes have been ported or not.
The major downside to a clean branch is extra work it requires and the
start up cost in time and energy of getting it in order, which can be
daunting / intimidating and lower morale. And generally you want to use
take your legacy code and refactor instead of in someways starting over.
Are we going to port lucene 4 or 4.3 ? If so I can do something similar
to
https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
where it tracks what needs to get ported / what has been ported.
What are we going to support in the next version?
Who is going to work on the next version?
What would make the most sense and what would invigorate the community to
get involved more and lower the barrier to entry?
I think those are the questions that would make a lot of the decisions for
us so that we can get back to work on lucene.net.
On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <ma...@gmail.com>wrote:
> Regarding the new branch, I'm a rookie with ASF projects...
>
> The https://svn.apache.org/repos/asf/lucene.net/ and
> https://github.com/apache/lucene.net points to the same repository? (This
> is new for me, pretty good) Which of them do you recommend (i'm used with
> SVN and its patterns).
>
> I'm checking the subversion right now.
>
> I can see the branches/Lucene.Net_4e. I think this is a old branch, i`m not
> sure about its current status.
>
> Will we wipe the current solution from /trunk and start a new one?
>
> Thanks,
>
>
>
>
> 2013/6/6 mherndon michael <mh...@michaelherndon.com>
>
> > We may be forced to start with a clean/empty branch if people still want
> to
> > attempt supporting lucene.net for mobile devices, win RT, etc. The are
> > many
> > classes that Lucene.net uses from the full framework that would not be
> > accessible in other versions of the .NET Framework. It also might
> require
> > a design that differs even more from its parent project.
> >
> > It might be wise to poll what users most desire in the next version
> through
> > jira or user voice.
> >
> >
> > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > inline
> > >
> > >
> > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> > >
> > > > Ah, I gotcha. Still getting used to git, I've been a TFS guy for so
> > long
> > > > :-)
> > > >
> > > > So to recap, the branch_3x will be used for any patches or anything
> to
> > > the
> > > > current 3.0.3 release, while trunk is what we will branch from for 4x
> > > dev.
> > > > Correct?
> > > >
> > >
> > > Yes - we can branch from it for 3.6 development if anyone will be
> > > interested in that
> > >
> > >
> > > >
> > > > Thanks for pushing the Version.cs. What's the deal with the github
> > sync?
> > > > Who could diagnose that?
> > > >
> > >
> > > Not sure, Apache Infra, basically. Just use the apache repo for now
> while
> > > we get that sorted out.
> > >
> > >
> > > >
> > > >
> > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> itamar@code972.com
> > > > >wrote:
> > > >
> > > > > Ok, haven't noticed that branch. Just use it then for 3.x
> > development.
> > > > WRT
> > > > > v4, yeah - just fork the repo and work on whatever branch. When you
> > > send
> > > > us
> > > > > PRs we will merge either to master or to a dedicated repo. For now
> it
> > > > > doesn't really matter, thats the beauty of git.
> > > > >
> > > > > I pushed a new Version.cs file, you should see it on the apache
> > servers
> > > > > (github sync seems to be off)
> > > > >
> > > > >
> > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <pi...@feature23.com>
> > > > wrote:
> > > > >
> > > > > > Thanks Itamar. I can certainly start work on 4.3 version of the
> > > > Analysis
> > > > > > namespace.
> > > > > >
> > > > > > Not sure the checkout command is what you intended -- you might
> > have
> > > > > meant
> > > > > > trunk instead of master, and that would create a new "3x" branch,
> > > when
> > > > > > there's already a "branch_3x" and that would be misnamed... so
> > maybe
> > > > > > checkout -b branch_4x trunk and start there aiming for lucene
> 4.3.x
> > > > > > compatibility?
> > > > > >
> > > > > > Also, does someone with commit rights to the upstream want to
> > create
> > > > the
> > > > > > necessary Version.cs entries, so that we're not all trying to
> > create
> > > > them
> > > > > > and dealing with a merge?
> > > > > >
> > > > > > Paul
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> > > itamar@code972.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Unless people here have a specific reason to use 3.6.2 I would
> > > highly
> > > > > > > recommed putting all the efforts we can towards v4 otherwise we
> > > will
> > > > > > never
> > > > > > > make it...
> > > > > > >
> > > > > > > Fork the repo from apache servers or github (same repo,
> different
> > > > > > remotes)
> > > > > > > and checkout -b 3x -t origin/master , that should work
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> > pirwin@feature23.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Itamar,
> > > > > > > >
> > > > > > > > I agree that from scratch is not the best way to do it, I
> just
> > > > > thought
> > > > > > > that
> > > > > > > > was the "decision" that was made from the discussion
> previously
> > > for
> > > > > the
> > > > > > > 4.x
> > > > > > > > work. An incremental approach will be much better.
> > > > > > > >
> > > > > > > > I've created a branch of the branch_3x branch on my fork and
> > will
> > > > > begin
> > > > > > > > working on bringing the Analysis namespace up to speed to
> > 3.6.2.
> > > If
> > > > > > > anyone
> > > > > > > > wants to pull it or just reuse parts once I'm done, have at
> it.
> > > > > > > >
> > > > > > > > If I shouldn't have branched off the branch_3x branch, please
> > let
> > > > me
> > > > > > know
> > > > > > > > what I should have branched from (trunk?)
> > > > > > > >
> > > > > > > > Paul
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <
> > > > > itamar@code972.com
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > Thanks Prescott for bringing this up again :)
> > > > > > > > >
> > > > > > > > > Paul, the problem is no one can really know what it would
> > take
> > > > > until
> > > > > > > they
> > > > > > > > > have deep dived into the work, and even then decisions
> could
> > > and
> > > > > will
> > > > > > > > > change. I will strongly advise against starting from
> scratch,
> > > > > > although
> > > > > > > I
> > > > > > > > do
> > > > > > > > > think a lot in the current structure should change, but its
> > > going
> > > > > to
> > > > > > be
> > > > > > > > > much easier to change it in place, refactoring where
> needed,
> > > than
> > > > > > > > starting
> > > > > > > > > all over again. Once we kicked this off I personally will
> be
> > > > happy
> > > > > > with
> > > > > > > > you
> > > > > > > > > taking the analysis part of Lucene and porting it, its
> pretty
> > > > much
> > > > > > self
> > > > > > > > > contained.
> > > > > > > > > Re 3.6.2 work - you can just do that on a fork and send us
> > PRs,
> > > > its
> > > > > > > much
> > > > > > > > > more straight forward than the v4 upgrade
> > > > > > > > >
> > > > > > > > > Marcos, porting class by class is the fastest way to do
> this,
> > > we
> > > > > can
> > > > > > > then
> > > > > > > > > concentrate on .NETifying and optimizing using .NET
> > constructs.
> > > > > > > > >
> > > > > > > > > That said, I think the way to go is create a branch out of
> > the
> > > > > > current
> > > > > > > > git
> > > > > > > > > master HEAD and label it "3.x", and start working on master
> > > > > towards a
> > > > > > > 4.3
> > > > > > > > > compatible version. The actual port should be using a
> process
> > > > that
> > > > > > > > ensures
> > > > > > > > > all Java classes are ported with their tests, and that
> those
> > > > tests
> > > > > > > pass -
> > > > > > > > > but I'm against committing any Java code to our
> repositories.
> > > The
> > > > > > > process
> > > > > > > > > should probably be working on classes in some order
> > > > > (alphabetically,
> > > > > > or
> > > > > > > > > core classes first) and getting each class to compile
> before
> > > > moving
> > > > > > > > > forward. I don't mind about the project not being
> compilable
> > > for
> > > > a
> > > > > > > month
> > > > > > > > or
> > > > > > > > > two.
> > > > > > > > > Once this is done a process of .NETifying and proofing the
> > code
> > > > can
> > > > > > be
> > > > > > > > > started, at which point we will already have a working v4
> > > version
> > > > > so
> > > > > > it
> > > > > > > > > will be easier to keep up with the Java project.
> > > > > > > > >
> > > > > > > > > The first step IMO is to stabilize the test suite so tests
> > > could
> > > > > more
> > > > > > > or
> > > > > > > > > less be copied and pasted (e.g. implementing Java-like
> > > > assertEquals
> > > > > > > > methods
> > > > > > > > > etc; I find xUnit to be much easier to work with than
> > NUnit). I
> > > > > > already
> > > > > > > > did
> > > > > > > > > some work there but there's still a lot to do.
> > > > > > > > >
> > > > > > > > > Unfortunately I can't dedicate time myself at this point,
> > but I
> > > > > > should
> > > > > > > be
> > > > > > > > > back in business in August, at which point I can dedicate
> > > several
> > > > > > > hours a
> > > > > > > > > week. Until then I'll be happy to watch closely and even
> > > > coordinate
> > > > > > the
> > > > > > > > > work to some extent.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > > > > > marcoslimagon@gmail.com
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > It really sounds good to me, this is a kick start =). I
> > > haven't
> > > > > > > > > contributed
> > > > > > > > > > anything
> > > > > > > > > > yet, but I would like to help you all to get this job
> done.
> > > > > > > > > >
> > > > > > > > > > I'm completely agree with Paul and Prescott.
> > > > > > > > > >
> > > > > > > > > > I know that there is a high commitment for keep the
> > > > > > > retrocompatibility
> > > > > > > > on
> > > > > > > > > > Lucene. Does Java Lucene API gets big changes every
> > release?
> > > > > > > > > >
> > > > > > > > > > Is the Lucene.Net a port from a stable version from a
> > Lucene
> > > > > > version,
> > > > > > > > > > right? If the Lucene API gets only minor changes every
> > stable
> > > > > > release
> > > > > > > > (or
> > > > > > > > > > keep most of its source-code), we could compare the
> > versions,
> > > > > check
> > > > > > > the
> > > > > > > > > > differences and bring them to Lucene.Net. Again, I
> haven't
> > > > > > > contributed
> > > > > > > > > with
> > > > > > > > > > yet, so I don't know how it is (just an idea).
> > > > > > > > > >
> > > > > > > > > > What's your approach for implement simple performance
> > > > > improvements
> > > > > > > > > (without
> > > > > > > > > > adding references or changing methods signatures)? Does
> it
> > > > could
> > > > > be
> > > > > > > > done,
> > > > > > > > > > or "follow the java version only"?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > > > > > > > >
> > > > > > > > > > > This is just an "outsider" suggestion as I haven't
> > > > contributed
> > > > > > > > anything
> > > > > > > > > > > yet, although I will definitely help with the 4.x work
> > as I
> > > > > have
> > > > > > a
> > > > > > > > > vested
> > > > > > > > > > > interest in seeing that get completed. I think there
> > should
> > > > be
> > > > > > one
> > > > > > > > > person
> > > > > > > > > > > (or perhaps two) guiding what the structure and
> workflow
> > > will
> > > > > > look
> > > > > > > > like
> > > > > > > > > > to
> > > > > > > > > > > avoid chaos. If the 4.x work is going to be starting
> from
> > > > > scratch
> > > > > > > as
> > > > > > > > a
> > > > > > > > > > > fresh port, that person should set up the project, get
> > > > > everything
> > > > > > > > going
> > > > > > > > > > in
> > > > > > > > > > > source control, create the folder structure, maybe stub
> > out
> > > > > some
> > > > > > > > > classes,
> > > > > > > > > > > etc. Then divide and conquer with anyone interested in
> > > > > > > contributing,
> > > > > > > > > > > perhaps by namespace.
> > > > > > > > > > >
> > > > > > > > > > > I like the idea of throwing the java code in there so
> > it's
> > > > easy
> > > > > > to
> > > > > > > > > > > reference.
> > > > > > > > > > >
> > > > > > > > > > > Again, I can work on Lucene.Net.Documents,
> > > > Lucene.Net.Analysis,
> > > > > > or
> > > > > > > > > > > Lucene.Net.Store -- or any others, those are just the
> > ones
> > > > I'm
> > > > > > most
> > > > > > > > > > > familiar with the inner workings. Tell me what to do
> and
> > > I'll
> > > > > get
> > > > > > > > > started
> > > > > > > > > > > on my fork.
> > > > > > > > > > >
> > > > > > > > > > > Paul Irwin
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > > > > > > > geobmx540@hotmail.com
> > > > > > > > > > > >wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hey guys -
> > > > > > > > > > > > I know I've been MIA a little while. We have a board
> > > report
> > > > > due
> > > > > > > > soon
> > > > > > > > > -
> > > > > > > > > > I
> > > > > > > > > > > > think it prudent that we advise them that we seem to
> > have
> > > > > > stalled
> > > > > > > > > > > somewhat.
> > > > > > > > > > > > We've got a few low hanging items out of of jira and
> > have
> > > > > been
> > > > > > > > > > responsive
> > > > > > > > > > > > on the mailing list to community questions, but I
> don't
> > > > think
> > > > > > > we've
> > > > > > > > > > done
> > > > > > > > > > > > anything to move forward with 4.0.
> > > > > > > > > > > > To that end - I'd like to *try* and start us back up
> > > moving
> > > > > > > > forward.
> > > > > > > > > > What
> > > > > > > > > > > > is the best way to accomplish this? If we took the
> java
> > > > > lucene
> > > > > > > 4.0
> > > > > > > > > code
> > > > > > > > > > > and
> > > > > > > > > > > > committed that java to our branch and then just let
> > > people
> > > > > pull
> > > > > > > > that
> > > > > > > > > > down
> > > > > > > > > > > > and being changing / modifying is that one way to
> maybe
> > > > make
> > > > > > some
> > > > > > > > > > forward
> > > > > > > > > > > > progress?
> > > > > > > > > > > > ~P
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > --
> > > > > > > > > > Marcos Lima
> > > > > > > > > > Software Developer/Tech Lead
> > > > > > > > > > marcoslimagon@gmail.com
> > > > > > > > > > tel: +55 (19) 9798-9335
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> --
> Marcos Lima
> Software Developer/Tech Lead
> marcoslimagon@gmail.com
> tel: +55 (19) 9798-9335
>
Re: Lucene 4.0
Posted by Marcos Lima <ma...@gmail.com>.
Regarding the new branch, I'm a rookie with ASF projects...
The https://svn.apache.org/repos/asf/lucene.net/ and
https://github.com/apache/lucene.net points to the same repository? (This
is new for me, pretty good) Which of them do you recommend (i'm used with
SVN and its patterns).
I'm checking the subversion right now.
I can see the branches/Lucene.Net_4e. I think this is a old branch, i`m not
sure about its current status.
Will we wipe the current solution from /trunk and start a new one?
Thanks,
2013/6/6 mherndon michael <mh...@michaelherndon.com>
> We may be forced to start with a clean/empty branch if people still want to
> attempt supporting lucene.net for mobile devices, win RT, etc. The are
> many
> classes that Lucene.net uses from the full framework that would not be
> accessible in other versions of the .NET Framework. It also might require
> a design that differs even more from its parent project.
>
> It might be wise to poll what users most desire in the next version through
> jira or user voice.
>
>
> On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > inline
> >
> >
> > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <pi...@feature23.com> wrote:
> >
> > > Ah, I gotcha. Still getting used to git, I've been a TFS guy for so
> long
> > > :-)
> > >
> > > So to recap, the branch_3x will be used for any patches or anything to
> > the
> > > current 3.0.3 release, while trunk is what we will branch from for 4x
> > dev.
> > > Correct?
> > >
> >
> > Yes - we can branch from it for 3.6 development if anyone will be
> > interested in that
> >
> >
> > >
> > > Thanks for pushing the Version.cs. What's the deal with the github
> sync?
> > > Who could diagnose that?
> > >
> >
> > Not sure, Apache Infra, basically. Just use the apache repo for now while
> > we get that sorted out.
> >
> >
> > >
> > >
> > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <itamar@code972.com
> > > >wrote:
> > >
> > > > Ok, haven't noticed that branch. Just use it then for 3.x
> development.
> > > WRT
> > > > v4, yeah - just fork the repo and work on whatever branch. When you
> > send
> > > us
> > > > PRs we will merge either to master or to a dedicated repo. For now it
> > > > doesn't really matter, thats the beauty of git.
> > > >
> > > > I pushed a new Version.cs file, you should see it on the apache
> servers
> > > > (github sync seems to be off)
> > > >
> > > >
> > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <pi...@feature23.com>
> > > wrote:
> > > >
> > > > > Thanks Itamar. I can certainly start work on 4.3 version of the
> > > Analysis
> > > > > namespace.
> > > > >
> > > > > Not sure the checkout command is what you intended -- you might
> have
> > > > meant
> > > > > trunk instead of master, and that would create a new "3x" branch,
> > when
> > > > > there's already a "branch_3x" and that would be misnamed... so
> maybe
> > > > > checkout -b branch_4x trunk and start there aiming for lucene 4.3.x
> > > > > compatibility?
> > > > >
> > > > > Also, does someone with commit rights to the upstream want to
> create
> > > the
> > > > > necessary Version.cs entries, so that we're not all trying to
> create
> > > them
> > > > > and dealing with a merge?
> > > > >
> > > > > Paul
> > > > >
> > > > >
> > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> > itamar@code972.com
> > > > > >wrote:
> > > > >
> > > > > > Unless people here have a specific reason to use 3.6.2 I would
> > highly
> > > > > > recommed putting all the efforts we can towards v4 otherwise we
> > will
> > > > > never
> > > > > > make it...
> > > > > >
> > > > > > Fork the repo from apache servers or github (same repo, different
> > > > > remotes)
> > > > > > and checkout -b 3x -t origin/master , that should work
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <
> pirwin@feature23.com>
> > > > > wrote:
> > > > > >
> > > > > > > Itamar,
> > > > > > >
> > > > > > > I agree that from scratch is not the best way to do it, I just
> > > > thought
> > > > > > that
> > > > > > > was the "decision" that was made from the discussion previously
> > for
> > > > the
> > > > > > 4.x
> > > > > > > work. An incremental approach will be much better.
> > > > > > >
> > > > > > > I've created a branch of the branch_3x branch on my fork and
> will
> > > > begin
> > > > > > > working on bringing the Analysis namespace up to speed to
> 3.6.2.
> > If
> > > > > > anyone
> > > > > > > wants to pull it or just reuse parts once I'm done, have at it.
> > > > > > >
> > > > > > > If I shouldn't have branched off the branch_3x branch, please
> let
> > > me
> > > > > know
> > > > > > > what I should have branched from (trunk?)
> > > > > > >
> > > > > > > Paul
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <
> > > > itamar@code972.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Thanks Prescott for bringing this up again :)
> > > > > > > >
> > > > > > > > Paul, the problem is no one can really know what it would
> take
> > > > until
> > > > > > they
> > > > > > > > have deep dived into the work, and even then decisions could
> > and
> > > > will
> > > > > > > > change. I will strongly advise against starting from scratch,
> > > > > although
> > > > > > I
> > > > > > > do
> > > > > > > > think a lot in the current structure should change, but its
> > going
> > > > to
> > > > > be
> > > > > > > > much easier to change it in place, refactoring where needed,
> > than
> > > > > > > starting
> > > > > > > > all over again. Once we kicked this off I personally will be
> > > happy
> > > > > with
> > > > > > > you
> > > > > > > > taking the analysis part of Lucene and porting it, its pretty
> > > much
> > > > > self
> > > > > > > > contained.
> > > > > > > > Re 3.6.2 work - you can just do that on a fork and send us
> PRs,
> > > its
> > > > > > much
> > > > > > > > more straight forward than the v4 upgrade
> > > > > > > >
> > > > > > > > Marcos, porting class by class is the fastest way to do this,
> > we
> > > > can
> > > > > > then
> > > > > > > > concentrate on .NETifying and optimizing using .NET
> constructs.
> > > > > > > >
> > > > > > > > That said, I think the way to go is create a branch out of
> the
> > > > > current
> > > > > > > git
> > > > > > > > master HEAD and label it "3.x", and start working on master
> > > > towards a
> > > > > > 4.3
> > > > > > > > compatible version. The actual port should be using a process
> > > that
> > > > > > > ensures
> > > > > > > > all Java classes are ported with their tests, and that those
> > > tests
> > > > > > pass -
> > > > > > > > but I'm against committing any Java code to our repositories.
> > The
> > > > > > process
> > > > > > > > should probably be working on classes in some order
> > > > (alphabetically,
> > > > > or
> > > > > > > > core classes first) and getting each class to compile before
> > > moving
> > > > > > > > forward. I don't mind about the project not being compilable
> > for
> > > a
> > > > > > month
> > > > > > > or
> > > > > > > > two.
> > > > > > > > Once this is done a process of .NETifying and proofing the
> code
> > > can
> > > > > be
> > > > > > > > started, at which point we will already have a working v4
> > version
> > > > so
> > > > > it
> > > > > > > > will be easier to keep up with the Java project.
> > > > > > > >
> > > > > > > > The first step IMO is to stabilize the test suite so tests
> > could
> > > > more
> > > > > > or
> > > > > > > > less be copied and pasted (e.g. implementing Java-like
> > > assertEquals
> > > > > > > methods
> > > > > > > > etc; I find xUnit to be much easier to work with than
> NUnit). I
> > > > > already
> > > > > > > did
> > > > > > > > some work there but there's still a lot to do.
> > > > > > > >
> > > > > > > > Unfortunately I can't dedicate time myself at this point,
> but I
> > > > > should
> > > > > > be
> > > > > > > > back in business in August, at which point I can dedicate
> > several
> > > > > > hours a
> > > > > > > > week. Until then I'll be happy to watch closely and even
> > > coordinate
> > > > > the
> > > > > > > > work to some extent.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > > > > marcoslimagon@gmail.com
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > It really sounds good to me, this is a kick start =). I
> > haven't
> > > > > > > > contributed
> > > > > > > > > anything
> > > > > > > > > yet, but I would like to help you all to get this job done.
> > > > > > > > >
> > > > > > > > > I'm completely agree with Paul and Prescott.
> > > > > > > > >
> > > > > > > > > I know that there is a high commitment for keep the
> > > > > > retrocompatibility
> > > > > > > on
> > > > > > > > > Lucene. Does Java Lucene API gets big changes every
> release?
> > > > > > > > >
> > > > > > > > > Is the Lucene.Net a port from a stable version from a
> Lucene
> > > > > version,
> > > > > > > > > right? If the Lucene API gets only minor changes every
> stable
> > > > > release
> > > > > > > (or
> > > > > > > > > keep most of its source-code), we could compare the
> versions,
> > > > check
> > > > > > the
> > > > > > > > > differences and bring them to Lucene.Net. Again, I haven't
> > > > > > contributed
> > > > > > > > with
> > > > > > > > > yet, so I don't know how it is (just an idea).
> > > > > > > > >
> > > > > > > > > What's your approach for implement simple performance
> > > > improvements
> > > > > > > > (without
> > > > > > > > > adding references or changing methods signatures)? Does it
> > > could
> > > > be
> > > > > > > done,
> > > > > > > > > or "follow the java version only"?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > > > > > > >
> > > > > > > > > > This is just an "outsider" suggestion as I haven't
> > > contributed
> > > > > > > anything
> > > > > > > > > > yet, although I will definitely help with the 4.x work
> as I
> > > > have
> > > > > a
> > > > > > > > vested
> > > > > > > > > > interest in seeing that get completed. I think there
> should
> > > be
> > > > > one
> > > > > > > > person
> > > > > > > > > > (or perhaps two) guiding what the structure and workflow
> > will
> > > > > look
> > > > > > > like
> > > > > > > > > to
> > > > > > > > > > avoid chaos. If the 4.x work is going to be starting from
> > > > scratch
> > > > > > as
> > > > > > > a
> > > > > > > > > > fresh port, that person should set up the project, get
> > > > everything
> > > > > > > going
> > > > > > > > > in
> > > > > > > > > > source control, create the folder structure, maybe stub
> out
> > > > some
> > > > > > > > classes,
> > > > > > > > > > etc. Then divide and conquer with anyone interested in
> > > > > > contributing,
> > > > > > > > > > perhaps by namespace.
> > > > > > > > > >
> > > > > > > > > > I like the idea of throwing the java code in there so
> it's
> > > easy
> > > > > to
> > > > > > > > > > reference.
> > > > > > > > > >
> > > > > > > > > > Again, I can work on Lucene.Net.Documents,
> > > Lucene.Net.Analysis,
> > > > > or
> > > > > > > > > > Lucene.Net.Store -- or any others, those are just the
> ones
> > > I'm
> > > > > most
> > > > > > > > > > familiar with the inner workings. Tell me what to do and
> > I'll
> > > > get
> > > > > > > > started
> > > > > > > > > > on my fork.
> > > > > > > > > >
> > > > > > > > > > Paul Irwin
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > > > > > > geobmx540@hotmail.com
> > > > > > > > > > >wrote:
> > > > > > > > > >
> > > > > > > > > > > Hey guys -
> > > > > > > > > > > I know I've been MIA a little while. We have a board
> > report
> > > > due
> > > > > > > soon
> > > > > > > > -
> > > > > > > > > I
> > > > > > > > > > > think it prudent that we advise them that we seem to
> have
> > > > > stalled
> > > > > > > > > > somewhat.
> > > > > > > > > > > We've got a few low hanging items out of of jira and
> have
> > > > been
> > > > > > > > > responsive
> > > > > > > > > > > on the mailing list to community questions, but I don't
> > > think
> > > > > > we've
> > > > > > > > > done
> > > > > > > > > > > anything to move forward with 4.0.
> > > > > > > > > > > To that end - I'd like to *try* and start us back up
> > moving
> > > > > > > forward.
> > > > > > > > > What
> > > > > > > > > > > is the best way to accomplish this? If we took the java
> > > > lucene
> > > > > > 4.0
> > > > > > > > code
> > > > > > > > > > and
> > > > > > > > > > > committed that java to our branch and then just let
> > people
> > > > pull
> > > > > > > that
> > > > > > > > > down
> > > > > > > > > > > and being changing / modifying is that one way to maybe
> > > make
> > > > > some
> > > > > > > > > forward
> > > > > > > > > > > progress?
> > > > > > > > > > > ~P
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > --
> > > > > > > > > Marcos Lima
> > > > > > > > > Software Developer/Tech Lead
> > > > > > > > > marcoslimagon@gmail.com
> > > > > > > > > tel: +55 (19) 9798-9335
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
--
--
Marcos Lima
Software Developer/Tech Lead
marcoslimagon@gmail.com
tel: +55 (19) 9798-9335
Re: Lucene 4.0
Posted by mherndon michael <mh...@michaelherndon.com>.
We may be forced to start with a clean/empty branch if people still want to
attempt supporting lucene.net for mobile devices, win RT, etc. The are many
classes that Lucene.net uses from the full framework that would not be
accessible in other versions of the .NET Framework. It also might require
a design that differs even more from its parent project.
It might be wise to poll what users most desire in the next version through
jira or user voice.
On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <it...@code972.com>wrote:
> inline
>
>
> On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <pi...@feature23.com> wrote:
>
> > Ah, I gotcha. Still getting used to git, I've been a TFS guy for so long
> > :-)
> >
> > So to recap, the branch_3x will be used for any patches or anything to
> the
> > current 3.0.3 release, while trunk is what we will branch from for 4x
> dev.
> > Correct?
> >
>
> Yes - we can branch from it for 3.6 development if anyone will be
> interested in that
>
>
> >
> > Thanks for pushing the Version.cs. What's the deal with the github sync?
> > Who could diagnose that?
> >
>
> Not sure, Apache Infra, basically. Just use the apache repo for now while
> we get that sorted out.
>
>
> >
> >
> > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > Ok, haven't noticed that branch. Just use it then for 3.x development.
> > WRT
> > > v4, yeah - just fork the repo and work on whatever branch. When you
> send
> > us
> > > PRs we will merge either to master or to a dedicated repo. For now it
> > > doesn't really matter, thats the beauty of git.
> > >
> > > I pushed a new Version.cs file, you should see it on the apache servers
> > > (github sync seems to be off)
> > >
> > >
> > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <pi...@feature23.com>
> > wrote:
> > >
> > > > Thanks Itamar. I can certainly start work on 4.3 version of the
> > Analysis
> > > > namespace.
> > > >
> > > > Not sure the checkout command is what you intended -- you might have
> > > meant
> > > > trunk instead of master, and that would create a new "3x" branch,
> when
> > > > there's already a "branch_3x" and that would be misnamed... so maybe
> > > > checkout -b branch_4x trunk and start there aiming for lucene 4.3.x
> > > > compatibility?
> > > >
> > > > Also, does someone with commit rights to the upstream want to create
> > the
> > > > necessary Version.cs entries, so that we're not all trying to create
> > them
> > > > and dealing with a merge?
> > > >
> > > > Paul
> > > >
> > > >
> > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <
> itamar@code972.com
> > > > >wrote:
> > > >
> > > > > Unless people here have a specific reason to use 3.6.2 I would
> highly
> > > > > recommed putting all the efforts we can towards v4 otherwise we
> will
> > > > never
> > > > > make it...
> > > > >
> > > > > Fork the repo from apache servers or github (same repo, different
> > > > remotes)
> > > > > and checkout -b 3x -t origin/master , that should work
> > > > >
> > > > >
> > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <pi...@feature23.com>
> > > > wrote:
> > > > >
> > > > > > Itamar,
> > > > > >
> > > > > > I agree that from scratch is not the best way to do it, I just
> > > thought
> > > > > that
> > > > > > was the "decision" that was made from the discussion previously
> for
> > > the
> > > > > 4.x
> > > > > > work. An incremental approach will be much better.
> > > > > >
> > > > > > I've created a branch of the branch_3x branch on my fork and will
> > > begin
> > > > > > working on bringing the Analysis namespace up to speed to 3.6.2.
> If
> > > > > anyone
> > > > > > wants to pull it or just reuse parts once I'm done, have at it.
> > > > > >
> > > > > > If I shouldn't have branched off the branch_3x branch, please let
> > me
> > > > know
> > > > > > what I should have branched from (trunk?)
> > > > > >
> > > > > > Paul
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <
> > > itamar@code972.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Thanks Prescott for bringing this up again :)
> > > > > > >
> > > > > > > Paul, the problem is no one can really know what it would take
> > > until
> > > > > they
> > > > > > > have deep dived into the work, and even then decisions could
> and
> > > will
> > > > > > > change. I will strongly advise against starting from scratch,
> > > > although
> > > > > I
> > > > > > do
> > > > > > > think a lot in the current structure should change, but its
> going
> > > to
> > > > be
> > > > > > > much easier to change it in place, refactoring where needed,
> than
> > > > > > starting
> > > > > > > all over again. Once we kicked this off I personally will be
> > happy
> > > > with
> > > > > > you
> > > > > > > taking the analysis part of Lucene and porting it, its pretty
> > much
> > > > self
> > > > > > > contained.
> > > > > > > Re 3.6.2 work - you can just do that on a fork and send us PRs,
> > its
> > > > > much
> > > > > > > more straight forward than the v4 upgrade
> > > > > > >
> > > > > > > Marcos, porting class by class is the fastest way to do this,
> we
> > > can
> > > > > then
> > > > > > > concentrate on .NETifying and optimizing using .NET constructs.
> > > > > > >
> > > > > > > That said, I think the way to go is create a branch out of the
> > > > current
> > > > > > git
> > > > > > > master HEAD and label it "3.x", and start working on master
> > > towards a
> > > > > 4.3
> > > > > > > compatible version. The actual port should be using a process
> > that
> > > > > > ensures
> > > > > > > all Java classes are ported with their tests, and that those
> > tests
> > > > > pass -
> > > > > > > but I'm against committing any Java code to our repositories.
> The
> > > > > process
> > > > > > > should probably be working on classes in some order
> > > (alphabetically,
> > > > or
> > > > > > > core classes first) and getting each class to compile before
> > moving
> > > > > > > forward. I don't mind about the project not being compilable
> for
> > a
> > > > > month
> > > > > > or
> > > > > > > two.
> > > > > > > Once this is done a process of .NETifying and proofing the code
> > can
> > > > be
> > > > > > > started, at which point we will already have a working v4
> version
> > > so
> > > > it
> > > > > > > will be easier to keep up with the Java project.
> > > > > > >
> > > > > > > The first step IMO is to stabilize the test suite so tests
> could
> > > more
> > > > > or
> > > > > > > less be copied and pasted (e.g. implementing Java-like
> > assertEquals
> > > > > > methods
> > > > > > > etc; I find xUnit to be much easier to work with than NUnit). I
> > > > already
> > > > > > did
> > > > > > > some work there but there's still a lot to do.
> > > > > > >
> > > > > > > Unfortunately I can't dedicate time myself at this point, but I
> > > > should
> > > > > be
> > > > > > > back in business in August, at which point I can dedicate
> several
> > > > > hours a
> > > > > > > week. Until then I'll be happy to watch closely and even
> > coordinate
> > > > the
> > > > > > > work to some extent.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > > > marcoslimagon@gmail.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > It really sounds good to me, this is a kick start =). I
> haven't
> > > > > > > contributed
> > > > > > > > anything
> > > > > > > > yet, but I would like to help you all to get this job done.
> > > > > > > >
> > > > > > > > I'm completely agree with Paul and Prescott.
> > > > > > > >
> > > > > > > > I know that there is a high commitment for keep the
> > > > > retrocompatibility
> > > > > > on
> > > > > > > > Lucene. Does Java Lucene API gets big changes every release?
> > > > > > > >
> > > > > > > > Is the Lucene.Net a port from a stable version from a Lucene
> > > > version,
> > > > > > > > right? If the Lucene API gets only minor changes every stable
> > > > release
> > > > > > (or
> > > > > > > > keep most of its source-code), we could compare the versions,
> > > check
> > > > > the
> > > > > > > > differences and bring them to Lucene.Net. Again, I haven't
> > > > > contributed
> > > > > > > with
> > > > > > > > yet, so I don't know how it is (just an idea).
> > > > > > > >
> > > > > > > > What's your approach for implement simple performance
> > > improvements
> > > > > > > (without
> > > > > > > > adding references or changing methods signatures)? Does it
> > could
> > > be
> > > > > > done,
> > > > > > > > or "follow the java version only"?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > > > > > >
> > > > > > > > > This is just an "outsider" suggestion as I haven't
> > contributed
> > > > > > anything
> > > > > > > > > yet, although I will definitely help with the 4.x work as I
> > > have
> > > > a
> > > > > > > vested
> > > > > > > > > interest in seeing that get completed. I think there should
> > be
> > > > one
> > > > > > > person
> > > > > > > > > (or perhaps two) guiding what the structure and workflow
> will
> > > > look
> > > > > > like
> > > > > > > > to
> > > > > > > > > avoid chaos. If the 4.x work is going to be starting from
> > > scratch
> > > > > as
> > > > > > a
> > > > > > > > > fresh port, that person should set up the project, get
> > > everything
> > > > > > going
> > > > > > > > in
> > > > > > > > > source control, create the folder structure, maybe stub out
> > > some
> > > > > > > classes,
> > > > > > > > > etc. Then divide and conquer with anyone interested in
> > > > > contributing,
> > > > > > > > > perhaps by namespace.
> > > > > > > > >
> > > > > > > > > I like the idea of throwing the java code in there so it's
> > easy
> > > > to
> > > > > > > > > reference.
> > > > > > > > >
> > > > > > > > > Again, I can work on Lucene.Net.Documents,
> > Lucene.Net.Analysis,
> > > > or
> > > > > > > > > Lucene.Net.Store -- or any others, those are just the ones
> > I'm
> > > > most
> > > > > > > > > familiar with the inner workings. Tell me what to do and
> I'll
> > > get
> > > > > > > started
> > > > > > > > > on my fork.
> > > > > > > > >
> > > > > > > > > Paul Irwin
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > > > > > geobmx540@hotmail.com
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > Hey guys -
> > > > > > > > > > I know I've been MIA a little while. We have a board
> report
> > > due
> > > > > > soon
> > > > > > > -
> > > > > > > > I
> > > > > > > > > > think it prudent that we advise them that we seem to have
> > > > stalled
> > > > > > > > > somewhat.
> > > > > > > > > > We've got a few low hanging items out of of jira and have
> > > been
> > > > > > > > responsive
> > > > > > > > > > on the mailing list to community questions, but I don't
> > think
> > > > > we've
> > > > > > > > done
> > > > > > > > > > anything to move forward with 4.0.
> > > > > > > > > > To that end - I'd like to *try* and start us back up
> moving
> > > > > > forward.
> > > > > > > > What
> > > > > > > > > > is the best way to accomplish this? If we took the java
> > > lucene
> > > > > 4.0
> > > > > > > code
> > > > > > > > > and
> > > > > > > > > > committed that java to our branch and then just let
> people
> > > pull
> > > > > > that
> > > > > > > > down
> > > > > > > > > > and being changing / modifying is that one way to maybe
> > make
> > > > some
> > > > > > > > forward
> > > > > > > > > > progress?
> > > > > > > > > > ~P
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > --
> > > > > > > > Marcos Lima
> > > > > > > > Software Developer/Tech Lead
> > > > > > > > marcoslimagon@gmail.com
> > > > > > > > tel: +55 (19) 9798-9335
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Lucene 4.0
Posted by Itamar Syn-Hershko <it...@code972.com>.
inline
On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <pi...@feature23.com> wrote:
> Ah, I gotcha. Still getting used to git, I've been a TFS guy for so long
> :-)
>
> So to recap, the branch_3x will be used for any patches or anything to the
> current 3.0.3 release, while trunk is what we will branch from for 4x dev.
> Correct?
>
Yes - we can branch from it for 3.6 development if anyone will be
interested in that
>
> Thanks for pushing the Version.cs. What's the deal with the github sync?
> Who could diagnose that?
>
Not sure, Apache Infra, basically. Just use the apache repo for now while
we get that sorted out.
>
>
> On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > Ok, haven't noticed that branch. Just use it then for 3.x development.
> WRT
> > v4, yeah - just fork the repo and work on whatever branch. When you send
> us
> > PRs we will merge either to master or to a dedicated repo. For now it
> > doesn't really matter, thats the beauty of git.
> >
> > I pushed a new Version.cs file, you should see it on the apache servers
> > (github sync seems to be off)
> >
> >
> > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >
> > > Thanks Itamar. I can certainly start work on 4.3 version of the
> Analysis
> > > namespace.
> > >
> > > Not sure the checkout command is what you intended -- you might have
> > meant
> > > trunk instead of master, and that would create a new "3x" branch, when
> > > there's already a "branch_3x" and that would be misnamed... so maybe
> > > checkout -b branch_4x trunk and start there aiming for lucene 4.3.x
> > > compatibility?
> > >
> > > Also, does someone with commit rights to the upstream want to create
> the
> > > necessary Version.cs entries, so that we're not all trying to create
> them
> > > and dealing with a merge?
> > >
> > > Paul
> > >
> > >
> > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <itamar@code972.com
> > > >wrote:
> > >
> > > > Unless people here have a specific reason to use 3.6.2 I would highly
> > > > recommed putting all the efforts we can towards v4 otherwise we will
> > > never
> > > > make it...
> > > >
> > > > Fork the repo from apache servers or github (same repo, different
> > > remotes)
> > > > and checkout -b 3x -t origin/master , that should work
> > > >
> > > >
> > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <pi...@feature23.com>
> > > wrote:
> > > >
> > > > > Itamar,
> > > > >
> > > > > I agree that from scratch is not the best way to do it, I just
> > thought
> > > > that
> > > > > was the "decision" that was made from the discussion previously for
> > the
> > > > 4.x
> > > > > work. An incremental approach will be much better.
> > > > >
> > > > > I've created a branch of the branch_3x branch on my fork and will
> > begin
> > > > > working on bringing the Analysis namespace up to speed to 3.6.2. If
> > > > anyone
> > > > > wants to pull it or just reuse parts once I'm done, have at it.
> > > > >
> > > > > If I shouldn't have branched off the branch_3x branch, please let
> me
> > > know
> > > > > what I should have branched from (trunk?)
> > > > >
> > > > > Paul
> > > > >
> > > > >
> > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <
> > itamar@code972.com
> > > > > >wrote:
> > > > >
> > > > > > Thanks Prescott for bringing this up again :)
> > > > > >
> > > > > > Paul, the problem is no one can really know what it would take
> > until
> > > > they
> > > > > > have deep dived into the work, and even then decisions could and
> > will
> > > > > > change. I will strongly advise against starting from scratch,
> > > although
> > > > I
> > > > > do
> > > > > > think a lot in the current structure should change, but its going
> > to
> > > be
> > > > > > much easier to change it in place, refactoring where needed, than
> > > > > starting
> > > > > > all over again. Once we kicked this off I personally will be
> happy
> > > with
> > > > > you
> > > > > > taking the analysis part of Lucene and porting it, its pretty
> much
> > > self
> > > > > > contained.
> > > > > > Re 3.6.2 work - you can just do that on a fork and send us PRs,
> its
> > > > much
> > > > > > more straight forward than the v4 upgrade
> > > > > >
> > > > > > Marcos, porting class by class is the fastest way to do this, we
> > can
> > > > then
> > > > > > concentrate on .NETifying and optimizing using .NET constructs.
> > > > > >
> > > > > > That said, I think the way to go is create a branch out of the
> > > current
> > > > > git
> > > > > > master HEAD and label it "3.x", and start working on master
> > towards a
> > > > 4.3
> > > > > > compatible version. The actual port should be using a process
> that
> > > > > ensures
> > > > > > all Java classes are ported with their tests, and that those
> tests
> > > > pass -
> > > > > > but I'm against committing any Java code to our repositories. The
> > > > process
> > > > > > should probably be working on classes in some order
> > (alphabetically,
> > > or
> > > > > > core classes first) and getting each class to compile before
> moving
> > > > > > forward. I don't mind about the project not being compilable for
> a
> > > > month
> > > > > or
> > > > > > two.
> > > > > > Once this is done a process of .NETifying and proofing the code
> can
> > > be
> > > > > > started, at which point we will already have a working v4 version
> > so
> > > it
> > > > > > will be easier to keep up with the Java project.
> > > > > >
> > > > > > The first step IMO is to stabilize the test suite so tests could
> > more
> > > > or
> > > > > > less be copied and pasted (e.g. implementing Java-like
> assertEquals
> > > > > methods
> > > > > > etc; I find xUnit to be much easier to work with than NUnit). I
> > > already
> > > > > did
> > > > > > some work there but there's still a lot to do.
> > > > > >
> > > > > > Unfortunately I can't dedicate time myself at this point, but I
> > > should
> > > > be
> > > > > > back in business in August, at which point I can dedicate several
> > > > hours a
> > > > > > week. Until then I'll be happy to watch closely and even
> coordinate
> > > the
> > > > > > work to some extent.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > > marcoslimagon@gmail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > It really sounds good to me, this is a kick start =). I haven't
> > > > > > contributed
> > > > > > > anything
> > > > > > > yet, but I would like to help you all to get this job done.
> > > > > > >
> > > > > > > I'm completely agree with Paul and Prescott.
> > > > > > >
> > > > > > > I know that there is a high commitment for keep the
> > > > retrocompatibility
> > > > > on
> > > > > > > Lucene. Does Java Lucene API gets big changes every release?
> > > > > > >
> > > > > > > Is the Lucene.Net a port from a stable version from a Lucene
> > > version,
> > > > > > > right? If the Lucene API gets only minor changes every stable
> > > release
> > > > > (or
> > > > > > > keep most of its source-code), we could compare the versions,
> > check
> > > > the
> > > > > > > differences and bring them to Lucene.Net. Again, I haven't
> > > > contributed
> > > > > > with
> > > > > > > yet, so I don't know how it is (just an idea).
> > > > > > >
> > > > > > > What's your approach for implement simple performance
> > improvements
> > > > > > (without
> > > > > > > adding references or changing methods signatures)? Does it
> could
> > be
> > > > > done,
> > > > > > > or "follow the java version only"?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > > > > >
> > > > > > > > This is just an "outsider" suggestion as I haven't
> contributed
> > > > > anything
> > > > > > > > yet, although I will definitely help with the 4.x work as I
> > have
> > > a
> > > > > > vested
> > > > > > > > interest in seeing that get completed. I think there should
> be
> > > one
> > > > > > person
> > > > > > > > (or perhaps two) guiding what the structure and workflow will
> > > look
> > > > > like
> > > > > > > to
> > > > > > > > avoid chaos. If the 4.x work is going to be starting from
> > scratch
> > > > as
> > > > > a
> > > > > > > > fresh port, that person should set up the project, get
> > everything
> > > > > going
> > > > > > > in
> > > > > > > > source control, create the folder structure, maybe stub out
> > some
> > > > > > classes,
> > > > > > > > etc. Then divide and conquer with anyone interested in
> > > > contributing,
> > > > > > > > perhaps by namespace.
> > > > > > > >
> > > > > > > > I like the idea of throwing the java code in there so it's
> easy
> > > to
> > > > > > > > reference.
> > > > > > > >
> > > > > > > > Again, I can work on Lucene.Net.Documents,
> Lucene.Net.Analysis,
> > > or
> > > > > > > > Lucene.Net.Store -- or any others, those are just the ones
> I'm
> > > most
> > > > > > > > familiar with the inner workings. Tell me what to do and I'll
> > get
> > > > > > started
> > > > > > > > on my fork.
> > > > > > > >
> > > > > > > > Paul Irwin
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > > > > geobmx540@hotmail.com
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > Hey guys -
> > > > > > > > > I know I've been MIA a little while. We have a board report
> > due
> > > > > soon
> > > > > > -
> > > > > > > I
> > > > > > > > > think it prudent that we advise them that we seem to have
> > > stalled
> > > > > > > > somewhat.
> > > > > > > > > We've got a few low hanging items out of of jira and have
> > been
> > > > > > > responsive
> > > > > > > > > on the mailing list to community questions, but I don't
> think
> > > > we've
> > > > > > > done
> > > > > > > > > anything to move forward with 4.0.
> > > > > > > > > To that end - I'd like to *try* and start us back up moving
> > > > > forward.
> > > > > > > What
> > > > > > > > > is the best way to accomplish this? If we took the java
> > lucene
> > > > 4.0
> > > > > > code
> > > > > > > > and
> > > > > > > > > committed that java to our branch and then just let people
> > pull
> > > > > that
> > > > > > > down
> > > > > > > > > and being changing / modifying is that one way to maybe
> make
> > > some
> > > > > > > forward
> > > > > > > > > progress?
> > > > > > > > > ~P
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > --
> > > > > > > Marcos Lima
> > > > > > > Software Developer/Tech Lead
> > > > > > > marcoslimagon@gmail.com
> > > > > > > tel: +55 (19) 9798-9335
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Ah, I gotcha. Still getting used to git, I've been a TFS guy for so long :-)
So to recap, the branch_3x will be used for any patches or anything to the
current 3.0.3 release, while trunk is what we will branch from for 4x dev.
Correct?
Thanks for pushing the Version.cs. What's the deal with the github sync?
Who could diagnose that?
On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <it...@code972.com>wrote:
> Ok, haven't noticed that branch. Just use it then for 3.x development. WRT
> v4, yeah - just fork the repo and work on whatever branch. When you send us
> PRs we will merge either to master or to a dedicated repo. For now it
> doesn't really matter, thats the beauty of git.
>
> I pushed a new Version.cs file, you should see it on the apache servers
> (github sync seems to be off)
>
>
> On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <pi...@feature23.com> wrote:
>
> > Thanks Itamar. I can certainly start work on 4.3 version of the Analysis
> > namespace.
> >
> > Not sure the checkout command is what you intended -- you might have
> meant
> > trunk instead of master, and that would create a new "3x" branch, when
> > there's already a "branch_3x" and that would be misnamed... so maybe
> > checkout -b branch_4x trunk and start there aiming for lucene 4.3.x
> > compatibility?
> >
> > Also, does someone with commit rights to the upstream want to create the
> > necessary Version.cs entries, so that we're not all trying to create them
> > and dealing with a merge?
> >
> > Paul
> >
> >
> > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > Unless people here have a specific reason to use 3.6.2 I would highly
> > > recommed putting all the efforts we can towards v4 otherwise we will
> > never
> > > make it...
> > >
> > > Fork the repo from apache servers or github (same repo, different
> > remotes)
> > > and checkout -b 3x -t origin/master , that should work
> > >
> > >
> > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <pi...@feature23.com>
> > wrote:
> > >
> > > > Itamar,
> > > >
> > > > I agree that from scratch is not the best way to do it, I just
> thought
> > > that
> > > > was the "decision" that was made from the discussion previously for
> the
> > > 4.x
> > > > work. An incremental approach will be much better.
> > > >
> > > > I've created a branch of the branch_3x branch on my fork and will
> begin
> > > > working on bringing the Analysis namespace up to speed to 3.6.2. If
> > > anyone
> > > > wants to pull it or just reuse parts once I'm done, have at it.
> > > >
> > > > If I shouldn't have branched off the branch_3x branch, please let me
> > know
> > > > what I should have branched from (trunk?)
> > > >
> > > > Paul
> > > >
> > > >
> > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <
> itamar@code972.com
> > > > >wrote:
> > > >
> > > > > Thanks Prescott for bringing this up again :)
> > > > >
> > > > > Paul, the problem is no one can really know what it would take
> until
> > > they
> > > > > have deep dived into the work, and even then decisions could and
> will
> > > > > change. I will strongly advise against starting from scratch,
> > although
> > > I
> > > > do
> > > > > think a lot in the current structure should change, but its going
> to
> > be
> > > > > much easier to change it in place, refactoring where needed, than
> > > > starting
> > > > > all over again. Once we kicked this off I personally will be happy
> > with
> > > > you
> > > > > taking the analysis part of Lucene and porting it, its pretty much
> > self
> > > > > contained.
> > > > > Re 3.6.2 work - you can just do that on a fork and send us PRs, its
> > > much
> > > > > more straight forward than the v4 upgrade
> > > > >
> > > > > Marcos, porting class by class is the fastest way to do this, we
> can
> > > then
> > > > > concentrate on .NETifying and optimizing using .NET constructs.
> > > > >
> > > > > That said, I think the way to go is create a branch out of the
> > current
> > > > git
> > > > > master HEAD and label it "3.x", and start working on master
> towards a
> > > 4.3
> > > > > compatible version. The actual port should be using a process that
> > > > ensures
> > > > > all Java classes are ported with their tests, and that those tests
> > > pass -
> > > > > but I'm against committing any Java code to our repositories. The
> > > process
> > > > > should probably be working on classes in some order
> (alphabetically,
> > or
> > > > > core classes first) and getting each class to compile before moving
> > > > > forward. I don't mind about the project not being compilable for a
> > > month
> > > > or
> > > > > two.
> > > > > Once this is done a process of .NETifying and proofing the code can
> > be
> > > > > started, at which point we will already have a working v4 version
> so
> > it
> > > > > will be easier to keep up with the Java project.
> > > > >
> > > > > The first step IMO is to stabilize the test suite so tests could
> more
> > > or
> > > > > less be copied and pasted (e.g. implementing Java-like assertEquals
> > > > methods
> > > > > etc; I find xUnit to be much easier to work with than NUnit). I
> > already
> > > > did
> > > > > some work there but there's still a lot to do.
> > > > >
> > > > > Unfortunately I can't dedicate time myself at this point, but I
> > should
> > > be
> > > > > back in business in August, at which point I can dedicate several
> > > hours a
> > > > > week. Until then I'll be happy to watch closely and even coordinate
> > the
> > > > > work to some extent.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> > marcoslimagon@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > It really sounds good to me, this is a kick start =). I haven't
> > > > > contributed
> > > > > > anything
> > > > > > yet, but I would like to help you all to get this job done.
> > > > > >
> > > > > > I'm completely agree with Paul and Prescott.
> > > > > >
> > > > > > I know that there is a high commitment for keep the
> > > retrocompatibility
> > > > on
> > > > > > Lucene. Does Java Lucene API gets big changes every release?
> > > > > >
> > > > > > Is the Lucene.Net a port from a stable version from a Lucene
> > version,
> > > > > > right? If the Lucene API gets only minor changes every stable
> > release
> > > > (or
> > > > > > keep most of its source-code), we could compare the versions,
> check
> > > the
> > > > > > differences and bring them to Lucene.Net. Again, I haven't
> > > contributed
> > > > > with
> > > > > > yet, so I don't know how it is (just an idea).
> > > > > >
> > > > > > What's your approach for implement simple performance
> improvements
> > > > > (without
> > > > > > adding references or changing methods signatures)? Does it could
> be
> > > > done,
> > > > > > or "follow the java version only"?
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > > > >
> > > > > > > This is just an "outsider" suggestion as I haven't contributed
> > > > anything
> > > > > > > yet, although I will definitely help with the 4.x work as I
> have
> > a
> > > > > vested
> > > > > > > interest in seeing that get completed. I think there should be
> > one
> > > > > person
> > > > > > > (or perhaps two) guiding what the structure and workflow will
> > look
> > > > like
> > > > > > to
> > > > > > > avoid chaos. If the 4.x work is going to be starting from
> scratch
> > > as
> > > > a
> > > > > > > fresh port, that person should set up the project, get
> everything
> > > > going
> > > > > > in
> > > > > > > source control, create the folder structure, maybe stub out
> some
> > > > > classes,
> > > > > > > etc. Then divide and conquer with anyone interested in
> > > contributing,
> > > > > > > perhaps by namespace.
> > > > > > >
> > > > > > > I like the idea of throwing the java code in there so it's easy
> > to
> > > > > > > reference.
> > > > > > >
> > > > > > > Again, I can work on Lucene.Net.Documents, Lucene.Net.Analysis,
> > or
> > > > > > > Lucene.Net.Store -- or any others, those are just the ones I'm
> > most
> > > > > > > familiar with the inner workings. Tell me what to do and I'll
> get
> > > > > started
> > > > > > > on my fork.
> > > > > > >
> > > > > > > Paul Irwin
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > > > geobmx540@hotmail.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Hey guys -
> > > > > > > > I know I've been MIA a little while. We have a board report
> due
> > > > soon
> > > > > -
> > > > > > I
> > > > > > > > think it prudent that we advise them that we seem to have
> > stalled
> > > > > > > somewhat.
> > > > > > > > We've got a few low hanging items out of of jira and have
> been
> > > > > > responsive
> > > > > > > > on the mailing list to community questions, but I don't think
> > > we've
> > > > > > done
> > > > > > > > anything to move forward with 4.0.
> > > > > > > > To that end - I'd like to *try* and start us back up moving
> > > > forward.
> > > > > > What
> > > > > > > > is the best way to accomplish this? If we took the java
> lucene
> > > 4.0
> > > > > code
> > > > > > > and
> > > > > > > > committed that java to our branch and then just let people
> pull
> > > > that
> > > > > > down
> > > > > > > > and being changing / modifying is that one way to maybe make
> > some
> > > > > > forward
> > > > > > > > progress?
> > > > > > > > ~P
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > --
> > > > > > Marcos Lima
> > > > > > Software Developer/Tech Lead
> > > > > > marcoslimagon@gmail.com
> > > > > > tel: +55 (19) 9798-9335
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Lucene 4.0
Posted by Itamar Syn-Hershko <it...@code972.com>.
Ok, haven't noticed that branch. Just use it then for 3.x development. WRT
v4, yeah - just fork the repo and work on whatever branch. When you send us
PRs we will merge either to master or to a dedicated repo. For now it
doesn't really matter, thats the beauty of git.
I pushed a new Version.cs file, you should see it on the apache servers
(github sync seems to be off)
On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <pi...@feature23.com> wrote:
> Thanks Itamar. I can certainly start work on 4.3 version of the Analysis
> namespace.
>
> Not sure the checkout command is what you intended -- you might have meant
> trunk instead of master, and that would create a new "3x" branch, when
> there's already a "branch_3x" and that would be misnamed... so maybe
> checkout -b branch_4x trunk and start there aiming for lucene 4.3.x
> compatibility?
>
> Also, does someone with commit rights to the upstream want to create the
> necessary Version.cs entries, so that we're not all trying to create them
> and dealing with a merge?
>
> Paul
>
>
> On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > Unless people here have a specific reason to use 3.6.2 I would highly
> > recommed putting all the efforts we can towards v4 otherwise we will
> never
> > make it...
> >
> > Fork the repo from apache servers or github (same repo, different
> remotes)
> > and checkout -b 3x -t origin/master , that should work
> >
> >
> > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <pi...@feature23.com>
> wrote:
> >
> > > Itamar,
> > >
> > > I agree that from scratch is not the best way to do it, I just thought
> > that
> > > was the "decision" that was made from the discussion previously for the
> > 4.x
> > > work. An incremental approach will be much better.
> > >
> > > I've created a branch of the branch_3x branch on my fork and will begin
> > > working on bringing the Analysis namespace up to speed to 3.6.2. If
> > anyone
> > > wants to pull it or just reuse parts once I'm done, have at it.
> > >
> > > If I shouldn't have branched off the branch_3x branch, please let me
> know
> > > what I should have branched from (trunk?)
> > >
> > > Paul
> > >
> > >
> > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <itamar@code972.com
> > > >wrote:
> > >
> > > > Thanks Prescott for bringing this up again :)
> > > >
> > > > Paul, the problem is no one can really know what it would take until
> > they
> > > > have deep dived into the work, and even then decisions could and will
> > > > change. I will strongly advise against starting from scratch,
> although
> > I
> > > do
> > > > think a lot in the current structure should change, but its going to
> be
> > > > much easier to change it in place, refactoring where needed, than
> > > starting
> > > > all over again. Once we kicked this off I personally will be happy
> with
> > > you
> > > > taking the analysis part of Lucene and porting it, its pretty much
> self
> > > > contained.
> > > > Re 3.6.2 work - you can just do that on a fork and send us PRs, its
> > much
> > > > more straight forward than the v4 upgrade
> > > >
> > > > Marcos, porting class by class is the fastest way to do this, we can
> > then
> > > > concentrate on .NETifying and optimizing using .NET constructs.
> > > >
> > > > That said, I think the way to go is create a branch out of the
> current
> > > git
> > > > master HEAD and label it "3.x", and start working on master towards a
> > 4.3
> > > > compatible version. The actual port should be using a process that
> > > ensures
> > > > all Java classes are ported with their tests, and that those tests
> > pass -
> > > > but I'm against committing any Java code to our repositories. The
> > process
> > > > should probably be working on classes in some order (alphabetically,
> or
> > > > core classes first) and getting each class to compile before moving
> > > > forward. I don't mind about the project not being compilable for a
> > month
> > > or
> > > > two.
> > > > Once this is done a process of .NETifying and proofing the code can
> be
> > > > started, at which point we will already have a working v4 version so
> it
> > > > will be easier to keep up with the Java project.
> > > >
> > > > The first step IMO is to stabilize the test suite so tests could more
> > or
> > > > less be copied and pasted (e.g. implementing Java-like assertEquals
> > > methods
> > > > etc; I find xUnit to be much easier to work with than NUnit). I
> already
> > > did
> > > > some work there but there's still a lot to do.
> > > >
> > > > Unfortunately I can't dedicate time myself at this point, but I
> should
> > be
> > > > back in business in August, at which point I can dedicate several
> > hours a
> > > > week. Until then I'll be happy to watch closely and even coordinate
> the
> > > > work to some extent.
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <
> marcoslimagon@gmail.com
> > > > >wrote:
> > > >
> > > > > It really sounds good to me, this is a kick start =). I haven't
> > > > contributed
> > > > > anything
> > > > > yet, but I would like to help you all to get this job done.
> > > > >
> > > > > I'm completely agree with Paul and Prescott.
> > > > >
> > > > > I know that there is a high commitment for keep the
> > retrocompatibility
> > > on
> > > > > Lucene. Does Java Lucene API gets big changes every release?
> > > > >
> > > > > Is the Lucene.Net a port from a stable version from a Lucene
> version,
> > > > > right? If the Lucene API gets only minor changes every stable
> release
> > > (or
> > > > > keep most of its source-code), we could compare the versions, check
> > the
> > > > > differences and bring them to Lucene.Net. Again, I haven't
> > contributed
> > > > with
> > > > > yet, so I don't know how it is (just an idea).
> > > > >
> > > > > What's your approach for implement simple performance improvements
> > > > (without
> > > > > adding references or changing methods signatures)? Does it could be
> > > done,
> > > > > or "follow the java version only"?
> > > > >
> > > > >
> > > > >
> > > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > > >
> > > > > > This is just an "outsider" suggestion as I haven't contributed
> > > anything
> > > > > > yet, although I will definitely help with the 4.x work as I have
> a
> > > > vested
> > > > > > interest in seeing that get completed. I think there should be
> one
> > > > person
> > > > > > (or perhaps two) guiding what the structure and workflow will
> look
> > > like
> > > > > to
> > > > > > avoid chaos. If the 4.x work is going to be starting from scratch
> > as
> > > a
> > > > > > fresh port, that person should set up the project, get everything
> > > going
> > > > > in
> > > > > > source control, create the folder structure, maybe stub out some
> > > > classes,
> > > > > > etc. Then divide and conquer with anyone interested in
> > contributing,
> > > > > > perhaps by namespace.
> > > > > >
> > > > > > I like the idea of throwing the java code in there so it's easy
> to
> > > > > > reference.
> > > > > >
> > > > > > Again, I can work on Lucene.Net.Documents, Lucene.Net.Analysis,
> or
> > > > > > Lucene.Net.Store -- or any others, those are just the ones I'm
> most
> > > > > > familiar with the inner workings. Tell me what to do and I'll get
> > > > started
> > > > > > on my fork.
> > > > > >
> > > > > > Paul Irwin
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > > geobmx540@hotmail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Hey guys -
> > > > > > > I know I've been MIA a little while. We have a board report due
> > > soon
> > > > -
> > > > > I
> > > > > > > think it prudent that we advise them that we seem to have
> stalled
> > > > > > somewhat.
> > > > > > > We've got a few low hanging items out of of jira and have been
> > > > > responsive
> > > > > > > on the mailing list to community questions, but I don't think
> > we've
> > > > > done
> > > > > > > anything to move forward with 4.0.
> > > > > > > To that end - I'd like to *try* and start us back up moving
> > > forward.
> > > > > What
> > > > > > > is the best way to accomplish this? If we took the java lucene
> > 4.0
> > > > code
> > > > > > and
> > > > > > > committed that java to our branch and then just let people pull
> > > that
> > > > > down
> > > > > > > and being changing / modifying is that one way to maybe make
> some
> > > > > forward
> > > > > > > progress?
> > > > > > > ~P
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > --
> > > > > Marcos Lima
> > > > > Software Developer/Tech Lead
> > > > > marcoslimagon@gmail.com
> > > > > tel: +55 (19) 9798-9335
> > > > >
> > > >
> > >
> >
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Thanks Itamar. I can certainly start work on 4.3 version of the Analysis
namespace.
Not sure the checkout command is what you intended -- you might have meant
trunk instead of master, and that would create a new "3x" branch, when
there's already a "branch_3x" and that would be misnamed... so maybe
checkout -b branch_4x trunk and start there aiming for lucene 4.3.x
compatibility?
Also, does someone with commit rights to the upstream want to create the
necessary Version.cs entries, so that we're not all trying to create them
and dealing with a merge?
Paul
On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <it...@code972.com>wrote:
> Unless people here have a specific reason to use 3.6.2 I would highly
> recommed putting all the efforts we can towards v4 otherwise we will never
> make it...
>
> Fork the repo from apache servers or github (same repo, different remotes)
> and checkout -b 3x -t origin/master , that should work
>
>
> On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <pi...@feature23.com> wrote:
>
> > Itamar,
> >
> > I agree that from scratch is not the best way to do it, I just thought
> that
> > was the "decision" that was made from the discussion previously for the
> 4.x
> > work. An incremental approach will be much better.
> >
> > I've created a branch of the branch_3x branch on my fork and will begin
> > working on bringing the Analysis namespace up to speed to 3.6.2. If
> anyone
> > wants to pull it or just reuse parts once I'm done, have at it.
> >
> > If I shouldn't have branched off the branch_3x branch, please let me know
> > what I should have branched from (trunk?)
> >
> > Paul
> >
> >
> > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > Thanks Prescott for bringing this up again :)
> > >
> > > Paul, the problem is no one can really know what it would take until
> they
> > > have deep dived into the work, and even then decisions could and will
> > > change. I will strongly advise against starting from scratch, although
> I
> > do
> > > think a lot in the current structure should change, but its going to be
> > > much easier to change it in place, refactoring where needed, than
> > starting
> > > all over again. Once we kicked this off I personally will be happy with
> > you
> > > taking the analysis part of Lucene and porting it, its pretty much self
> > > contained.
> > > Re 3.6.2 work - you can just do that on a fork and send us PRs, its
> much
> > > more straight forward than the v4 upgrade
> > >
> > > Marcos, porting class by class is the fastest way to do this, we can
> then
> > > concentrate on .NETifying and optimizing using .NET constructs.
> > >
> > > That said, I think the way to go is create a branch out of the current
> > git
> > > master HEAD and label it "3.x", and start working on master towards a
> 4.3
> > > compatible version. The actual port should be using a process that
> > ensures
> > > all Java classes are ported with their tests, and that those tests
> pass -
> > > but I'm against committing any Java code to our repositories. The
> process
> > > should probably be working on classes in some order (alphabetically, or
> > > core classes first) and getting each class to compile before moving
> > > forward. I don't mind about the project not being compilable for a
> month
> > or
> > > two.
> > > Once this is done a process of .NETifying and proofing the code can be
> > > started, at which point we will already have a working v4 version so it
> > > will be easier to keep up with the Java project.
> > >
> > > The first step IMO is to stabilize the test suite so tests could more
> or
> > > less be copied and pasted (e.g. implementing Java-like assertEquals
> > methods
> > > etc; I find xUnit to be much easier to work with than NUnit). I already
> > did
> > > some work there but there's still a lot to do.
> > >
> > > Unfortunately I can't dedicate time myself at this point, but I should
> be
> > > back in business in August, at which point I can dedicate several
> hours a
> > > week. Until then I'll be happy to watch closely and even coordinate the
> > > work to some extent.
> > >
> > >
> > >
> > >
> > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <marcoslimagon@gmail.com
> > > >wrote:
> > >
> > > > It really sounds good to me, this is a kick start =). I haven't
> > > contributed
> > > > anything
> > > > yet, but I would like to help you all to get this job done.
> > > >
> > > > I'm completely agree with Paul and Prescott.
> > > >
> > > > I know that there is a high commitment for keep the
> retrocompatibility
> > on
> > > > Lucene. Does Java Lucene API gets big changes every release?
> > > >
> > > > Is the Lucene.Net a port from a stable version from a Lucene version,
> > > > right? If the Lucene API gets only minor changes every stable release
> > (or
> > > > keep most of its source-code), we could compare the versions, check
> the
> > > > differences and bring them to Lucene.Net. Again, I haven't
> contributed
> > > with
> > > > yet, so I don't know how it is (just an idea).
> > > >
> > > > What's your approach for implement simple performance improvements
> > > (without
> > > > adding references or changing methods signatures)? Does it could be
> > done,
> > > > or "follow the java version only"?
> > > >
> > > >
> > > >
> > > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > > >
> > > > > This is just an "outsider" suggestion as I haven't contributed
> > anything
> > > > > yet, although I will definitely help with the 4.x work as I have a
> > > vested
> > > > > interest in seeing that get completed. I think there should be one
> > > person
> > > > > (or perhaps two) guiding what the structure and workflow will look
> > like
> > > > to
> > > > > avoid chaos. If the 4.x work is going to be starting from scratch
> as
> > a
> > > > > fresh port, that person should set up the project, get everything
> > going
> > > > in
> > > > > source control, create the folder structure, maybe stub out some
> > > classes,
> > > > > etc. Then divide and conquer with anyone interested in
> contributing,
> > > > > perhaps by namespace.
> > > > >
> > > > > I like the idea of throwing the java code in there so it's easy to
> > > > > reference.
> > > > >
> > > > > Again, I can work on Lucene.Net.Documents, Lucene.Net.Analysis, or
> > > > > Lucene.Net.Store -- or any others, those are just the ones I'm most
> > > > > familiar with the inner workings. Tell me what to do and I'll get
> > > started
> > > > > on my fork.
> > > > >
> > > > > Paul Irwin
> > > > >
> > > > >
> > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > geobmx540@hotmail.com
> > > > > >wrote:
> > > > >
> > > > > > Hey guys -
> > > > > > I know I've been MIA a little while. We have a board report due
> > soon
> > > -
> > > > I
> > > > > > think it prudent that we advise them that we seem to have stalled
> > > > > somewhat.
> > > > > > We've got a few low hanging items out of of jira and have been
> > > > responsive
> > > > > > on the mailing list to community questions, but I don't think
> we've
> > > > done
> > > > > > anything to move forward with 4.0.
> > > > > > To that end - I'd like to *try* and start us back up moving
> > forward.
> > > > What
> > > > > > is the best way to accomplish this? If we took the java lucene
> 4.0
> > > code
> > > > > and
> > > > > > committed that java to our branch and then just let people pull
> > that
> > > > down
> > > > > > and being changing / modifying is that one way to maybe make some
> > > > forward
> > > > > > progress?
> > > > > > ~P
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > --
> > > > Marcos Lima
> > > > Software Developer/Tech Lead
> > > > marcoslimagon@gmail.com
> > > > tel: +55 (19) 9798-9335
> > > >
> > >
> >
>
Re: Lucene 4.0
Posted by Itamar Syn-Hershko <it...@code972.com>.
Unless people here have a specific reason to use 3.6.2 I would highly
recommed putting all the efforts we can towards v4 otherwise we will never
make it...
Fork the repo from apache servers or github (same repo, different remotes)
and checkout -b 3x -t origin/master , that should work
On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <pi...@feature23.com> wrote:
> Itamar,
>
> I agree that from scratch is not the best way to do it, I just thought that
> was the "decision" that was made from the discussion previously for the 4.x
> work. An incremental approach will be much better.
>
> I've created a branch of the branch_3x branch on my fork and will begin
> working on bringing the Analysis namespace up to speed to 3.6.2. If anyone
> wants to pull it or just reuse parts once I'm done, have at it.
>
> If I shouldn't have branched off the branch_3x branch, please let me know
> what I should have branched from (trunk?)
>
> Paul
>
>
> On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > Thanks Prescott for bringing this up again :)
> >
> > Paul, the problem is no one can really know what it would take until they
> > have deep dived into the work, and even then decisions could and will
> > change. I will strongly advise against starting from scratch, although I
> do
> > think a lot in the current structure should change, but its going to be
> > much easier to change it in place, refactoring where needed, than
> starting
> > all over again. Once we kicked this off I personally will be happy with
> you
> > taking the analysis part of Lucene and porting it, its pretty much self
> > contained.
> > Re 3.6.2 work - you can just do that on a fork and send us PRs, its much
> > more straight forward than the v4 upgrade
> >
> > Marcos, porting class by class is the fastest way to do this, we can then
> > concentrate on .NETifying and optimizing using .NET constructs.
> >
> > That said, I think the way to go is create a branch out of the current
> git
> > master HEAD and label it "3.x", and start working on master towards a 4.3
> > compatible version. The actual port should be using a process that
> ensures
> > all Java classes are ported with their tests, and that those tests pass -
> > but I'm against committing any Java code to our repositories. The process
> > should probably be working on classes in some order (alphabetically, or
> > core classes first) and getting each class to compile before moving
> > forward. I don't mind about the project not being compilable for a month
> or
> > two.
> > Once this is done a process of .NETifying and proofing the code can be
> > started, at which point we will already have a working v4 version so it
> > will be easier to keep up with the Java project.
> >
> > The first step IMO is to stabilize the test suite so tests could more or
> > less be copied and pasted (e.g. implementing Java-like assertEquals
> methods
> > etc; I find xUnit to be much easier to work with than NUnit). I already
> did
> > some work there but there's still a lot to do.
> >
> > Unfortunately I can't dedicate time myself at this point, but I should be
> > back in business in August, at which point I can dedicate several hours a
> > week. Until then I'll be happy to watch closely and even coordinate the
> > work to some extent.
> >
> >
> >
> >
> > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <marcoslimagon@gmail.com
> > >wrote:
> >
> > > It really sounds good to me, this is a kick start =). I haven't
> > contributed
> > > anything
> > > yet, but I would like to help you all to get this job done.
> > >
> > > I'm completely agree with Paul and Prescott.
> > >
> > > I know that there is a high commitment for keep the retrocompatibility
> on
> > > Lucene. Does Java Lucene API gets big changes every release?
> > >
> > > Is the Lucene.Net a port from a stable version from a Lucene version,
> > > right? If the Lucene API gets only minor changes every stable release
> (or
> > > keep most of its source-code), we could compare the versions, check the
> > > differences and bring them to Lucene.Net. Again, I haven't contributed
> > with
> > > yet, so I don't know how it is (just an idea).
> > >
> > > What's your approach for implement simple performance improvements
> > (without
> > > adding references or changing methods signatures)? Does it could be
> done,
> > > or "follow the java version only"?
> > >
> > >
> > >
> > > 2013/6/6 Paul Irwin <pi...@feature23.com>
> > >
> > > > This is just an "outsider" suggestion as I haven't contributed
> anything
> > > > yet, although I will definitely help with the 4.x work as I have a
> > vested
> > > > interest in seeing that get completed. I think there should be one
> > person
> > > > (or perhaps two) guiding what the structure and workflow will look
> like
> > > to
> > > > avoid chaos. If the 4.x work is going to be starting from scratch as
> a
> > > > fresh port, that person should set up the project, get everything
> going
> > > in
> > > > source control, create the folder structure, maybe stub out some
> > classes,
> > > > etc. Then divide and conquer with anyone interested in contributing,
> > > > perhaps by namespace.
> > > >
> > > > I like the idea of throwing the java code in there so it's easy to
> > > > reference.
> > > >
> > > > Again, I can work on Lucene.Net.Documents, Lucene.Net.Analysis, or
> > > > Lucene.Net.Store -- or any others, those are just the ones I'm most
> > > > familiar with the inner workings. Tell me what to do and I'll get
> > started
> > > > on my fork.
> > > >
> > > > Paul Irwin
> > > >
> > > >
> > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> geobmx540@hotmail.com
> > > > >wrote:
> > > >
> > > > > Hey guys -
> > > > > I know I've been MIA a little while. We have a board report due
> soon
> > -
> > > I
> > > > > think it prudent that we advise them that we seem to have stalled
> > > > somewhat.
> > > > > We've got a few low hanging items out of of jira and have been
> > > responsive
> > > > > on the mailing list to community questions, but I don't think we've
> > > done
> > > > > anything to move forward with 4.0.
> > > > > To that end - I'd like to *try* and start us back up moving
> forward.
> > > What
> > > > > is the best way to accomplish this? If we took the java lucene 4.0
> > code
> > > > and
> > > > > committed that java to our branch and then just let people pull
> that
> > > down
> > > > > and being changing / modifying is that one way to maybe make some
> > > forward
> > > > > progress?
> > > > > ~P
> > > >
> > >
> > >
> > >
> > > --
> > > --
> > > Marcos Lima
> > > Software Developer/Tech Lead
> > > marcoslimagon@gmail.com
> > > tel: +55 (19) 9798-9335
> > >
> >
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Itamar,
I agree that from scratch is not the best way to do it, I just thought that
was the "decision" that was made from the discussion previously for the 4.x
work. An incremental approach will be much better.
I've created a branch of the branch_3x branch on my fork and will begin
working on bringing the Analysis namespace up to speed to 3.6.2. If anyone
wants to pull it or just reuse parts once I'm done, have at it.
If I shouldn't have branched off the branch_3x branch, please let me know
what I should have branched from (trunk?)
Paul
On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <it...@code972.com>wrote:
> Thanks Prescott for bringing this up again :)
>
> Paul, the problem is no one can really know what it would take until they
> have deep dived into the work, and even then decisions could and will
> change. I will strongly advise against starting from scratch, although I do
> think a lot in the current structure should change, but its going to be
> much easier to change it in place, refactoring where needed, than starting
> all over again. Once we kicked this off I personally will be happy with you
> taking the analysis part of Lucene and porting it, its pretty much self
> contained.
> Re 3.6.2 work - you can just do that on a fork and send us PRs, its much
> more straight forward than the v4 upgrade
>
> Marcos, porting class by class is the fastest way to do this, we can then
> concentrate on .NETifying and optimizing using .NET constructs.
>
> That said, I think the way to go is create a branch out of the current git
> master HEAD and label it "3.x", and start working on master towards a 4.3
> compatible version. The actual port should be using a process that ensures
> all Java classes are ported with their tests, and that those tests pass -
> but I'm against committing any Java code to our repositories. The process
> should probably be working on classes in some order (alphabetically, or
> core classes first) and getting each class to compile before moving
> forward. I don't mind about the project not being compilable for a month or
> two.
> Once this is done a process of .NETifying and proofing the code can be
> started, at which point we will already have a working v4 version so it
> will be easier to keep up with the Java project.
>
> The first step IMO is to stabilize the test suite so tests could more or
> less be copied and pasted (e.g. implementing Java-like assertEquals methods
> etc; I find xUnit to be much easier to work with than NUnit). I already did
> some work there but there's still a lot to do.
>
> Unfortunately I can't dedicate time myself at this point, but I should be
> back in business in August, at which point I can dedicate several hours a
> week. Until then I'll be happy to watch closely and even coordinate the
> work to some extent.
>
>
>
>
> On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <marcoslimagon@gmail.com
> >wrote:
>
> > It really sounds good to me, this is a kick start =). I haven't
> contributed
> > anything
> > yet, but I would like to help you all to get this job done.
> >
> > I'm completely agree with Paul and Prescott.
> >
> > I know that there is a high commitment for keep the retrocompatibility on
> > Lucene. Does Java Lucene API gets big changes every release?
> >
> > Is the Lucene.Net a port from a stable version from a Lucene version,
> > right? If the Lucene API gets only minor changes every stable release (or
> > keep most of its source-code), we could compare the versions, check the
> > differences and bring them to Lucene.Net. Again, I haven't contributed
> with
> > yet, so I don't know how it is (just an idea).
> >
> > What's your approach for implement simple performance improvements
> (without
> > adding references or changing methods signatures)? Does it could be done,
> > or "follow the java version only"?
> >
> >
> >
> > 2013/6/6 Paul Irwin <pi...@feature23.com>
> >
> > > This is just an "outsider" suggestion as I haven't contributed anything
> > > yet, although I will definitely help with the 4.x work as I have a
> vested
> > > interest in seeing that get completed. I think there should be one
> person
> > > (or perhaps two) guiding what the structure and workflow will look like
> > to
> > > avoid chaos. If the 4.x work is going to be starting from scratch as a
> > > fresh port, that person should set up the project, get everything going
> > in
> > > source control, create the folder structure, maybe stub out some
> classes,
> > > etc. Then divide and conquer with anyone interested in contributing,
> > > perhaps by namespace.
> > >
> > > I like the idea of throwing the java code in there so it's easy to
> > > reference.
> > >
> > > Again, I can work on Lucene.Net.Documents, Lucene.Net.Analysis, or
> > > Lucene.Net.Store -- or any others, those are just the ones I'm most
> > > familiar with the inner workings. Tell me what to do and I'll get
> started
> > > on my fork.
> > >
> > > Paul Irwin
> > >
> > >
> > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <geobmx540@hotmail.com
> > > >wrote:
> > >
> > > > Hey guys -
> > > > I know I've been MIA a little while. We have a board report due soon
> -
> > I
> > > > think it prudent that we advise them that we seem to have stalled
> > > somewhat.
> > > > We've got a few low hanging items out of of jira and have been
> > responsive
> > > > on the mailing list to community questions, but I don't think we've
> > done
> > > > anything to move forward with 4.0.
> > > > To that end - I'd like to *try* and start us back up moving forward.
> > What
> > > > is the best way to accomplish this? If we took the java lucene 4.0
> code
> > > and
> > > > committed that java to our branch and then just let people pull that
> > down
> > > > and being changing / modifying is that one way to maybe make some
> > forward
> > > > progress?
> > > > ~P
> > >
> >
> >
> >
> > --
> > --
> > Marcos Lima
> > Software Developer/Tech Lead
> > marcoslimagon@gmail.com
> > tel: +55 (19) 9798-9335
> >
>
Re: Lucene 4.0
Posted by Itamar Syn-Hershko <it...@code972.com>.
Thanks Prescott for bringing this up again :)
Paul, the problem is no one can really know what it would take until they
have deep dived into the work, and even then decisions could and will
change. I will strongly advise against starting from scratch, although I do
think a lot in the current structure should change, but its going to be
much easier to change it in place, refactoring where needed, than starting
all over again. Once we kicked this off I personally will be happy with you
taking the analysis part of Lucene and porting it, its pretty much self
contained.
Re 3.6.2 work - you can just do that on a fork and send us PRs, its much
more straight forward than the v4 upgrade
Marcos, porting class by class is the fastest way to do this, we can then
concentrate on .NETifying and optimizing using .NET constructs.
That said, I think the way to go is create a branch out of the current git
master HEAD and label it "3.x", and start working on master towards a 4.3
compatible version. The actual port should be using a process that ensures
all Java classes are ported with their tests, and that those tests pass -
but I'm against committing any Java code to our repositories. The process
should probably be working on classes in some order (alphabetically, or
core classes first) and getting each class to compile before moving
forward. I don't mind about the project not being compilable for a month or
two.
Once this is done a process of .NETifying and proofing the code can be
started, at which point we will already have a working v4 version so it
will be easier to keep up with the Java project.
The first step IMO is to stabilize the test suite so tests could more or
less be copied and pasted (e.g. implementing Java-like assertEquals methods
etc; I find xUnit to be much easier to work with than NUnit). I already did
some work there but there's still a lot to do.
Unfortunately I can't dedicate time myself at this point, but I should be
back in business in August, at which point I can dedicate several hours a
week. Until then I'll be happy to watch closely and even coordinate the
work to some extent.
On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <ma...@gmail.com>wrote:
> It really sounds good to me, this is a kick start =). I haven't contributed
> anything
> yet, but I would like to help you all to get this job done.
>
> I'm completely agree with Paul and Prescott.
>
> I know that there is a high commitment for keep the retrocompatibility on
> Lucene. Does Java Lucene API gets big changes every release?
>
> Is the Lucene.Net a port from a stable version from a Lucene version,
> right? If the Lucene API gets only minor changes every stable release (or
> keep most of its source-code), we could compare the versions, check the
> differences and bring them to Lucene.Net. Again, I haven't contributed with
> yet, so I don't know how it is (just an idea).
>
> What's your approach for implement simple performance improvements (without
> adding references or changing methods signatures)? Does it could be done,
> or "follow the java version only"?
>
>
>
> 2013/6/6 Paul Irwin <pi...@feature23.com>
>
> > This is just an "outsider" suggestion as I haven't contributed anything
> > yet, although I will definitely help with the 4.x work as I have a vested
> > interest in seeing that get completed. I think there should be one person
> > (or perhaps two) guiding what the structure and workflow will look like
> to
> > avoid chaos. If the 4.x work is going to be starting from scratch as a
> > fresh port, that person should set up the project, get everything going
> in
> > source control, create the folder structure, maybe stub out some classes,
> > etc. Then divide and conquer with anyone interested in contributing,
> > perhaps by namespace.
> >
> > I like the idea of throwing the java code in there so it's easy to
> > reference.
> >
> > Again, I can work on Lucene.Net.Documents, Lucene.Net.Analysis, or
> > Lucene.Net.Store -- or any others, those are just the ones I'm most
> > familiar with the inner workings. Tell me what to do and I'll get started
> > on my fork.
> >
> > Paul Irwin
> >
> >
> > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <geobmx540@hotmail.com
> > >wrote:
> >
> > > Hey guys -
> > > I know I've been MIA a little while. We have a board report due soon -
> I
> > > think it prudent that we advise them that we seem to have stalled
> > somewhat.
> > > We've got a few low hanging items out of of jira and have been
> responsive
> > > on the mailing list to community questions, but I don't think we've
> done
> > > anything to move forward with 4.0.
> > > To that end - I'd like to *try* and start us back up moving forward.
> What
> > > is the best way to accomplish this? If we took the java lucene 4.0 code
> > and
> > > committed that java to our branch and then just let people pull that
> down
> > > and being changing / modifying is that one way to maybe make some
> forward
> > > progress?
> > > ~P
> >
>
>
>
> --
> --
> Marcos Lima
> Software Developer/Tech Lead
> marcoslimagon@gmail.com
> tel: +55 (19) 9798-9335
>
Re: Lucene 4.0
Posted by Marcos Lima <ma...@gmail.com>.
It really sounds good to me, this is a kick start =). I haven't contributed
anything
yet, but I would like to help you all to get this job done.
I'm completely agree with Paul and Prescott.
I know that there is a high commitment for keep the retrocompatibility on
Lucene. Does Java Lucene API gets big changes every release?
Is the Lucene.Net a port from a stable version from a Lucene version,
right? If the Lucene API gets only minor changes every stable release (or
keep most of its source-code), we could compare the versions, check the
differences and bring them to Lucene.Net. Again, I haven't contributed with
yet, so I don't know how it is (just an idea).
What's your approach for implement simple performance improvements (without
adding references or changing methods signatures)? Does it could be done,
or "follow the java version only"?
2013/6/6 Paul Irwin <pi...@feature23.com>
> This is just an "outsider" suggestion as I haven't contributed anything
> yet, although I will definitely help with the 4.x work as I have a vested
> interest in seeing that get completed. I think there should be one person
> (or perhaps two) guiding what the structure and workflow will look like to
> avoid chaos. If the 4.x work is going to be starting from scratch as a
> fresh port, that person should set up the project, get everything going in
> source control, create the folder structure, maybe stub out some classes,
> etc. Then divide and conquer with anyone interested in contributing,
> perhaps by namespace.
>
> I like the idea of throwing the java code in there so it's easy to
> reference.
>
> Again, I can work on Lucene.Net.Documents, Lucene.Net.Analysis, or
> Lucene.Net.Store -- or any others, those are just the ones I'm most
> familiar with the inner workings. Tell me what to do and I'll get started
> on my fork.
>
> Paul Irwin
>
>
> On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <geobmx540@hotmail.com
> >wrote:
>
> > Hey guys -
> > I know I've been MIA a little while. We have a board report due soon - I
> > think it prudent that we advise them that we seem to have stalled
> somewhat.
> > We've got a few low hanging items out of of jira and have been responsive
> > on the mailing list to community questions, but I don't think we've done
> > anything to move forward with 4.0.
> > To that end - I'd like to *try* and start us back up moving forward. What
> > is the best way to accomplish this? If we took the java lucene 4.0 code
> and
> > committed that java to our branch and then just let people pull that down
> > and being changing / modifying is that one way to maybe make some forward
> > progress?
> > ~P
>
--
--
Marcos Lima
Software Developer/Tech Lead
marcoslimagon@gmail.com
tel: +55 (19) 9798-9335
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
Sorry for the follow-up email, but I also don't mind working on bringing
the 3.x side up to 3.6.2 compatibility. Is the SOP to create a 3.6 branch
and work from there?
On Thu, Jun 6, 2013 at 3:05 PM, Paul Irwin <pi...@feature23.com> wrote:
> This is just an "outsider" suggestion as I haven't contributed anything
> yet, although I will definitely help with the 4.x work as I have a vested
> interest in seeing that get completed. I think there should be one person
> (or perhaps two) guiding what the structure and workflow will look like to
> avoid chaos. If the 4.x work is going to be starting from scratch as a
> fresh port, that person should set up the project, get everything going in
> source control, create the folder structure, maybe stub out some classes,
> etc. Then divide and conquer with anyone interested in contributing,
> perhaps by namespace.
>
> I like the idea of throwing the java code in there so it's easy to
> reference.
>
> Again, I can work on Lucene.Net.Documents, Lucene.Net.Analysis, or
> Lucene.Net.Store -- or any others, those are just the ones I'm most
> familiar with the inner workings. Tell me what to do and I'll get started
> on my fork.
>
> Paul Irwin
>
>
> On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <ge...@hotmail.com>wrote:
>
>> Hey guys -
>> I know I've been MIA a little while. We have a board report due soon - I
>> think it prudent that we advise them that we seem to have stalled somewhat.
>> We've got a few low hanging items out of of jira and have been responsive
>> on the mailing list to community questions, but I don't think we've done
>> anything to move forward with 4.0.
>> To that end - I'd like to *try* and start us back up moving forward. What
>> is the best way to accomplish this? If we took the java lucene 4.0 code and
>> committed that java to our branch and then just let people pull that down
>> and being changing / modifying is that one way to maybe make some forward
>> progress?
>> ~P
>
>
>
Re: Lucene 4.0
Posted by Paul Irwin <pi...@feature23.com>.
This is just an "outsider" suggestion as I haven't contributed anything
yet, although I will definitely help with the 4.x work as I have a vested
interest in seeing that get completed. I think there should be one person
(or perhaps two) guiding what the structure and workflow will look like to
avoid chaos. If the 4.x work is going to be starting from scratch as a
fresh port, that person should set up the project, get everything going in
source control, create the folder structure, maybe stub out some classes,
etc. Then divide and conquer with anyone interested in contributing,
perhaps by namespace.
I like the idea of throwing the java code in there so it's easy to
reference.
Again, I can work on Lucene.Net.Documents, Lucene.Net.Analysis, or
Lucene.Net.Store -- or any others, those are just the ones I'm most
familiar with the inner workings. Tell me what to do and I'll get started
on my fork.
Paul Irwin
On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <ge...@hotmail.com>wrote:
> Hey guys -
> I know I've been MIA a little while. We have a board report due soon - I
> think it prudent that we advise them that we seem to have stalled somewhat.
> We've got a few low hanging items out of of jira and have been responsive
> on the mailing list to community questions, but I don't think we've done
> anything to move forward with 4.0.
> To that end - I'd like to *try* and start us back up moving forward. What
> is the best way to accomplish this? If we took the java lucene 4.0 code and
> committed that java to our branch and then just let people pull that down
> and being changing / modifying is that one way to maybe make some forward
> progress?
> ~P