lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lombardena...@gmail.com
Subject Re: Lucene 4.0
Date Fri, 09 Aug 2013 02:10:04 GMT
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 <itamar@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 <pirwin@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 <pirwin@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 <pirwin@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 <pirwin@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 <pirwin@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 <pirwin@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
>> 

Mime
View raw message