RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Scott Lombard]

Digy,

Should your 2.9.4g be renamed to 3.0 something and then be released in the
future as a 3.0 release?  The current trunk could be released under the tag
2.9.4.

Scott

 -Original Message-
 From: Digy [mailto:digyd...@gmail.com]
 Sent: Saturday, July 02, 2011 7:04 PM
 To: lucene-net-...@lucene.apache.org
 Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
 No no. It was just an example. As you already know, there are a lot of
 changes in contrib codes related with those API changes in
 Lucene.Net.2.9.4g core.
 Therefore, I see no option like merging other that copying.
 
 DIGY
 
 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Sunday, July 03, 2011 1:53 AM
 To: lucene-net-...@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
 I'm not sure that I see a conflict. Are you referring to the use of
 generic
 Dictionary in IndexInput in 2.9.4g? That's the only point where I could
 see
 a possible problem, but generic dictionaries are supported on WP7, so it
 should be fine.
 
 In which case, the two should merge and compile correctly.
 
 Thanks,
 Troy
 
 
 On Sat, Jul 2, 2011 at 2:36 PM, Digy digyd...@gmail.com wrote:
 
  OK. Maybe I asked wrong question, Suppose I committed
  IsolatedStorageDirectory only to trunk. How would you merge this branch
 
  trunk?
 
  DIGY.
 
  -Original Message-
  From: Troy Howard [mailto:thowar...@gmail.com]
  Sent: Sunday, July 03, 2011 12:28 AM
  To: lucene-net-...@lucene.apache.org
  Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  Yes. But if there are commits to trunk before that happens it's a merge.
 
  -T
  On Jul 2, 2011 1:53 PM, Digy digyd...@gmail.com wrote:
   Troy,
  
   What do you mean by merging? 2.9.4g is a superset of 2.9.4 and has
   * bux fixes like LUCENENET-414
   * new features like LUCENENET-429, MemoryMappedDirectory(although not
  used
  yet) , PartiallyTrustedAppDomain tests
   * improvements like LUCENENET-427, LUCENENET-418, Refactoring of
  SupportClass
   * API changes like
   - StopAnalyzer(Liststring stopWords)
   - Query.ExtractTerms(ICollectionstring)
   - TopDocs.TotalHits, TopDocs.ScoreDocs
   * readibily-changes like replacing some abstract methods with Func,
  while(XXX.MoveNext())s with foreachs
   etc.
  
   Is it something like creating a 2.9.4 tag and replacing trunk with
  2.9.4g?
  
   DIGY
  
   -Original Message-
   From: Troy Howard [mailto:thowar...@gmail.com]
   Sent: Friday, July 01, 2011 12:36 AM
   To: lucene-net-...@lucene.apache.org
   Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
 needed?
  
   DIGY - Re: Why do I wait.. That's mostly because I intend to make some
  deep
   changes, which would make merging the 2.9.4g branch back to trunk
  difficult.
   So, it's easier to merge those changes first. Also, I won't have
 enough
  time
   to make my changes until a little way in the future, but probably do
 have
   the time to put together another release, so I'll do that first
 because
  it
   fits with my work/life schedule.
  
   Thanks,
   Troy
  
  
   On Thu, Jun 30, 2011 at 1:19 PM, Digy digyd...@gmail.com wrote:
  
   Michael,
   You interpret the report as whoever commits code wins? But when I
 look
  at
   it, I see a lof of talk, no work. .Net community is not interested
 in
   contributing.
   I really don't understand what hinders people to work on Lucene.Net.
 As
  I
   did for 2.9.4g, grab the code, do whatever you want on it and submit
  back.
   If it doesn't fit to the project's direction it can still find a
 place
  in
   contrib or in branch. All of the approaches can live side by side
  happily
  in
   the Lucene.Net repository.
  
   Troy,
   I also don't understand why do you wait for 2.9.4g? It is a *branch*
 and
   has nothing to do with the trunk. It need not be an offical release
 and
  can
   live in branch as a PoC.
  
  
   As a result, I got bored to listen to this should be done that way.
  What
   I want to see is I did it that way, should we continue with this.
  
   DIGY
  
  
  
  
   -Original Message-
   From: Troy Howard [mailto:thowar...@gmail.com]
   Sent: Thursday, June 30, 2011 10:47 PM
   To: lucene-net-...@lucene.apache.org
   Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
 needed?
  
   Michael,
  
   I agree with everything you said. My point in saying whoever commits
  code
   wins was to illustrate the reality of how and why the project has
 the
   current form.
  
   Building consensus is difficult. It is an essential first step before
 we
   can
   do something like make a list of bit-sized pieces of work that others
  can
   work on.
  
   This is why my real message of Let's find a way to accommodate both
 is
  so
   important. It allows us to build consensus, so that we can settle on
 a
   direction and structure our work.
  
   Until we accomplish that, it really is whoever

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

 I've add a Paths Class under the Lucene.Net.Tests Util folder
Since it is a Lucene.Net specific code, may Support be a better place?
DIGY

-Original Message-
From: Michael Herndon [mailto:mhern...@wickedsoftware.net] 
Sent: Friday, July 01, 2011 11:53 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

@Rory,

Jira in the past had the ability to create sub tasks or convert a current
task to a sub task. I'm guessing that apache's jira should be able to do
that.

@All,

I've add a Paths Class under the Lucene.Net.Tests Util folder (feel free to
rename, refactor as long as the tests still work) to help with working with
paths in general.  This should help with forming paths relative to the temp
directory or the project root.

NUnit's Shadow Copy tends to throw people off when trying to get the path of
the current assembly being tested to build up a relative path, the Path
class should help with that.

- Michael

On Fri, Jul 1, 2011 at 4:09 PM, Rory Plaire codekai...@gmail.com wrote:

 My thinking is just a separate ticket for each one. This makes the work
 easier to manage and gives a better sense about how much work is left as
 well as makes it easier to prioritize independent issues. We could link
all
 the sub-issues to a single task / feature / whatever (that is, if JIRA has
 that capability).

 -r
 On Fri, Jul 1, 2011 at 12:48 PM, Michael Herndon 
 mhern...@wickedsoftware.net wrote:

  I think whatever makes sense to do.
 
  possibly create one jira for now with a running list that can be
modified
  and possibly as people pull from that list, cross things off or create a
  separate ticket that links back to to the main one.
 
 
 
 
  On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire codekai...@gmail.com
 wrote:
 
   @Michael -
  
   Should that list be in JIRA? It would be easier to manage, I think...
  
   If yes, I'll happily do it.
  
   -r
  
   On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon 
   mhern...@wickedsoftware.net
wrote:
  
* need to document what the build script does.  whut grammerz?
   
On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon 
mhern...@wickedsoftware.net wrote:
   
 @Rory, @All,

 The only tickets I currently have for those is LUCENE-419,
 LUCENE-418

 418, I should be able to push into the 2.9.4g branch tonight.
  419
  is
   a
 long term goal and not as important as getting the tests fixed, of
  have
the
 tests broken down into what is actually a unit test, functional
 test,
perf
 or long running test. I can get into more why it needs to be done.

 I'll also need to make document the what build script currently
 does
  on
the
 wiki  and make a few notes about testing, like using the
  RAMDirectory,
 etc.

 Things that need to get done or even be discussed.
  * There needs to be a running list of things to do/not to do with
testing.
 I don't know if this goes in a jira or do we keep a running list
on
  the
wiki
 or site for people to pick up and  help with.
  * Tests need to run on mono and not Fail (there is a good deal of
failing
 tests on mono, mostly due to the temp directory have the C:\ in
the
path).
  * Assert.ThrowExceptionType() needs to be used instead of
  Try/Catch
 Assert.Fail.  **
  * File  Path combines to the temp directory need helper methods,
  * e,g, having this in a hundred places is bad   new

   
  
 

System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get(tempDir,
 ), testIndex));
  * We should still be testing deprecated methods, but we need to
 use
#pragma
 warning disable/enable 0618  for testing those. otherwise compiler
warnings
 are too numerous to be anywhere near helpful.
  * We should only be using deprecated methods in places where they
  are
 being explicitly tested, other tests that need that functionality
 in
order
 to validate those tests should be re factored to use methods that
 are
   not
 deprecated.
  * Identify code that could be abstracted into test utility
 classes.
  * Infrastructure Validation tests need to be made, anything that
  seems
 like infrastructure.  e.g. does the temp directory exist, does the
folders
 that the tests use inside the temp directory exist, can we
 read/write
   to
 those folders. (if a ton of tests fail due to the file system, we
   should
be
 able to point out that it was due to permissions or missing
 folders,
files,
 etc).
  * Identify what classes need an interface, abstract class or
  inherited
in
 order to create testing mocks. (once those classes are created,
 they
should
 be documented in the wiki).



 ** Asset.Throws needs to replace stuff like the following. We
 should
   also
 be checking the messages for exceptions and make sure they make
 sense

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

Troy,

What do you mean by merging? 2.9.4g is a superset of 2.9.4 and has
* bux fixes like LUCENENET-414 
* new features  like LUCENENET-429, MemoryMappedDirectory(although not used 
yet) ,  PartiallyTrustedAppDomain tests
* improvements like LUCENENET-427, LUCENENET-418,  Refactoring of SupportClass
* API changes like 
  - StopAnalyzer(Liststring stopWords)
  - Query.ExtractTerms(ICollectionstring)
  - TopDocs.TotalHits, TopDocs.ScoreDocs
* readibily-changes like replacing some abstract methods with Func, 
while(XXX.MoveNext())s with foreachs
etc.

Is it something like creating a 2.9.4 tag and replacing trunk with 2.9.4g?

DIGY

-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com] 
Sent: Friday, July 01, 2011 12:36 AM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

DIGY - Re: Why do I wait.. That's mostly because I intend to make some deep
changes, which would make merging the 2.9.4g branch back to trunk difficult.
So, it's easier to merge those changes first. Also, I won't have enough time
to make my changes until a little way in the future, but probably do have
the time to put together another release, so I'll do that first because it
fits with my work/life schedule.

Thanks,
Troy


On Thu, Jun 30, 2011 at 1:19 PM, Digy digyd...@gmail.com wrote:

 Michael,
 You interpret the report as whoever commits code wins? But when I look at
 it, I see a lof of talk, no work. .Net community is not interested in
 contributing.
 I really don't understand what hinders people to work on Lucene.Net. As I
 did for 2.9.4g, grab the code, do whatever you want on it and submit back.
 If it doesn't fit to the project's direction it can still find a place in
 contrib or in branch. All of the approaches can live side by side happily in
 the Lucene.Net repository.

 Troy,
 I also don't understand why do you wait for 2.9.4g? It is a *branch* and
 has nothing to do with the trunk. It need not be an offical release and can
 live in branch as a PoC.


 As a result, I got bored to listen to this should be done that way. What
 I want to see is I did it that way, should we continue with this.

 DIGY




 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Thursday, June 30, 2011 10:47 PM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 Michael,

 I agree with everything you said. My point in saying whoever commits code
 wins was to illustrate the reality of how and why the project has the
 current form.

 Building consensus is difficult. It is an essential first step before we
 can
 do something like make a list of bit-sized pieces of work that others can
 work on.

 This is why my real message of Let's find a way to accommodate both is so
 important. It allows us to build consensus, so that we can settle on a
 direction and structure our work.

 Until we accomplish that, it really is whoever commits code wins, and
 that
 is an unhealthy and unmaintainable way to operate.

 From a technical perspective, your statements about the unit tests are
 completely accurate. They really need a LOT of reworking. That's the very
 first step before making any significant changes. Part of the problem is
 that the tests themselves are not well written. The other part is that the
 Lucene object model was not designed for testability, and it makes writing
 good tests more difficult, and certain tests might not be possible. It will
 be difficult to write good unit tests without re-structuring. The biggest
 issue is the use of abstract classes with base behaviour vs interfaces or
 fully abstracted classes. Makes mocking tough. This is the direction I was
 going when I started the Lucere project. I'd like to start in on that work
 after the 2.9.4g release.

 Thanks,
 Troy


 On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon 
 mhern...@wickedsoftware.net wrote:

  I'd say that is all the more reasons that we need to work smarter and not
  harder. I'd also say thats a good reason to make sure we build consensus
  rather than just saying whoever commits code wins.
 
  And its a damn good reason to focus on the effort of growing the number
 of
  contributors and lowing the barrier to submitting patches, breaking
 things
  down into pieces that people would feel confident to work on without
  being overwhelmed by the complexity of Lucene.Net.
 
  There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
  internals and index formats are significantly different including nixing
  the
  current vint file format and using byte[] array slices for Terms instead
 of
  char[].
 
  So while porting 1 to 1 while require less knowledge or thought, its most
  likely going to require more hours of work. And Its definitely not going
 to
  guarantee the stability of the code or that its great code.
 
  I'd have to say that its not as stable as most would believe at the
 moment

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Troy Howard]

Yes. But if there are commits to trunk before that happens it's a merge.

-T
On Jul 2, 2011 1:53 PM, Digy digyd...@gmail.com wrote:
 Troy,

 What do you mean by merging? 2.9.4g is a superset of 2.9.4 and has
 * bux fixes like LUCENENET-414
 * new features like LUCENENET-429, MemoryMappedDirectory(although not used
yet) , PartiallyTrustedAppDomain tests
 * improvements like LUCENENET-427, LUCENENET-418, Refactoring of
SupportClass
 * API changes like
 - StopAnalyzer(Liststring stopWords)
 - Query.ExtractTerms(ICollectionstring)
 - TopDocs.TotalHits, TopDocs.ScoreDocs
 * readibily-changes like replacing some abstract methods with Func,
while(XXX.MoveNext())s with foreachs
 etc.

 Is it something like creating a 2.9.4 tag and replacing trunk with 2.9.4g?

 DIGY

 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Friday, July 01, 2011 12:36 AM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 DIGY - Re: Why do I wait.. That's mostly because I intend to make some
deep
 changes, which would make merging the 2.9.4g branch back to trunk
difficult.
 So, it's easier to merge those changes first. Also, I won't have enough
time
 to make my changes until a little way in the future, but probably do have
 the time to put together another release, so I'll do that first because it
 fits with my work/life schedule.

 Thanks,
 Troy


 On Thu, Jun 30, 2011 at 1:19 PM, Digy digyd...@gmail.com wrote:

 Michael,
 You interpret the report as whoever commits code wins? But when I look
at
 it, I see a lof of talk, no work. .Net community is not interested in
 contributing.
 I really don't understand what hinders people to work on Lucene.Net. As I
 did for 2.9.4g, grab the code, do whatever you want on it and submit
back.
 If it doesn't fit to the project's direction it can still find a place in
 contrib or in branch. All of the approaches can live side by side happily
in
 the Lucene.Net repository.

 Troy,
 I also don't understand why do you wait for 2.9.4g? It is a *branch* and
 has nothing to do with the trunk. It need not be an offical release and
can
 live in branch as a PoC.


 As a result, I got bored to listen to this should be done that way.
What
 I want to see is I did it that way, should we continue with this.

 DIGY




 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Thursday, June 30, 2011 10:47 PM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 Michael,

 I agree with everything you said. My point in saying whoever commits
code
 wins was to illustrate the reality of how and why the project has the
 current form.

 Building consensus is difficult. It is an essential first step before we
 can
 do something like make a list of bit-sized pieces of work that others can
 work on.

 This is why my real message of Let's find a way to accommodate both is
so
 important. It allows us to build consensus, so that we can settle on a
 direction and structure our work.

 Until we accomplish that, it really is whoever commits code wins, and
 that
 is an unhealthy and unmaintainable way to operate.

 From a technical perspective, your statements about the unit tests are
 completely accurate. They really need a LOT of reworking. That's the very
 first step before making any significant changes. Part of the problem is
 that the tests themselves are not well written. The other part is that
the
 Lucene object model was not designed for testability, and it makes
writing
 good tests more difficult, and certain tests might not be possible. It
will
 be difficult to write good unit tests without re-structuring. The biggest
 issue is the use of abstract classes with base behaviour vs interfaces or
 fully abstracted classes. Makes mocking tough. This is the direction I
was
 going when I started the Lucere project. I'd like to start in on that
work
 after the 2.9.4g release.

 Thanks,
 Troy


 On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon 
 mhern...@wickedsoftware.net wrote:

  I'd say that is all the more reasons that we need to work smarter and
not
  harder. I'd also say thats a good reason to make sure we build
consensus
  rather than just saying whoever commits code wins.
 
  And its a damn good reason to focus on the effort of growing the number
 of
  contributors and lowing the barrier to submitting patches, breaking
 things
  down into pieces that people would feel confident to work on without
  being overwhelmed by the complexity of Lucene.Net.
 
  There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
  internals and index formats are significantly different including
nixing
  the
  current vint file format and using byte[] array slices for Terms
instead
 of
  char[].
 
  So while porting 1 to 1 while require less knowledge or thought, its
most
  likely going to require more hours of work. And Its definitely not
going

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

OK. Maybe I asked wrong question, Suppose I committed IsolatedStorageDirectory 
only to trunk. How would you merge this branch  trunk?

DIGY.

-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com] 
Sent: Sunday, July 03, 2011 12:28 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Yes. But if there are commits to trunk before that happens it's a merge.

-T
On Jul 2, 2011 1:53 PM, Digy digyd...@gmail.com wrote:
 Troy,

 What do you mean by merging? 2.9.4g is a superset of 2.9.4 and has
 * bux fixes like LUCENENET-414
 * new features like LUCENENET-429, MemoryMappedDirectory(although not used
yet) , PartiallyTrustedAppDomain tests
 * improvements like LUCENENET-427, LUCENENET-418, Refactoring of
SupportClass
 * API changes like
 - StopAnalyzer(Liststring stopWords)
 - Query.ExtractTerms(ICollectionstring)
 - TopDocs.TotalHits, TopDocs.ScoreDocs
 * readibily-changes like replacing some abstract methods with Func,
while(XXX.MoveNext())s with foreachs
 etc.

 Is it something like creating a 2.9.4 tag and replacing trunk with 2.9.4g?

 DIGY

 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Friday, July 01, 2011 12:36 AM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 DIGY - Re: Why do I wait.. That's mostly because I intend to make some
deep
 changes, which would make merging the 2.9.4g branch back to trunk
difficult.
 So, it's easier to merge those changes first. Also, I won't have enough
time
 to make my changes until a little way in the future, but probably do have
 the time to put together another release, so I'll do that first because it
 fits with my work/life schedule.

 Thanks,
 Troy


 On Thu, Jun 30, 2011 at 1:19 PM, Digy digyd...@gmail.com wrote:

 Michael,
 You interpret the report as whoever commits code wins? But when I look
at
 it, I see a lof of talk, no work. .Net community is not interested in
 contributing.
 I really don't understand what hinders people to work on Lucene.Net. As I
 did for 2.9.4g, grab the code, do whatever you want on it and submit
back.
 If it doesn't fit to the project's direction it can still find a place in
 contrib or in branch. All of the approaches can live side by side happily
in
 the Lucene.Net repository.

 Troy,
 I also don't understand why do you wait for 2.9.4g? It is a *branch* and
 has nothing to do with the trunk. It need not be an offical release and
can
 live in branch as a PoC.


 As a result, I got bored to listen to this should be done that way.
What
 I want to see is I did it that way, should we continue with this.

 DIGY




 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Thursday, June 30, 2011 10:47 PM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 Michael,

 I agree with everything you said. My point in saying whoever commits
code
 wins was to illustrate the reality of how and why the project has the
 current form.

 Building consensus is difficult. It is an essential first step before we
 can
 do something like make a list of bit-sized pieces of work that others can
 work on.

 This is why my real message of Let's find a way to accommodate both is
so
 important. It allows us to build consensus, so that we can settle on a
 direction and structure our work.

 Until we accomplish that, it really is whoever commits code wins, and
 that
 is an unhealthy and unmaintainable way to operate.

 From a technical perspective, your statements about the unit tests are
 completely accurate. They really need a LOT of reworking. That's the very
 first step before making any significant changes. Part of the problem is
 that the tests themselves are not well written. The other part is that
the
 Lucene object model was not designed for testability, and it makes
writing
 good tests more difficult, and certain tests might not be possible. It
will
 be difficult to write good unit tests without re-structuring. The biggest
 issue is the use of abstract classes with base behaviour vs interfaces or
 fully abstracted classes. Makes mocking tough. This is the direction I
was
 going when I started the Lucere project. I'd like to start in on that
work
 after the 2.9.4g release.

 Thanks,
 Troy


 On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon 
 mhern...@wickedsoftware.net wrote:

  I'd say that is all the more reasons that we need to work smarter and
not
  harder. I'd also say thats a good reason to make sure we build
consensus
  rather than just saying whoever commits code wins.
 
  And its a damn good reason to focus on the effort of growing the number
 of
  contributors and lowing the barrier to submitting patches, breaking
 things
  down into pieces that people would feel confident to work on without
  being overwhelmed by the complexity of Lucene.Net.
 
  There is a pretty big gap between

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Rory Plaire]

My thinking is just a separate ticket for each one. This makes the work
easier to manage and gives a better sense about how much work is left as
well as makes it easier to prioritize independent issues. We could link all
the sub-issues to a single task / feature / whatever (that is, if JIRA has
that capability).

-r
On Fri, Jul 1, 2011 at 12:48 PM, Michael Herndon 
mhern...@wickedsoftware.net wrote:

 I think whatever makes sense to do.

 possibly create one jira for now with a running list that can be modified
 and possibly as people pull from that list, cross things off or create a
 separate ticket that links back to to the main one.




 On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire codekai...@gmail.com wrote:

  @Michael -
 
  Should that list be in JIRA? It would be easier to manage, I think...
 
  If yes, I'll happily do it.
 
  -r
 
  On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon 
  mhern...@wickedsoftware.net
   wrote:
 
   * need to document what the build script does.  whut grammerz?
  
   On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon 
   mhern...@wickedsoftware.net wrote:
  
@Rory, @All,
   
The only tickets I currently have for those is LUCENE-419, LUCENE-418
   
418, I should be able to push into the 2.9.4g branch tonight.419
 is
  a
long term goal and not as important as getting the tests fixed, of
 have
   the
tests broken down into what is actually a unit test, functional test,
   perf
or long running test. I can get into more why it needs to be done.
   
I'll also need to make document the what build script currently does
 on
   the
wiki  and make a few notes about testing, like using the
 RAMDirectory,
etc.
   
Things that need to get done or even be discussed.
 * There needs to be a running list of things to do/not to do with
   testing.
I don't know if this goes in a jira or do we keep a running list on
 the
   wiki
or site for people to pick up and  help with.
 * Tests need to run on mono and not Fail (there is a good deal of
   failing
tests on mono, mostly due to the temp directory have the C:\ in the
   path).
 * Assert.ThrowExceptionType() needs to be used instead of
 Try/Catch
Assert.Fail.  **
 * File  Path combines to the temp directory need helper methods,
 * e,g, having this in a hundred places is bad   new
   
  
 
 System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get(tempDir,
), testIndex));
 * We should still be testing deprecated methods, but we need to use
   #pragma
warning disable/enable 0618  for testing those. otherwise compiler
   warnings
are too numerous to be anywhere near helpful.
 * We should only be using deprecated methods in places where they
 are
being explicitly tested, other tests that need that functionality in
   order
to validate those tests should be re factored to use methods that are
  not
deprecated.
 * Identify code that could be abstracted into test utility classes.
 * Infrastructure Validation tests need to be made, anything that
 seems
like infrastructure.  e.g. does the temp directory exist, does the
   folders
that the tests use inside the temp directory exist, can we read/write
  to
those folders. (if a ton of tests fail due to the file system, we
  should
   be
able to point out that it was due to permissions or missing folders,
   files,
etc).
 * Identify what classes need an interface, abstract class or
 inherited
   in
order to create testing mocks. (once those classes are created, they
   should
be documented in the wiki).
   
   
   
** Asset.Throws needs to replace stuff like the following. We should
  also
be checking the messages for exceptions and make sure they make sense
  and
can help users fix isses if the exceptions are aimed at the library
   users.
try
{
d = DateTools.StringToDate(97); // no date
 Assert.Fail();
}
catch (System.FormatException e)
 {
/* expected exception */
}
   
On Thu, Jun 30, 2011 at 11:48 PM, Rory Plaire codekai...@gmail.com
   wrote:
   
So, veering towards action - are there concrete tasks written up
   anywhere
for the unit tests? If a poor schlep like me wanted to dig in and
  start
   to
improve them, where would I get the understanding of what is good
 and
   what
needs help?
   
-r
   
On Thu, Jun 30, 2011 at 3:29 PM, Digy digyd...@gmail.com wrote:
   
 I can not say I like this approach, but till we find an automated
way(with
 good results), it seems to be the only way we can use.

 DIGY

 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Friday, July 01, 2011 12:43 AM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
   needed?

 Scott -

 The idea of the automated port is still worth doing. Perhaps it
  makes

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Michael Herndon]

 action - are there concrete tasks written up
anywhere
 for the unit tests? If a poor schlep like me wanted to dig in and
   start
to
 improve them, where would I get the understanding of what is good
  and
what
 needs help?

 -r

 On Thu, Jun 30, 2011 at 3:29 PM, Digy digyd...@gmail.com wrote:

  I can not say I like this approach, but till we find an
 automated
 way(with
  good results), it seems to be the only way we can use.
 
  DIGY
 
  -Original Message-
  From: Troy Howard [mailto:thowar...@gmail.com]
  Sent: Friday, July 01, 2011 12:43 AM
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
needed?
 
  Scott -
 
  The idea of the automated port is still worth doing. Perhaps it
   makes
 sense
  for someone more passionate about the line-by-line idea to do
 that
work?
 
  I would say, focus on what makes sense to you. Being productive,
 regardless
  of the specific direction, is what will be most valuable. Once
 you
 start,
  others will join and momentum will build. That is how these
 things
work.
 
  I like DIGY's approach too, but the problem with it is that it
 is
  a
  never-ending manual task. The theory behind the automated port
 is
   that
 it
  may reduce the manual work. It is complicated, but once it's
 built
   and
  works, it will save a lot of future development hours. If it's
  built
in
 a
  sufficiently general manner, it could be useful for other
 project
   like
  Lucene.Net that want to automate a port from Java to C#.
 
  It might make sense for that to be a separate project from
   Lucene.Net
  though.
 
  -T
 
 
  On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard 
lombardena...@gmail.com
  wrote:
 
   Ok I think I asked the wrong question.  I am trying to figure
  out
 where
  to
   put my time.  I was thinking about working on the automated
   porting
  system,
   but when I saw the response to the .NET 4.0 discussions I
  started
   to
   question if that is the right direction.  The community seemed
  to
   be
 more
   interested in the .NET features.
  
   The complexity of the automated tool is going to become very
  high
and
  will
   probably end up with a line-for-line style port.  So I keep
  asking
my
  self
   is the automated tool worth it.  I don't think it is.
  
   I like the method has been Digy is using for porting the code.
   So
   I
  guess
   for me the real question is Digy where did you see 2.9.4g
 going
   next
 and
   what do you need help on?
  
   Scott
  
  
  
  
-Original Message-
From: Digy [mailto:digyd...@gmail.com]
Sent: Thursday, June 30, 2011 4:20 PM
To: lucene-net-dev@lucene.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave
  port
  needed?
   
Michael,
You interpret the report as whoever commits code wins? But
   when
I
  look
at it, I see a lof of talk, no work. .Net community is not
 interested
   in
contributing.
I really don't understand what hinders people to work on
Lucene.Net.
 As
  I
did for 2.9.4g, grab the code, do whatever you want on it
 and
submit
   back.
If it doesn't fit to the project's direction it can still
 find
  a
 place
  in
contrib or in branch. All of the approaches can live side by
   side
  happily
in the Lucene.Net repository.
   
Troy,
I also don't understand why do you wait for 2.9.4g? It is a
*branch*
  and
has nothing to do with the trunk. It need not be an offical
release
 and
can live in branch as a PoC.
   
   
As a result, I got bored to listen to this should be done
  that
 way.
   What
I want to see is I did it that way, should we continue with
this.
   
DIGY
   
   
   
   
-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com]
Sent: Thursday, June 30, 2011 10:47 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave
  port
  needed?
   
Michael,
   
I agree with everything you said. My point in saying
 whoever
 commits
   code
wins was to illustrate the reality of how and why the
 project
   has
 the
current form.
   
Building consensus is difficult. It is an essential first
 step
 before
  we
can
do something like make a list of bit-sized pieces of work
 that
 others
  can
work

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Michael Herndon]

@Rory, @All,

The only tickets I currently have for those is LUCENE-419, LUCENE-418

418, I should be able to push into the 2.9.4g branch tonight.419 is a
long term goal and not as important as getting the tests fixed, of have the
tests broken down into what is actually a unit test, functional test, perf
or long running test. I can get into more why it needs to be done.

I'll also need to make document the what build script currently does on the
wiki  and make a few notes about testing, like using the RAMDirectory,
etc.

Things that need to get done or even be discussed.
 * There needs to be a running list of things to do/not to do with testing.
I don't know if this goes in a jira or do we keep a running list on the wiki
or site for people to pick up and  help with.
 * Tests need to run on mono and not Fail (there is a good deal of failing
tests on mono, mostly due to the temp directory have the C:\ in the path).
 * Assert.ThrowExceptionType() needs to be used instead of Try/Catch
Assert.Fail.  **
 * File  Path combines to the temp directory need helper methods,
 * e,g, having this in a hundred places is bad   new
System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get(tempDir,
), testIndex));
 * We should still be testing deprecated methods, but we need to use #pragma
warning disable/enable 0618  for testing those. otherwise compiler warnings
are too numerous to be anywhere near helpful.
 * We should only be using deprecated methods in places where they are being
explicitly tested, other tests that need that functionality in order to
validate those tests should be re factored to use methods that are not
deprecated.
 * Identify code that could be abstracted into test utility classes.
 * Infrastructure Validation tests need to be made, anything that seems like
infrastructure.  e.g. does the temp directory exist, does the folders that
the tests use inside the temp directory exist, can we read/write to those
folders. (if a ton of tests fail due to the file system, we should be able
to point out that it was due to permissions or missing folders, files,
etc).
 * Identify what classes need an interface, abstract class or inherited in
order to create testing mocks. (once those classes are created, they should
be documented in the wiki).



** Asset.Throws needs to replace stuff like the following. We should also be
checking the messages for exceptions and make sure they make sense and can
help users fix isses if the exceptions are aimed at the library users.
try
{
d = DateTools.StringToDate(97); // no date
Assert.Fail();
}
catch (System.FormatException e)
{
/* expected exception */
}

On Thu, Jun 30, 2011 at 11:48 PM, Rory Plaire codekai...@gmail.com wrote:

 So, veering towards action - are there concrete tasks written up anywhere
 for the unit tests? If a poor schlep like me wanted to dig in and start to
 improve them, where would I get the understanding of what is good and what
 needs help?

 -r

 On Thu, Jun 30, 2011 at 3:29 PM, Digy digyd...@gmail.com wrote:

  I can not say I like this approach, but till we find an automated
 way(with
  good results), it seems to be the only way we can use.
 
  DIGY
 
  -Original Message-
  From: Troy Howard [mailto:thowar...@gmail.com]
  Sent: Friday, July 01, 2011 12:43 AM
  To: lucene-net-...@lucene.apache.org
  Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  Scott -
 
  The idea of the automated port is still worth doing. Perhaps it makes
 sense
  for someone more passionate about the line-by-line idea to do that work?
 
  I would say, focus on what makes sense to you. Being productive,
 regardless
  of the specific direction, is what will be most valuable. Once you start,
  others will join and momentum will build. That is how these things work.
 
  I like DIGY's approach too, but the problem with it is that it is a
  never-ending manual task. The theory behind the automated port is that it
  may reduce the manual work. It is complicated, but once it's built and
  works, it will save a lot of future development hours. If it's built in a
  sufficiently general manner, it could be useful for other project like
  Lucene.Net that want to automate a port from Java to C#.
 
  It might make sense for that to be a separate project from Lucene.Net
  though.
 
  -T
 
 
  On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard lombardena...@gmail.com
  wrote:
 
   Ok I think I asked the wrong question.  I am trying to figure out where
  to
   put my time.  I was thinking about working on the automated porting
  system,
   but when I saw the response to the .NET 4.0 discussions I started to
   question if that is the right direction.  The community seemed to be
 more
   interested in the .NET features.
  
   The complexity of the automated tool is going to become very high and
  will
   probably end up with a line-for-line style port.  So I keep asking my
  self
   is the automated tool worth it.  I don't think it is.
  
   I like

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Michael Herndon]

* need to document what the build script does.  whut grammerz?

On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon 
mhern...@wickedsoftware.net wrote:

 @Rory, @All,

 The only tickets I currently have for those is LUCENE-419, LUCENE-418

 418, I should be able to push into the 2.9.4g branch tonight.419 is a
 long term goal and not as important as getting the tests fixed, of have the
 tests broken down into what is actually a unit test, functional test, perf
 or long running test. I can get into more why it needs to be done.

 I'll also need to make document the what build script currently does on the
 wiki  and make a few notes about testing, like using the RAMDirectory,
 etc.

 Things that need to get done or even be discussed.
  * There needs to be a running list of things to do/not to do with testing.
 I don't know if this goes in a jira or do we keep a running list on the wiki
 or site for people to pick up and  help with.
  * Tests need to run on mono and not Fail (there is a good deal of failing
 tests on mono, mostly due to the temp directory have the C:\ in the path).
  * Assert.ThrowExceptionType() needs to be used instead of Try/Catch
 Assert.Fail.  **
  * File  Path combines to the temp directory need helper methods,
  * e,g, having this in a hundred places is bad   new
 System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get(tempDir,
 ), testIndex));
  * We should still be testing deprecated methods, but we need to use #pragma
 warning disable/enable 0618  for testing those. otherwise compiler warnings
 are too numerous to be anywhere near helpful.
  * We should only be using deprecated methods in places where they are
 being explicitly tested, other tests that need that functionality in order
 to validate those tests should be re factored to use methods that are not
 deprecated.
  * Identify code that could be abstracted into test utility classes.
  * Infrastructure Validation tests need to be made, anything that seems
 like infrastructure.  e.g. does the temp directory exist, does the folders
 that the tests use inside the temp directory exist, can we read/write to
 those folders. (if a ton of tests fail due to the file system, we should be
 able to point out that it was due to permissions or missing folders, files,
 etc).
  * Identify what classes need an interface, abstract class or inherited in
 order to create testing mocks. (once those classes are created, they should
 be documented in the wiki).



 ** Asset.Throws needs to replace stuff like the following. We should also
 be checking the messages for exceptions and make sure they make sense and
 can help users fix isses if the exceptions are aimed at the library users.
 try
 {
 d = DateTools.StringToDate(97); // no date
  Assert.Fail();
 }
 catch (System.FormatException e)
  {
 /* expected exception */
 }

 On Thu, Jun 30, 2011 at 11:48 PM, Rory Plaire codekai...@gmail.comwrote:

 So, veering towards action - are there concrete tasks written up anywhere
 for the unit tests? If a poor schlep like me wanted to dig in and start to
 improve them, where would I get the understanding of what is good and what
 needs help?

 -r

 On Thu, Jun 30, 2011 at 3:29 PM, Digy digyd...@gmail.com wrote:

  I can not say I like this approach, but till we find an automated
 way(with
  good results), it seems to be the only way we can use.
 
  DIGY
 
  -Original Message-
  From: Troy Howard [mailto:thowar...@gmail.com]
  Sent: Friday, July 01, 2011 12:43 AM
  To: lucene-net-...@lucene.apache.org
  Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  Scott -
 
  The idea of the automated port is still worth doing. Perhaps it makes
 sense
  for someone more passionate about the line-by-line idea to do that work?
 
  I would say, focus on what makes sense to you. Being productive,
 regardless
  of the specific direction, is what will be most valuable. Once you
 start,
  others will join and momentum will build. That is how these things work.
 
  I like DIGY's approach too, but the problem with it is that it is a
  never-ending manual task. The theory behind the automated port is that
 it
  may reduce the manual work. It is complicated, but once it's built and
  works, it will save a lot of future development hours. If it's built in
 a
  sufficiently general manner, it could be useful for other project like
  Lucene.Net that want to automate a port from Java to C#.
 
  It might make sense for that to be a separate project from Lucene.Net
  though.
 
  -T
 
 
  On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard lombardena...@gmail.com
  wrote:
 
   Ok I think I asked the wrong question.  I am trying to figure out
 where
  to
   put my time.  I was thinking about working on the automated porting
  system,
   but when I saw the response to the .NET 4.0 discussions I started to
   question if that is the right direction.  The community seemed to be
 more
   interested in the .NET features.
  
   The complexity

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Rory Plaire]

@Michael -

Should that list be in JIRA? It would be easier to manage, I think...

If yes, I'll happily do it.

-r

On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon mhern...@wickedsoftware.net
 wrote:

 * need to document what the build script does.  whut grammerz?

 On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon 
 mhern...@wickedsoftware.net wrote:

  @Rory, @All,
 
  The only tickets I currently have for those is LUCENE-419, LUCENE-418
 
  418, I should be able to push into the 2.9.4g branch tonight.419 is a
  long term goal and not as important as getting the tests fixed, of have
 the
  tests broken down into what is actually a unit test, functional test,
 perf
  or long running test. I can get into more why it needs to be done.
 
  I'll also need to make document the what build script currently does on
 the
  wiki  and make a few notes about testing, like using the RAMDirectory,
  etc.
 
  Things that need to get done or even be discussed.
   * There needs to be a running list of things to do/not to do with
 testing.
  I don't know if this goes in a jira or do we keep a running list on the
 wiki
  or site for people to pick up and  help with.
   * Tests need to run on mono and not Fail (there is a good deal of
 failing
  tests on mono, mostly due to the temp directory have the C:\ in the
 path).
   * Assert.ThrowExceptionType() needs to be used instead of Try/Catch
  Assert.Fail.  **
   * File  Path combines to the temp directory need helper methods,
   * e,g, having this in a hundred places is bad   new
 
 System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get(tempDir,
  ), testIndex));
   * We should still be testing deprecated methods, but we need to use
 #pragma
  warning disable/enable 0618  for testing those. otherwise compiler
 warnings
  are too numerous to be anywhere near helpful.
   * We should only be using deprecated methods in places where they are
  being explicitly tested, other tests that need that functionality in
 order
  to validate those tests should be re factored to use methods that are not
  deprecated.
   * Identify code that could be abstracted into test utility classes.
   * Infrastructure Validation tests need to be made, anything that seems
  like infrastructure.  e.g. does the temp directory exist, does the
 folders
  that the tests use inside the temp directory exist, can we read/write to
  those folders. (if a ton of tests fail due to the file system, we should
 be
  able to point out that it was due to permissions or missing folders,
 files,
  etc).
   * Identify what classes need an interface, abstract class or inherited
 in
  order to create testing mocks. (once those classes are created, they
 should
  be documented in the wiki).
 
 
 
  ** Asset.Throws needs to replace stuff like the following. We should also
  be checking the messages for exceptions and make sure they make sense and
  can help users fix isses if the exceptions are aimed at the library
 users.
  try
  {
  d = DateTools.StringToDate(97); // no date
   Assert.Fail();
  }
  catch (System.FormatException e)
   {
  /* expected exception */
  }
 
  On Thu, Jun 30, 2011 at 11:48 PM, Rory Plaire codekai...@gmail.com
 wrote:
 
  So, veering towards action - are there concrete tasks written up
 anywhere
  for the unit tests? If a poor schlep like me wanted to dig in and start
 to
  improve them, where would I get the understanding of what is good and
 what
  needs help?
 
  -r
 
  On Thu, Jun 30, 2011 at 3:29 PM, Digy digyd...@gmail.com wrote:
 
   I can not say I like this approach, but till we find an automated
  way(with
   good results), it seems to be the only way we can use.
  
   DIGY
  
   -Original Message-
   From: Troy Howard [mailto:thowar...@gmail.com]
   Sent: Friday, July 01, 2011 12:43 AM
   To: lucene-net-...@lucene.apache.org
   Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
 needed?
  
   Scott -
  
   The idea of the automated port is still worth doing. Perhaps it makes
  sense
   for someone more passionate about the line-by-line idea to do that
 work?
  
   I would say, focus on what makes sense to you. Being productive,
  regardless
   of the specific direction, is what will be most valuable. Once you
  start,
   others will join and momentum will build. That is how these things
 work.
  
   I like DIGY's approach too, but the problem with it is that it is a
   never-ending manual task. The theory behind the automated port is that
  it
   may reduce the manual work. It is complicated, but once it's built and
   works, it will save a lot of future development hours. If it's built
 in
  a
   sufficiently general manner, it could be useful for other project like
   Lucene.Net that want to automate a port from Java to C#.
  
   It might make sense for that to be a separate project from Lucene.Net
   though.
  
   -T
  
  
   On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard 
 lombardena...@gmail.com
   wrote:
  
Ok I think I asked the wrong

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Michael Herndon]

I think whatever makes sense to do.

possibly create one jira for now with a running list that can be modified
and possibly as people pull from that list, cross things off or create a
separate ticket that links back to to the main one.




On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire codekai...@gmail.com wrote:

 @Michael -

 Should that list be in JIRA? It would be easier to manage, I think...

 If yes, I'll happily do it.

 -r

 On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon 
 mhern...@wickedsoftware.net
  wrote:

  * need to document what the build script does.  whut grammerz?
 
  On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon 
  mhern...@wickedsoftware.net wrote:
 
   @Rory, @All,
  
   The only tickets I currently have for those is LUCENE-419, LUCENE-418
  
   418, I should be able to push into the 2.9.4g branch tonight.419 is
 a
   long term goal and not as important as getting the tests fixed, of have
  the
   tests broken down into what is actually a unit test, functional test,
  perf
   or long running test. I can get into more why it needs to be done.
  
   I'll also need to make document the what build script currently does on
  the
   wiki  and make a few notes about testing, like using the RAMDirectory,
   etc.
  
   Things that need to get done or even be discussed.
* There needs to be a running list of things to do/not to do with
  testing.
   I don't know if this goes in a jira or do we keep a running list on the
  wiki
   or site for people to pick up and  help with.
* Tests need to run on mono and not Fail (there is a good deal of
  failing
   tests on mono, mostly due to the temp directory have the C:\ in the
  path).
* Assert.ThrowExceptionType() needs to be used instead of Try/Catch
   Assert.Fail.  **
* File  Path combines to the temp directory need helper methods,
* e,g, having this in a hundred places is bad   new
  
 
 System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get(tempDir,
   ), testIndex));
* We should still be testing deprecated methods, but we need to use
  #pragma
   warning disable/enable 0618  for testing those. otherwise compiler
  warnings
   are too numerous to be anywhere near helpful.
* We should only be using deprecated methods in places where they are
   being explicitly tested, other tests that need that functionality in
  order
   to validate those tests should be re factored to use methods that are
 not
   deprecated.
* Identify code that could be abstracted into test utility classes.
* Infrastructure Validation tests need to be made, anything that seems
   like infrastructure.  e.g. does the temp directory exist, does the
  folders
   that the tests use inside the temp directory exist, can we read/write
 to
   those folders. (if a ton of tests fail due to the file system, we
 should
  be
   able to point out that it was due to permissions or missing folders,
  files,
   etc).
* Identify what classes need an interface, abstract class or inherited
  in
   order to create testing mocks. (once those classes are created, they
  should
   be documented in the wiki).
  
  
  
   ** Asset.Throws needs to replace stuff like the following. We should
 also
   be checking the messages for exceptions and make sure they make sense
 and
   can help users fix isses if the exceptions are aimed at the library
  users.
   try
   {
   d = DateTools.StringToDate(97); // no date
Assert.Fail();
   }
   catch (System.FormatException e)
{
   /* expected exception */
   }
  
   On Thu, Jun 30, 2011 at 11:48 PM, Rory Plaire codekai...@gmail.com
  wrote:
  
   So, veering towards action - are there concrete tasks written up
  anywhere
   for the unit tests? If a poor schlep like me wanted to dig in and
 start
  to
   improve them, where would I get the understanding of what is good and
  what
   needs help?
  
   -r
  
   On Thu, Jun 30, 2011 at 3:29 PM, Digy digyd...@gmail.com wrote:
  
I can not say I like this approach, but till we find an automated
   way(with
good results), it seems to be the only way we can use.
   
DIGY
   
-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com]
Sent: Friday, July 01, 2011 12:43 AM
To: lucene-net-...@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
  needed?
   
Scott -
   
The idea of the automated port is still worth doing. Perhaps it
 makes
   sense
for someone more passionate about the line-by-line idea to do that
  work?
   
I would say, focus on what makes sense to you. Being productive,
   regardless
of the specific direction, is what will be most valuable. Once you
   start,
others will join and momentum will build. That is how these things
  work.
   
I like DIGY's approach too, but the problem with it is that it is a
never-ending manual task. The theory behind the automated port is
 that
   it
may reduce the manual work. It is complicated

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Moray McConnachie]

I don't think I'm as hard core on this as Neal, but remember: the
history of the Lucene.NET project is that all the intellectual work, all
the understanding of search, all the new features come from the Lucene
Java folks. Theirs is an immensely respected project, and I trust them
to add new features that will be well-tested and well-researched, and to
have a decent roadmap which I can trust they will execute on. 

Now I know there's been an influx of capable developers to Lucene.NET
who are ready, willing and (I'm going to assume) able to add a lot more
value in a generic .NET implementation as they change it. But it'll take
a while before I trust a .NET dedicated framework which is significantly
diverged from Java in the way I do the line-by-line version. And at what
stage is it not just not a line-by-line port, but not a port at all?

At the same time, I recognise that if this project is going to continue,
and attract good developers, it has to change in this direction.

So that said, I can see why a line-by-line port might not be
sustainable. And most people don't need it. But most of us using Lucene
in production systems do need a system that we can trust and rely on. So
let me chime in with someone else's plea, to keep the general structure
close to Lucene, to keep the same general objects and inheritance
set-up, and to keep the same method names, even if you add other methods
and classes to provide additional functionality. ABSOLUTELY the same
file formats. End users benefit a lot from a high degree of similarity,
with good documentation and help being available from the Java
community.

Yours,
Moray
-
Moray McConnachie
Director of IT+44 1865 261 600
Oxford Analytica  http://www.oxan.com

-Original Message-
From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com] 
Sent: 29 June 2011 20:47
To: lucene-net-u...@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-Original Message-
From: Scott Lombard [mailto:lombardena...@gmail.com]
Sent: Wednesday, June 29, 2011 1:58 PM
To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net
2.0 to Net 4.0 I am trying to figure out what is the need for a
line-by-line port.  Starting with Digy's excellent work on the
conversion to generics a priority of the 2.9.4g release is the 2
packages would not be interchangeable.  So faster turnaround from a java
release won't matter to non line-by-line users they will have to wait
until the updates are made to the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?
Anyone have a comment?

 

Scott

 

  

 

-
Disclaimer 

This message and any attachments are confidential and/or privileged. If this 
has been sent to you in error, please do not use, retain or disclose them, and 
contact the sender as soon as possible.

Oxford Analytica Ltd
Registered in England: No. 1196703
5 Alfred Street, Oxford
United Kingdom, OX1 4EH
-

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Noel Lysaght]

Can I just plug in my bit and say I agree 100% with what Moray has outlined 
below.


If we move away from the line by line port then over time we'll loose out on 
the momentum that is Lucene and the improvements that they make.
It is only if the Lucene.NET community has expertise in search,  a  deep 
knowledge of the project and the community can guarantee that the knowledge 
will survive members coming and going should such a consideration be give.


When Lucene.NET has stood on it's feet for a number of years after it has 
moved out of Apache incubation should consideration be given to abandoning a 
line by line port.
By all means extend and wrap the libraries in .NET equivalents and .NET 
goodness like LINQ (we do this internally in our company at the moment); but 
leave the core of the project on a line by line port.


Just my tu-pence worth.

Kind Regards
Noel


-Original Message- 
From: Moray McConnachie

Sent: Thursday, June 30, 2011 10:25 AM
To: lucene-net-u...@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

I don't think I'm as hard core on this as Neal, but remember: the
history of the Lucene.NET project is that all the intellectual work, all
the understanding of search, all the new features come from the Lucene
Java folks. Theirs is an immensely respected project, and I trust them
to add new features that will be well-tested and well-researched, and to
have a decent roadmap which I can trust they will execute on.

Now I know there's been an influx of capable developers to Lucene.NET
who are ready, willing and (I'm going to assume) able to add a lot more
value in a generic .NET implementation as they change it. But it'll take
a while before I trust a .NET dedicated framework which is significantly
diverged from Java in the way I do the line-by-line version. And at what
stage is it not just not a line-by-line port, but not a port at all?

At the same time, I recognise that if this project is going to continue,
and attract good developers, it has to change in this direction.

So that said, I can see why a line-by-line port might not be
sustainable. And most people don't need it. But most of us using Lucene
in production systems do need a system that we can trust and rely on. So
let me chime in with someone else's plea, to keep the general structure
close to Lucene, to keep the same general objects and inheritance
set-up, and to keep the same method names, even if you add other methods
and classes to provide additional functionality. ABSOLUTELY the same
file formats. End users benefit a lot from a high degree of similarity,
with good documentation and help being available from the Java
community.

Yours,
Moray
-
Moray McConnachie
Director of IT+44 1865 261 600
Oxford Analytica  http://www.oxan.com

-Original Message-
From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com]
Sent: 29 June 2011 20:47
To: lucene-net-u...@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-Original Message-
From: Scott Lombard [mailto:lombardena...@gmail.com]
Sent: Wednesday, June 29, 2011 1:58 PM
To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?



After the large community response about moving the code base from .Net
2.0 to Net 4.0 I am trying to figure out what is the need for a
line-by-line port.  Starting with Digy's excellent work on the
conversion to generics a priority of the 2.9.4g release is the 2
packages would not be interchangeable.  So faster turnaround from a java
release won't matter to non line-by-line users they will have to wait
until the updates are made to the non line-by-line code base.



My question is there really a user base for the line-by-line port?
Anyone have a comment?



Scott







-
Disclaimer

This message and any attachments are confidential and/or privileged. If this 
has been sent to you in error, please do not use, retain or disclose them, 
and contact the sender as soon as possible.


Oxford Analytica Ltd
Registered in England: No. 1196703
5 Alfred Street, Oxford
United Kingdom, OX1 4EH
-

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Ayende Rahien]

As someone from the nhibernate project
We stopped following hibernate a while ago, and haven't regretted it
We have mire features, less bugs and better code base

Sent from my Windows Phone From: Rory Plaire
Sent: Thursday, June 30, 2011 19:58
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
I don't want to drag this out much longer, but I am curious with people who
hold the line-by-line sentiment - are you NHibernate users?

-r

On Thu, Jun 30, 2011 at 2:39 AM, Noel Lysaght lysag...@hotmail.com wrote:

 Can I just plug in my bit and say I agree 100% with what Moray has outlined
 below.

 If we move away from the line by line port then over time we'll loose out
 on the momentum that is Lucene and the improvements that they make.
 It is only if the Lucene.NET community has expertise in search,  a  deep
 knowledge of the project and the community can guarantee that the knowledge
 will survive members coming and going should such a consideration be give.

 When Lucene.NET has stood on it's feet for a number of years after it has
 moved out of Apache incubation should consideration be given to abandoning a
 line by line port.
 By all means extend and wrap the libraries in .NET equivalents and .NET
 goodness like LINQ (we do this internally in our company at the moment); but
 leave the core of the project on a line by line port.

 Just my tu-pence worth.

 Kind Regards
 Noel


 -Original Message- From: Moray McConnachie
 Sent: Thursday, June 30, 2011 10:25 AM

 To: lucene-net-user@lucene.apache.**orglucene-net-u...@lucene.apache.org
 Cc: lucene-net-dev@incubator.**apache.orglucene-net-...@incubator.apache.org
 Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 I don't think I'm as hard core on this as Neal, but remember: the
 history of the Lucene.NET project is that all the intellectual work, all
 the understanding of search, all the new features come from the Lucene
 Java folks. Theirs is an immensely respected project, and I trust them
 to add new features that will be well-tested and well-researched, and to
 have a decent roadmap which I can trust they will execute on.

 Now I know there's been an influx of capable developers to Lucene.NET
 who are ready, willing and (I'm going to assume) able to add a lot more
 value in a generic .NET implementation as they change it. But it'll take
 a while before I trust a .NET dedicated framework which is significantly
 diverged from Java in the way I do the line-by-line version. And at what
 stage is it not just not a line-by-line port, but not a port at all?

 At the same time, I recognise that if this project is going to continue,
 and attract good developers, it has to change in this direction.

 So that said, I can see why a line-by-line port might not be
 sustainable. And most people don't need it. But most of us using Lucene
 in production systems do need a system that we can trust and rely on. So
 let me chime in with someone else's plea, to keep the general structure
 close to Lucene, to keep the same general objects and inheritance
 set-up, and to keep the same method names, even if you add other methods
 and classes to provide additional functionality. ABSOLUTELY the same
 file formats. End users benefit a lot from a high degree of similarity,
 with good documentation and help being available from the Java
 community.

 Yours,
 Moray
 --**---
 Moray McConnachie
 Director of IT+44 1865 261 600
 Oxford Analytica  http://www.oxan.com

 -Original Message-
 From: Granroth, Neal V. 
 [mailto:neal.granroth@**thermofisher.comneal.granr...@thermofisher.com
 ]
 Sent: 29 June 2011 20:47
 To: lucene-net-user@lucene.apache.**orglucene-net-u...@lucene.apache.org
 Cc: lucene-net-dev@incubator.**apache.orglucene-net-...@incubator.apache.org
 Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 This is has been discussed many times.
 Lucene.NET is not valid, the code cannot be trusted, if it is not a
 line-by-line port.  It ceases to be Lucene.

 - Neal

 -Original Message-
 From: Scott Lombard [mailto:lombardenator@gmail.**comlombardena...@gmail.com
 ]
 Sent: Wednesday, June 29, 2011 1:58 PM
 To: lucene-net-dev@lucene.apache.**org lucene-net-dev@lucene.apache.org;
 lucene-net-user@lucene.apache.**org lucene-net-u...@lucene.apache.org
 Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?



 After the large community response about moving the code base from .Net
 2.0 to Net 4.0 I am trying to figure out what is the need for a
 line-by-line port.  Starting with Digy's excellent work on the
 conversion to generics a priority of the 2.9.4g release is the 2
 packages would not be interchangeable.  So faster turnaround from a java
 release won't matter to non line-by-line users they will have to wait
 until the updates are made to the non line-by-line code base.



 My question is there really a user

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Itamar Syn-Hershko]

NHibernate has a much bigger community and more active devs afaict.


The proposed changes as I understand them are not about changing class 
structure or APIs, but merely touch hunks of code and rewrite them to 
use better .NET practices (yield, generics, LINQ etc). In conjunction 
with a move to .NET 4.0 this would increase readability, improve GC and 
boost performance.



IMO this doesn't have to be a line-by-line port in order to make porting 
of patches easy - what digy seem to be really worried about (and he's 
right). As long as the meaning of the code is clear, it shouldn't be a 
real problem to apply Java patches to the .NET codebase. And as long as 
the test suite keeps being thorough, there's really nothing to fear of.



On 30/06/2011 20:15, Ayende Rahien wrote:


As someone from the nhibernate project
We stopped following hibernate a while ago, and haven't regretted it
We have mire features, less bugs and better code base

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

Michael,
You interpret the report as whoever commits code wins? But when I look at it, 
I see a lof of talk, no work. .Net community is not interested in 
contributing.
I really don't understand what hinders people to work on Lucene.Net. As I did 
for 2.9.4g, grab the code, do whatever you want on it and submit back. If it 
doesn't fit to the project's direction it can still find a place in contrib or 
in branch. All of the approaches can live side by side happily in the 
Lucene.Net repository. 

Troy,
I also don't understand why do you wait for 2.9.4g? It is a *branch* and has 
nothing to do with the trunk. It need not be an offical release and can live in 
branch as a PoC. 


As a result, I got bored to listen to this should be done that way. What I 
want to see is I did it that way, should we continue with this.

DIGY




-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com] 
Sent: Thursday, June 30, 2011 10:47 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Michael,

I agree with everything you said. My point in saying whoever commits code
wins was to illustrate the reality of how and why the project has the
current form.

Building consensus is difficult. It is an essential first step before we can
do something like make a list of bit-sized pieces of work that others can
work on.

This is why my real message of Let's find a way to accommodate both is so
important. It allows us to build consensus, so that we can settle on a
direction and structure our work.

Until we accomplish that, it really is whoever commits code wins, and that
is an unhealthy and unmaintainable way to operate.

From a technical perspective, your statements about the unit tests are
completely accurate. They really need a LOT of reworking. That's the very
first step before making any significant changes. Part of the problem is
that the tests themselves are not well written. The other part is that the
Lucene object model was not designed for testability, and it makes writing
good tests more difficult, and certain tests might not be possible. It will
be difficult to write good unit tests without re-structuring. The biggest
issue is the use of abstract classes with base behaviour vs interfaces or
fully abstracted classes. Makes mocking tough. This is the direction I was
going when I started the Lucere project. I'd like to start in on that work
after the 2.9.4g release.

Thanks,
Troy


On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon 
mhern...@wickedsoftware.net wrote:

 I'd say that is all the more reasons that we need to work smarter and not
 harder. I'd also say thats a good reason to make sure we build consensus
 rather than just saying whoever commits code wins.

 And its a damn good reason to focus on the effort of growing the number of
 contributors and lowing the barrier to submitting patches, breaking things
 down into pieces that people would feel confident to work on without
 being overwhelmed by the complexity of Lucene.Net.

 There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
 internals and index formats are significantly different including nixing
 the
 current vint file format and using byte[] array slices for Terms instead of
 char[].

 So while porting 1 to 1 while require less knowledge or thought, its most
 likely going to require more hours of work. And Its definitely not going to
 guarantee the stability of the code or that its great code.

 I'd have to say that its not as stable as most would believe at the moment.

 Most of the tests avoid anything that remotely looks like it knows about
 the
 DRY principle and there is a static constructor in the core test case that
 throws an exception if it doesn't find an environment variable TEMP which
 will fail 90% of the tests and nunit will be unable to give you a clear
 reason why.  Just to name a few issues I came across working towards
 getting
 Lucene.Net into CI.  I haven't even started really digging in under the
 covers of the code yet.

 So my suggestion is to chew on this a bit more and build consensus, avoid
 fracturing people into sides.  Be open to reservations and concerns that
 others have and continue to address them.

 - Michael


 On Thu, Jun 30, 2011 at 2:10 PM, Digy digyd...@gmail.com wrote:

  Although there are a lot of people using Lucene.Net, this is our
  contribution report for the past 5 years.
 
 
 
 https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q
 
 
 AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|linversionId=-1issue
 
 
 Status=allselectedProjectId=12310290reportKey=com.sourcelabs.jira.plugin.r
  eport.contributions%3AcontributionreportNext=Next
 
 
  DIGY
 
  -Original Message-
  From: Ayende Rahien [mailto:aye...@ayende.com]
  Sent: Thursday, June 30, 2011 8:16 PM
  To: Rory Plaire; lucene-net-dev@lucene.apache.org
  Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

 A) I don't to want to commit anything  thats going to piss alot of people
off, 
 B) I don't want to spend time/waste time on modifications that are going
to be rejected.  

What I've learnt from Apache Way is creating a JIRA issue if you are
hesitant.
If no one answers in a reasonable time(mostly), then commit.

DIGY

-Original Message-
From: Michael Herndon [mailto:mhern...@wickedsoftware.net] 
Sent: Thursday, June 30, 2011 11:58 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

@Troy,

I've already started working towards fixing unit testing issues, and
prototyping some things that sure DRY up the testing just so that I can get
the tests running on mono.

Those changes are currently in a private git repo, however since we don't
have a CI, I'm need to make some time to manually test those on at least 3
different Os (windowx, osx, and ubuntu) before putting those back into the
2.9.4g branch.

The reason being I need those in working order so that I can do a write up
on pulling those from source and at least running the build script to
compile everything and run the tests for you.  I don't know about everyone
else, but thats a starting point I look for when I go to work on something
or commit something back.

They should make their way back sometime this month.  I think the next thing
I'll do is put my money where my mouth is, spend time break down the rest of
the CI tasks, then seeing how much stuff I can get documented into the wiki.
 The simple faceted search is a decent starting template.

@Digy I agree with the talk, no work.

Though coming from the outside in, I still cringe when I make any commits at
the moment. (even that little .gitnore file)  A) I don't to want to commit
anything  thats going to piss alot of people off, B) I don't want to spend
time/waste time on modifications that are going to be rejected.  C) it took
a good deal of going through things before I felt comfortable to even making
a commit.   D) yes I know I just need to get over it and so does everyone
else (hence the obsession with the unit tests at the moment).

and I think a key to relaying people to get over it, including myself, is to
make the point you had more clear across the board:

*If it doesn't fit to the project's direction it can still find a place in
contrib or in branch. All of the approaches can live side by side happily in
the Lucene.Net repository. * +1  because that makes feel there is more
leadway to experiment and any decent effort will at least go somewhere to
live and not be wasted.

On Thu, Jun 30, 2011 at 4:19 PM, Digy digyd...@gmail.com wrote:

 Michael,
 You interpret the report as whoever commits code wins? But when I look
at
 it, I see a lof of talk, no work. .Net community is not interested in
 contributing.
 I really don't understand what hinders people to work on Lucene.Net. As I
 did for 2.9.4g, grab the code, do whatever you want on it and submit back.
 If it doesn't fit to the project's direction it can still find a place in
 contrib or in branch. All of the approaches can live side by side happily
in
 the Lucene.Net repository.

 Troy,
 I also don't understand why do you wait for 2.9.4g? It is a *branch* and
 has nothing to do with the trunk. It need not be an offical release and
can
 live in branch as a PoC.


 As a result, I got bored to listen to this should be done that way. What
 I want to see is I did it that way, should we continue with this.

 DIGY




 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Thursday, June 30, 2011 10:47 PM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 Michael,

 I agree with everything you said. My point in saying whoever commits code
 wins was to illustrate the reality of how and why the project has the
 current form.

 Building consensus is difficult. It is an essential first step before we
 can
 do something like make a list of bit-sized pieces of work that others can
 work on.

 This is why my real message of Let's find a way to accommodate both is
so
 important. It allows us to build consensus, so that we can settle on a
 direction and structure our work.

 Until we accomplish that, it really is whoever commits code wins, and
 that
 is an unhealthy and unmaintainable way to operate.

 From a technical perspective, your statements about the unit tests are
 completely accurate. They really need a LOT of reworking. That's the very
 first step before making any significant changes. Part of the problem is
 that the tests themselves are not well written. The other part is that the
 Lucene object model was not designed for testability, and it makes writing
 good tests more difficult, and certain tests might not be possible. It
will
 be difficult to write good unit tests without re-structuring. The biggest
 issue is the use of abstract classes with base behaviour vs interfaces or
 fully

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Troy Howard]

DIGY - Re: Why do I wait.. That's mostly because I intend to make some deep
changes, which would make merging the 2.9.4g branch back to trunk difficult.
So, it's easier to merge those changes first. Also, I won't have enough time
to make my changes until a little way in the future, but probably do have
the time to put together another release, so I'll do that first because it
fits with my work/life schedule.

Thanks,
Troy


On Thu, Jun 30, 2011 at 1:19 PM, Digy digyd...@gmail.com wrote:

 Michael,
 You interpret the report as whoever commits code wins? But when I look at
 it, I see a lof of talk, no work. .Net community is not interested in
 contributing.
 I really don't understand what hinders people to work on Lucene.Net. As I
 did for 2.9.4g, grab the code, do whatever you want on it and submit back.
 If it doesn't fit to the project's direction it can still find a place in
 contrib or in branch. All of the approaches can live side by side happily in
 the Lucene.Net repository.

 Troy,
 I also don't understand why do you wait for 2.9.4g? It is a *branch* and
 has nothing to do with the trunk. It need not be an offical release and can
 live in branch as a PoC.


 As a result, I got bored to listen to this should be done that way. What
 I want to see is I did it that way, should we continue with this.

 DIGY




 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Thursday, June 30, 2011 10:47 PM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 Michael,

 I agree with everything you said. My point in saying whoever commits code
 wins was to illustrate the reality of how and why the project has the
 current form.

 Building consensus is difficult. It is an essential first step before we
 can
 do something like make a list of bit-sized pieces of work that others can
 work on.

 This is why my real message of Let's find a way to accommodate both is so
 important. It allows us to build consensus, so that we can settle on a
 direction and structure our work.

 Until we accomplish that, it really is whoever commits code wins, and
 that
 is an unhealthy and unmaintainable way to operate.

 From a technical perspective, your statements about the unit tests are
 completely accurate. They really need a LOT of reworking. That's the very
 first step before making any significant changes. Part of the problem is
 that the tests themselves are not well written. The other part is that the
 Lucene object model was not designed for testability, and it makes writing
 good tests more difficult, and certain tests might not be possible. It will
 be difficult to write good unit tests without re-structuring. The biggest
 issue is the use of abstract classes with base behaviour vs interfaces or
 fully abstracted classes. Makes mocking tough. This is the direction I was
 going when I started the Lucere project. I'd like to start in on that work
 after the 2.9.4g release.

 Thanks,
 Troy


 On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon 
 mhern...@wickedsoftware.net wrote:

  I'd say that is all the more reasons that we need to work smarter and not
  harder. I'd also say thats a good reason to make sure we build consensus
  rather than just saying whoever commits code wins.
 
  And its a damn good reason to focus on the effort of growing the number
 of
  contributors and lowing the barrier to submitting patches, breaking
 things
  down into pieces that people would feel confident to work on without
  being overwhelmed by the complexity of Lucene.Net.
 
  There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
  internals and index formats are significantly different including nixing
  the
  current vint file format and using byte[] array slices for Terms instead
 of
  char[].
 
  So while porting 1 to 1 while require less knowledge or thought, its most
  likely going to require more hours of work. And Its definitely not going
 to
  guarantee the stability of the code or that its great code.
 
  I'd have to say that its not as stable as most would believe at the
 moment.
 
  Most of the tests avoid anything that remotely looks like it knows about
  the
  DRY principle and there is a static constructor in the core test case
 that
  throws an exception if it doesn't find an environment variable TEMP
 which
  will fail 90% of the tests and nunit will be unable to give you a clear
  reason why.  Just to name a few issues I came across working towards
  getting
  Lucene.Net into CI.  I haven't even started really digging in under the
  covers of the code yet.
 
  So my suggestion is to chew on this a bit more and build consensus, avoid
  fracturing people into sides.  Be open to reservations and concerns that
  others have and continue to address them.
 
  - Michael
 
 
  On Thu, Jun 30, 2011 at 2:10 PM, Digy digyd...@gmail.com wrote:
 
   Although there are a lot of people using Lucene.Net, this is our
   contribution report

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Troy Howard]

Scott -

The idea of the automated port is still worth doing. Perhaps it makes sense
for someone more passionate about the line-by-line idea to do that work?

I would say, focus on what makes sense to you. Being productive, regardless
of the specific direction, is what will be most valuable. Once you start,
others will join and momentum will build. That is how these things work.

I like DIGY's approach too, but the problem with it is that it is a
never-ending manual task. The theory behind the automated port is that it
may reduce the manual work. It is complicated, but once it's built and
works, it will save a lot of future development hours. If it's built in a
sufficiently general manner, it could be useful for other project like
Lucene.Net that want to automate a port from Java to C#.

It might make sense for that to be a separate project from Lucene.Net
though.

-T


On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard lombardena...@gmail.comwrote:

 Ok I think I asked the wrong question.  I am trying to figure out where to
 put my time.  I was thinking about working on the automated porting system,
 but when I saw the response to the .NET 4.0 discussions I started to
 question if that is the right direction.  The community seemed to be more
 interested in the .NET features.

 The complexity of the automated tool is going to become very high and will
 probably end up with a line-for-line style port.  So I keep asking my self
 is the automated tool worth it.  I don't think it is.

 I like the method has been Digy is using for porting the code.  So I guess
 for me the real question is Digy where did you see 2.9.4g going next and
 what do you need help on?

 Scott




  -Original Message-
  From: Digy [mailto:digyd...@gmail.com]
  Sent: Thursday, June 30, 2011 4:20 PM
  To: lucene-net-dev@lucene.apache.org
  Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  Michael,
  You interpret the report as whoever commits code wins? But when I look
  at it, I see a lof of talk, no work. .Net community is not interested
 in
  contributing.
  I really don't understand what hinders people to work on Lucene.Net. As I
  did for 2.9.4g, grab the code, do whatever you want on it and submit
 back.
  If it doesn't fit to the project's direction it can still find a place in
  contrib or in branch. All of the approaches can live side by side happily
  in the Lucene.Net repository.
 
  Troy,
  I also don't understand why do you wait for 2.9.4g? It is a *branch* and
  has nothing to do with the trunk. It need not be an offical release and
  can live in branch as a PoC.
 
 
  As a result, I got bored to listen to this should be done that way.
 What
  I want to see is I did it that way, should we continue with this.
 
  DIGY
 
 
 
 
  -Original Message-
  From: Troy Howard [mailto:thowar...@gmail.com]
  Sent: Thursday, June 30, 2011 10:47 PM
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  Michael,
 
  I agree with everything you said. My point in saying whoever commits
 code
  wins was to illustrate the reality of how and why the project has the
  current form.
 
  Building consensus is difficult. It is an essential first step before we
  can
  do something like make a list of bit-sized pieces of work that others can
  work on.
 
  This is why my real message of Let's find a way to accommodate both is
  so
  important. It allows us to build consensus, so that we can settle on a
  direction and structure our work.
 
  Until we accomplish that, it really is whoever commits code wins, and
  that
  is an unhealthy and unmaintainable way to operate.
 
  From a technical perspective, your statements about the unit tests are
  completely accurate. They really need a LOT of reworking. That's the very
  first step before making any significant changes. Part of the problem is
  that the tests themselves are not well written. The other part is that
 the
  Lucene object model was not designed for testability, and it makes
 writing
  good tests more difficult, and certain tests might not be possible. It
  will
  be difficult to write good unit tests without re-structuring. The biggest
  issue is the use of abstract classes with base behaviour vs interfaces or
  fully abstracted classes. Makes mocking tough. This is the direction I
 was
  going when I started the Lucere project. I'd like to start in on that
 work
  after the 2.9.4g release.
 
  Thanks,
  Troy
 
 
  On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon 
  mhern...@wickedsoftware.net wrote:
 
   I'd say that is all the more reasons that we need to work smarter and
  not
   harder. I'd also say thats a good reason to make sure we build
 consensus
   rather than just saying whoever commits code wins.
  
   And its a damn good reason to focus on the effort of growing the number
  of
   contributors and lowing the barrier to submitting patches, breaking
  things
   down into pieces

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Troy Howard]

Michael -

If you bring those changes from git into a branch in SVN, we can help with
it. It doesn't have to be complete to be committed. :)

Regarding A (angering people)/B (being rejected)/C (feeling comfortable)/D
(getting over it)...

a) Making progress is more important than keeping everyone happy
b) Our goal is to accept things, not reject them. That said, if something
gets rejected due to quality issues, don't be afraid of that, it's a
learning experience for everyone, and it's a good thing. We can work
together to get to something everyone is happy with and learn in the
process.
c) Commit to a branch. Merge when things are right. No one expects branches
to build or be finished. It's OK. I get worried when I merge to trunk or
when I make a release. But I don't do that until I'm pretty sure it's all
legit.
d) Best way to get over it is to start doing it

I know you probably already realize all of this, but I wanted to respond, so
that, in case anyone else out there is struggling with the same set of
fears, they can see that fears that prevent action are more problematic than
any action they might take without those fears.

Thanks,
Troy


On Thu, Jun 30, 2011 at 1:57 PM, Michael Herndon 
mhern...@wickedsoftware.net wrote:

 @Troy,

 I've already started working towards fixing unit testing issues, and
 prototyping some things that sure DRY up the testing just so that I can get
 the tests running on mono.

 Those changes are currently in a private git repo, however since we don't
 have a CI, I'm need to make some time to manually test those on at least 3
 different Os (windowx, osx, and ubuntu) before putting those back into the
 2.9.4g branch.

 The reason being I need those in working order so that I can do a write up
 on pulling those from source and at least running the build script to
 compile everything and run the tests for you.  I don't know about everyone
 else, but thats a starting point I look for when I go to work on something
 or commit something back.

 They should make their way back sometime this month.  I think the next
 thing
 I'll do is put my money where my mouth is, spend time break down the rest
 of
 the CI tasks, then seeing how much stuff I can get documented into the
 wiki.
  The simple faceted search is a decent starting template.

 @Digy I agree with the talk, no work.

 Though coming from the outside in, I still cringe when I make any commits
 at
 the moment. (even that little .gitnore file)  A) I don't to want to commit
 anything  thats going to piss alot of people off, B) I don't want to spend
 time/waste time on modifications that are going to be rejected.  C) it took
 a good deal of going through things before I felt comfortable to even
 making
 a commit.   D) yes I know I just need to get over it and so does everyone
 else (hence the obsession with the unit tests at the moment).

 and I think a key to relaying people to get over it, including myself, is
 to
 make the point you had more clear across the board:

 *If it doesn't fit to the project's direction it can still find a place in
 contrib or in branch. All of the approaches can live side by side happily
 in
 the Lucene.Net repository. * +1  because that makes feel there is more
 leadway to experiment and any decent effort will at least go somewhere to
 live and not be wasted.

 On Thu, Jun 30, 2011 at 4:19 PM, Digy digyd...@gmail.com wrote:

  Michael,
  You interpret the report as whoever commits code wins? But when I look
 at
  it, I see a lof of talk, no work. .Net community is not interested in
  contributing.
  I really don't understand what hinders people to work on Lucene.Net. As I
  did for 2.9.4g, grab the code, do whatever you want on it and submit
 back.
  If it doesn't fit to the project's direction it can still find a place in
  contrib or in branch. All of the approaches can live side by side happily
 in
  the Lucene.Net repository.
 
  Troy,
  I also don't understand why do you wait for 2.9.4g? It is a *branch* and
  has nothing to do with the trunk. It need not be an offical release and
 can
  live in branch as a PoC.
 
 
  As a result, I got bored to listen to this should be done that way.
 What
  I want to see is I did it that way, should we continue with this.
 
  DIGY
 
 
 
 
  -Original Message-
  From: Troy Howard [mailto:thowar...@gmail.com]
  Sent: Thursday, June 30, 2011 10:47 PM
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  Michael,
 
  I agree with everything you said. My point in saying whoever commits
 code
  wins was to illustrate the reality of how and why the project has the
  current form.
 
  Building consensus is difficult. It is an essential first step before we
  can
  do something like make a list of bit-sized pieces of work that others can
  work on.
 
  This is why my real message of Let's find a way to accommodate both is
 so
  important. It allows us to build consensus, so that we can settle

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

I can not say I like this approach, but till we find an automated way(with good 
results), it seems to be the only way we can use.

DIGY

-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com] 
Sent: Friday, July 01, 2011 12:43 AM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Scott -

The idea of the automated port is still worth doing. Perhaps it makes sense
for someone more passionate about the line-by-line idea to do that work?

I would say, focus on what makes sense to you. Being productive, regardless
of the specific direction, is what will be most valuable. Once you start,
others will join and momentum will build. That is how these things work.

I like DIGY's approach too, but the problem with it is that it is a
never-ending manual task. The theory behind the automated port is that it
may reduce the manual work. It is complicated, but once it's built and
works, it will save a lot of future development hours. If it's built in a
sufficiently general manner, it could be useful for other project like
Lucene.Net that want to automate a port from Java to C#.

It might make sense for that to be a separate project from Lucene.Net
though.

-T


On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard lombardena...@gmail.comwrote:

 Ok I think I asked the wrong question.  I am trying to figure out where to
 put my time.  I was thinking about working on the automated porting system,
 but when I saw the response to the .NET 4.0 discussions I started to
 question if that is the right direction.  The community seemed to be more
 interested in the .NET features.

 The complexity of the automated tool is going to become very high and will
 probably end up with a line-for-line style port.  So I keep asking my self
 is the automated tool worth it.  I don't think it is.

 I like the method has been Digy is using for porting the code.  So I guess
 for me the real question is Digy where did you see 2.9.4g going next and
 what do you need help on?

 Scott




  -Original Message-
  From: Digy [mailto:digyd...@gmail.com]
  Sent: Thursday, June 30, 2011 4:20 PM
  To: lucene-net-dev@lucene.apache.org
  Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  Michael,
  You interpret the report as whoever commits code wins? But when I look
  at it, I see a lof of talk, no work. .Net community is not interested
 in
  contributing.
  I really don't understand what hinders people to work on Lucene.Net. As I
  did for 2.9.4g, grab the code, do whatever you want on it and submit
 back.
  If it doesn't fit to the project's direction it can still find a place in
  contrib or in branch. All of the approaches can live side by side happily
  in the Lucene.Net repository.
 
  Troy,
  I also don't understand why do you wait for 2.9.4g? It is a *branch* and
  has nothing to do with the trunk. It need not be an offical release and
  can live in branch as a PoC.
 
 
  As a result, I got bored to listen to this should be done that way.
 What
  I want to see is I did it that way, should we continue with this.
 
  DIGY
 
 
 
 
  -Original Message-
  From: Troy Howard [mailto:thowar...@gmail.com]
  Sent: Thursday, June 30, 2011 10:47 PM
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  Michael,
 
  I agree with everything you said. My point in saying whoever commits
 code
  wins was to illustrate the reality of how and why the project has the
  current form.
 
  Building consensus is difficult. It is an essential first step before we
  can
  do something like make a list of bit-sized pieces of work that others can
  work on.
 
  This is why my real message of Let's find a way to accommodate both is
  so
  important. It allows us to build consensus, so that we can settle on a
  direction and structure our work.
 
  Until we accomplish that, it really is whoever commits code wins, and
  that
  is an unhealthy and unmaintainable way to operate.
 
  From a technical perspective, your statements about the unit tests are
  completely accurate. They really need a LOT of reworking. That's the very
  first step before making any significant changes. Part of the problem is
  that the tests themselves are not well written. The other part is that
 the
  Lucene object model was not designed for testability, and it makes
 writing
  good tests more difficult, and certain tests might not be possible. It
  will
  be difficult to write good unit tests without re-structuring. The biggest
  issue is the use of abstract classes with base behaviour vs interfaces or
  fully abstracted classes. Makes mocking tough. This is the direction I
 was
  going when I started the Lucere project. I'd like to start in on that
 work
  after the 2.9.4g release.
 
  Thanks,
  Troy
 
 
  On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon 
  mhern...@wickedsoftware.net wrote:
 
   I'd say that is all the more

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Rory Plaire]

So, veering towards action - are there concrete tasks written up anywhere
for the unit tests? If a poor schlep like me wanted to dig in and start to
improve them, where would I get the understanding of what is good and what
needs help?

-r

On Thu, Jun 30, 2011 at 3:29 PM, Digy digyd...@gmail.com wrote:

 I can not say I like this approach, but till we find an automated way(with
 good results), it seems to be the only way we can use.

 DIGY

 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Friday, July 01, 2011 12:43 AM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 Scott -

 The idea of the automated port is still worth doing. Perhaps it makes sense
 for someone more passionate about the line-by-line idea to do that work?

 I would say, focus on what makes sense to you. Being productive, regardless
 of the specific direction, is what will be most valuable. Once you start,
 others will join and momentum will build. That is how these things work.

 I like DIGY's approach too, but the problem with it is that it is a
 never-ending manual task. The theory behind the automated port is that it
 may reduce the manual work. It is complicated, but once it's built and
 works, it will save a lot of future development hours. If it's built in a
 sufficiently general manner, it could be useful for other project like
 Lucene.Net that want to automate a port from Java to C#.

 It might make sense for that to be a separate project from Lucene.Net
 though.

 -T


 On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard lombardena...@gmail.com
 wrote:

  Ok I think I asked the wrong question.  I am trying to figure out where
 to
  put my time.  I was thinking about working on the automated porting
 system,
  but when I saw the response to the .NET 4.0 discussions I started to
  question if that is the right direction.  The community seemed to be more
  interested in the .NET features.
 
  The complexity of the automated tool is going to become very high and
 will
  probably end up with a line-for-line style port.  So I keep asking my
 self
  is the automated tool worth it.  I don't think it is.
 
  I like the method has been Digy is using for porting the code.  So I
 guess
  for me the real question is Digy where did you see 2.9.4g going next and
  what do you need help on?
 
  Scott
 
 
 
 
   -Original Message-
   From: Digy [mailto:digyd...@gmail.com]
   Sent: Thursday, June 30, 2011 4:20 PM
   To: lucene-net-dev@lucene.apache.org
   Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
 needed?
  
   Michael,
   You interpret the report as whoever commits code wins? But when I
 look
   at it, I see a lof of talk, no work. .Net community is not interested
  in
   contributing.
   I really don't understand what hinders people to work on Lucene.Net. As
 I
   did for 2.9.4g, grab the code, do whatever you want on it and submit
  back.
   If it doesn't fit to the project's direction it can still find a place
 in
   contrib or in branch. All of the approaches can live side by side
 happily
   in the Lucene.Net repository.
  
   Troy,
   I also don't understand why do you wait for 2.9.4g? It is a *branch*
 and
   has nothing to do with the trunk. It need not be an offical release and
   can live in branch as a PoC.
  
  
   As a result, I got bored to listen to this should be done that way.
  What
   I want to see is I did it that way, should we continue with this.
  
   DIGY
  
  
  
  
   -Original Message-
   From: Troy Howard [mailto:thowar...@gmail.com]
   Sent: Thursday, June 30, 2011 10:47 PM
   To: lucene-net-dev@lucene.apache.org
   Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
 needed?
  
   Michael,
  
   I agree with everything you said. My point in saying whoever commits
  code
   wins was to illustrate the reality of how and why the project has the
   current form.
  
   Building consensus is difficult. It is an essential first step before
 we
   can
   do something like make a list of bit-sized pieces of work that others
 can
   work on.
  
   This is why my real message of Let's find a way to accommodate both
 is
   so
   important. It allows us to build consensus, so that we can settle on a
   direction and structure our work.
  
   Until we accomplish that, it really is whoever commits code wins, and
   that
   is an unhealthy and unmaintainable way to operate.
  
   From a technical perspective, your statements about the unit tests are
   completely accurate. They really need a LOT of reworking. That's the
 very
   first step before making any significant changes. Part of the problem
 is
   that the tests themselves are not well written. The other part is that
  the
   Lucene object model was not designed for testability, and it makes
  writing
   good tests more difficult, and certain tests might not be possible. It
   will
   be difficult to write good unit tests without

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

Although there are a lot of people using Lucene.Net, this is our
contribution report for the past 5 years.

https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q
AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|linversionId=-1issue
Status=allselectedProjectId=12310290reportKey=com.sourcelabs.jira.plugin.r
eport.contributions%3AcontributionreportNext=Next


DIGY

-Original Message-
From: Ayende Rahien [mailto:aye...@ayende.com] 
Sent: Thursday, June 30, 2011 8:16 PM
To: Rory Plaire; lucene-net-...@lucene.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

As someone from the nhibernate project
We stopped following hibernate a while ago, and haven't regretted it
We have mire features, less bugs and better code base

Sent from my Windows Phone From: Rory Plaire
Sent: Thursday, June 30, 2011 19:58
To: lucene-net-...@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
I don't want to drag this out much longer, but I am curious with people who
hold the line-by-line sentiment - are you NHibernate users?

-r

On Thu, Jun 30, 2011 at 2:39 AM, Noel Lysaght lysag...@hotmail.com wrote:

 Can I just plug in my bit and say I agree 100% with what Moray has
outlined
 below.

 If we move away from the line by line port then over time we'll loose out
 on the momentum that is Lucene and the improvements that they make.
 It is only if the Lucene.NET community has expertise in search,  a  deep
 knowledge of the project and the community can guarantee that the
knowledge
 will survive members coming and going should such a consideration be give.

 When Lucene.NET has stood on it's feet for a number of years after it has
 moved out of Apache incubation should consideration be given to abandoning
a
 line by line port.
 By all means extend and wrap the libraries in .NET equivalents and .NET
 goodness like LINQ (we do this internally in our company at the moment);
but
 leave the core of the project on a line by line port.

 Just my tu-pence worth.

 Kind Regards
 Noel


 -Original Message- From: Moray McConnachie
 Sent: Thursday, June 30, 2011 10:25 AM

 To: lucene-net-user@lucene.apache.**orglucene-net-u...@lucene.apache.org
 Cc:
lucene-net-dev@incubator.**apache.orglucene-net-...@incubator.apache.org
 Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 I don't think I'm as hard core on this as Neal, but remember: the
 history of the Lucene.NET project is that all the intellectual work, all
 the understanding of search, all the new features come from the Lucene
 Java folks. Theirs is an immensely respected project, and I trust them
 to add new features that will be well-tested and well-researched, and to
 have a decent roadmap which I can trust they will execute on.

 Now I know there's been an influx of capable developers to Lucene.NET
 who are ready, willing and (I'm going to assume) able to add a lot more
 value in a generic .NET implementation as they change it. But it'll take
 a while before I trust a .NET dedicated framework which is significantly
 diverged from Java in the way I do the line-by-line version. And at what
 stage is it not just not a line-by-line port, but not a port at all?

 At the same time, I recognise that if this project is going to continue,
 and attract good developers, it has to change in this direction.

 So that said, I can see why a line-by-line port might not be
 sustainable. And most people don't need it. But most of us using Lucene
 in production systems do need a system that we can trust and rely on. So
 let me chime in with someone else's plea, to keep the general structure
 close to Lucene, to keep the same general objects and inheritance
 set-up, and to keep the same method names, even if you add other methods
 and classes to provide additional functionality. ABSOLUTELY the same
 file formats. End users benefit a lot from a high degree of similarity,
 with good documentation and help being available from the Java
 community.

 Yours,
 Moray
 --**---
 Moray McConnachie
 Director of IT+44 1865 261 600
 Oxford Analytica  http://www.oxan.com

 -Original Message-
 From: Granroth, Neal V.
[mailto:neal.granroth@**thermofisher.comneal.granr...@thermofisher.com
 ]
 Sent: 29 June 2011 20:47
 To: lucene-net-user@lucene.apache.**orglucene-net-u...@lucene.apache.org
 Cc:
lucene-net-dev@incubator.**apache.orglucene-net-...@incubator.apache.org
 Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 This is has been discussed many times.
 Lucene.NET is not valid, the code cannot be trusted, if it is not a
 line-by-line port.  It ceases to be Lucene.

 - Neal

 -Original Message-
 From: Scott Lombard
[mailto:lombardenator@gmail.**comlombardena...@gmail.com
 ]
 Sent: Wednesday, June 29, 2011 1:58 PM
 To: lucene-net-dev@lucene.apache.**org lucene-net-...@lucene.apache.org;
 lucene-net-user@lucene.apache

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Michael Herndon]

I'd say that is all the more reasons that we need to work smarter and not
harder. I'd also say thats a good reason to make sure we build consensus
rather than just saying whoever commits code wins.

And its a damn good reason to focus on the effort of growing the number of
contributors and lowing the barrier to submitting patches, breaking things
down into pieces that people would feel confident to work on without
being overwhelmed by the complexity of Lucene.Net.

There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
internals and index formats are significantly different including nixing the
current vint file format and using byte[] array slices for Terms instead of
char[].

So while porting 1 to 1 while require less knowledge or thought, its most
likely going to require more hours of work. And Its definitely not going to
guarantee the stability of the code or that its great code.

I'd have to say that its not as stable as most would believe at the moment.

Most of the tests avoid anything that remotely looks like it knows about the
DRY principle and there is a static constructor in the core test case that
throws an exception if it doesn't find an environment variable TEMP which
will fail 90% of the tests and nunit will be unable to give you a clear
reason why.  Just to name a few issues I came across working towards getting
Lucene.Net into CI.  I haven't even started really digging in under the
covers of the code yet.

So my suggestion is to chew on this a bit more and build consensus, avoid
fracturing people into sides.  Be open to reservations and concerns that
others have and continue to address them.

- Michael


On Thu, Jun 30, 2011 at 2:10 PM, Digy digyd...@gmail.com wrote:

 Although there are a lot of people using Lucene.Net, this is our
 contribution report for the past 5 years.


 https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q

 AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|linversionId=-1issue

 Status=allselectedProjectId=12310290reportKey=com.sourcelabs.jira.plugin.r
 eport.contributions%3AcontributionreportNext=Next


 DIGY

 -Original Message-
 From: Ayende Rahien [mailto:aye...@ayende.com]
 Sent: Thursday, June 30, 2011 8:16 PM
 To: Rory Plaire; lucene-net-...@lucene.apache.org
 Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 As someone from the nhibernate project
 We stopped following hibernate a while ago, and haven't regretted it
 We have mire features, less bugs and better code base

 Sent from my Windows Phone From: Rory Plaire
 Sent: Thursday, June 30, 2011 19:58
 To: lucene-net-...@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 I don't want to drag this out much longer, but I am curious with people who
 hold the line-by-line sentiment - are you NHibernate users?

 -r

 On Thu, Jun 30, 2011 at 2:39 AM, Noel Lysaght lysag...@hotmail.com
 wrote:

  Can I just plug in my bit and say I agree 100% with what Moray has
 outlined
  below.
 
  If we move away from the line by line port then over time we'll loose out
  on the momentum that is Lucene and the improvements that they make.
  It is only if the Lucene.NET community has expertise in search,  a  deep
  knowledge of the project and the community can guarantee that the
 knowledge
  will survive members coming and going should such a consideration be
 give.
 
  When Lucene.NET has stood on it's feet for a number of years after it has
  moved out of Apache incubation should consideration be given to
 abandoning
 a
  line by line port.
  By all means extend and wrap the libraries in .NET equivalents and .NET
  goodness like LINQ (we do this internally in our company at the moment);
 but
  leave the core of the project on a line by line port.
 
  Just my tu-pence worth.
 
  Kind Regards
  Noel
 
 
  -Original Message- From: Moray McConnachie
  Sent: Thursday, June 30, 2011 10:25 AM
 
  To: lucene-net-user@lucene.apache.**org
 lucene-net-u...@lucene.apache.org
  Cc:
 lucene-net-dev@incubator.**apache.orglucene-net-...@incubator.apache.org
  Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  I don't think I'm as hard core on this as Neal, but remember: the
  history of the Lucene.NET project is that all the intellectual work, all
  the understanding of search, all the new features come from the Lucene
  Java folks. Theirs is an immensely respected project, and I trust them
  to add new features that will be well-tested and well-researched, and to
  have a decent roadmap which I can trust they will execute on.
 
  Now I know there's been an influx of capable developers to Lucene.NET
  who are ready, willing and (I'm going to assume) able to add a lot more
  value in a generic .NET implementation as they change it. But it'll take
  a while before I trust a .NET dedicated framework which is significantly
  diverged from Java in the way I do the line-by-line version. And at what

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Troy Howard]

Michael,

I agree with everything you said. My point in saying whoever commits code
wins was to illustrate the reality of how and why the project has the
current form.

Building consensus is difficult. It is an essential first step before we can
do something like make a list of bit-sized pieces of work that others can
work on.

This is why my real message of Let's find a way to accommodate both is so
important. It allows us to build consensus, so that we can settle on a
direction and structure our work.

Until we accomplish that, it really is whoever commits code wins, and that
is an unhealthy and unmaintainable way to operate.

From a technical perspective, your statements about the unit tests are
completely accurate. They really need a LOT of reworking. That's the very
first step before making any significant changes. Part of the problem is
that the tests themselves are not well written. The other part is that the
Lucene object model was not designed for testability, and it makes writing
good tests more difficult, and certain tests might not be possible. It will
be difficult to write good unit tests without re-structuring. The biggest
issue is the use of abstract classes with base behaviour vs interfaces or
fully abstracted classes. Makes mocking tough. This is the direction I was
going when I started the Lucere project. I'd like to start in on that work
after the 2.9.4g release.

Thanks,
Troy


On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon 
mhern...@wickedsoftware.net wrote:

 I'd say that is all the more reasons that we need to work smarter and not
 harder. I'd also say thats a good reason to make sure we build consensus
 rather than just saying whoever commits code wins.

 And its a damn good reason to focus on the effort of growing the number of
 contributors and lowing the barrier to submitting patches, breaking things
 down into pieces that people would feel confident to work on without
 being overwhelmed by the complexity of Lucene.Net.

 There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
 internals and index formats are significantly different including nixing
 the
 current vint file format and using byte[] array slices for Terms instead of
 char[].

 So while porting 1 to 1 while require less knowledge or thought, its most
 likely going to require more hours of work. And Its definitely not going to
 guarantee the stability of the code or that its great code.

 I'd have to say that its not as stable as most would believe at the moment.

 Most of the tests avoid anything that remotely looks like it knows about
 the
 DRY principle and there is a static constructor in the core test case that
 throws an exception if it doesn't find an environment variable TEMP which
 will fail 90% of the tests and nunit will be unable to give you a clear
 reason why.  Just to name a few issues I came across working towards
 getting
 Lucene.Net into CI.  I haven't even started really digging in under the
 covers of the code yet.

 So my suggestion is to chew on this a bit more and build consensus, avoid
 fracturing people into sides.  Be open to reservations and concerns that
 others have and continue to address them.

 - Michael


 On Thu, Jun 30, 2011 at 2:10 PM, Digy digyd...@gmail.com wrote:

  Although there are a lot of people using Lucene.Net, this is our
  contribution report for the past 5 years.
 
 
 
 https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q
 
 
 AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|linversionId=-1issue
 
 
 Status=allselectedProjectId=12310290reportKey=com.sourcelabs.jira.plugin.r
  eport.contributions%3AcontributionreportNext=Next
 
 
  DIGY
 
  -Original Message-
  From: Ayende Rahien [mailto:aye...@ayende.com]
  Sent: Thursday, June 30, 2011 8:16 PM
  To: Rory Plaire; lucene-net-...@lucene.apache.org
  Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  As someone from the nhibernate project
  We stopped following hibernate a while ago, and haven't regretted it
  We have mire features, less bugs and better code base
 
  Sent from my Windows Phone From: Rory Plaire
  Sent: Thursday, June 30, 2011 19:58
  To: lucene-net-...@lucene.apache.org
  Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
  I don't want to drag this out much longer, but I am curious with people
 who
  hold the line-by-line sentiment - are you NHibernate users?
 
  -r
 
  On Thu, Jun 30, 2011 at 2:39 AM, Noel Lysaght lysag...@hotmail.com
  wrote:
 
   Can I just plug in my bit and say I agree 100% with what Moray has
  outlined
   below.
  
   If we move away from the line by line port then over time we'll loose
 out
   on the momentum that is Lucene and the improvements that they make.
   It is only if the Lucene.NET community has expertise in search,  a
  deep
   knowledge of the project and the community can guarantee that the
  knowledge
   will survive members coming and going should

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Scott Lombard]

Ok I think I asked the wrong question.  I am trying to figure out where to
put my time.  I was thinking about working on the automated porting system,
but when I saw the response to the .NET 4.0 discussions I started to
question if that is the right direction.  The community seemed to be more
interested in the .NET features.  

The complexity of the automated tool is going to become very high and will
probably end up with a line-for-line style port.  So I keep asking my self
is the automated tool worth it.  I don't think it is.  

I like the method has been Digy is using for porting the code.  So I guess
for me the real question is Digy where did you see 2.9.4g going next and
what do you need help on?  

Scott




 -Original Message-
 From: Digy [mailto:digyd...@gmail.com]
 Sent: Thursday, June 30, 2011 4:20 PM
 To: lucene-net-...@lucene.apache.org
 Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
 Michael,
 You interpret the report as whoever commits code wins? But when I look
 at it, I see a lof of talk, no work. .Net community is not interested in
 contributing.
 I really don't understand what hinders people to work on Lucene.Net. As I
 did for 2.9.4g, grab the code, do whatever you want on it and submit back.
 If it doesn't fit to the project's direction it can still find a place in
 contrib or in branch. All of the approaches can live side by side happily
 in the Lucene.Net repository.
 
 Troy,
 I also don't understand why do you wait for 2.9.4g? It is a *branch* and
 has nothing to do with the trunk. It need not be an offical release and
 can live in branch as a PoC.
 
 
 As a result, I got bored to listen to this should be done that way. What
 I want to see is I did it that way, should we continue with this.
 
 DIGY
 
 
 
 
 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Thursday, June 30, 2011 10:47 PM
 To: lucene-net-...@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
 Michael,
 
 I agree with everything you said. My point in saying whoever commits code
 wins was to illustrate the reality of how and why the project has the
 current form.
 
 Building consensus is difficult. It is an essential first step before we
 can
 do something like make a list of bit-sized pieces of work that others can
 work on.
 
 This is why my real message of Let's find a way to accommodate both is
 so
 important. It allows us to build consensus, so that we can settle on a
 direction and structure our work.
 
 Until we accomplish that, it really is whoever commits code wins, and
 that
 is an unhealthy and unmaintainable way to operate.
 
 From a technical perspective, your statements about the unit tests are
 completely accurate. They really need a LOT of reworking. That's the very
 first step before making any significant changes. Part of the problem is
 that the tests themselves are not well written. The other part is that the
 Lucene object model was not designed for testability, and it makes writing
 good tests more difficult, and certain tests might not be possible. It
 will
 be difficult to write good unit tests without re-structuring. The biggest
 issue is the use of abstract classes with base behaviour vs interfaces or
 fully abstracted classes. Makes mocking tough. This is the direction I was
 going when I started the Lucere project. I'd like to start in on that work
 after the 2.9.4g release.
 
 Thanks,
 Troy
 
 
 On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon 
 mhern...@wickedsoftware.net wrote:
 
  I'd say that is all the more reasons that we need to work smarter and
 not
  harder. I'd also say thats a good reason to make sure we build consensus
  rather than just saying whoever commits code wins.
 
  And its a damn good reason to focus on the effort of growing the number
 of
  contributors and lowing the barrier to submitting patches, breaking
 things
  down into pieces that people would feel confident to work on without
  being overwhelmed by the complexity of Lucene.Net.
 
  There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
  internals and index formats are significantly different including nixing
  the
  current vint file format and using byte[] array slices for Terms instead
 of
  char[].
 
  So while porting 1 to 1 while require less knowledge or thought, its
 most
  likely going to require more hours of work. And Its definitely not going
 to
  guarantee the stability of the code or that its great code.
 
  I'd have to say that its not as stable as most would believe at the
 moment.
 
  Most of the tests avoid anything that remotely looks like it knows about
  the
  DRY principle and there is a static constructor in the core test case
 that
  throws an exception if it doesn't find an environment variable TEMP
 which
  will fail 90% of the tests and nunit will be unable to give you a clear
  reason why.  Just to name a few issues I came across working towards
  getting

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Rory Plaire]

For what it's worth, I've participated in a number of projects which have
been ported from Java to .Net with varying levels of translation into
the native style and functionalty of the .Net framework. The largest are
NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is that
a line-by-line port isn't as valuable as people would imagine.

Even if we discount the reality that a line-by-line port is really
unachievable due to various differences between the frameworks, keeping even
identical code in sync will always take some work: full automation on this
large of a project is infeasible. During manual effort, therefore, making
readable changes to the code is really not that much more work.

For update maintenance, porting over code from recent versions of both
projects to the .Net versions, and .Nettifying that code is little
trouble. Since both projects use source control, it's easy to see the
changes and translate them.

When it comes to debugging issues, in NTS or NHibernate, I go to the Java
sources, and even if the classes were largely rewritten to take advantage of
IEnumerable or generics or structures, running unit tests, tracing the code,
and seeing the output of each has always been straightforward.

Since I'm using .Net, I'd want the Lucene.Net project to be more .Net than a
line-by-line port of Java, in order to take advantage of the Framework as
well as provide a better code base for .Net developers to maintain. If large
.Net projects ported from Java do this, and have found considerable success,
it is, in my view, a well-proven practice and shouldn't be avoided due to
uncertainty of how the resulting code should work. Ultimately, that is what
unit tests are for, anyway.

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

Hi Rory,
I agree with you in theory. But collecting people to work on a project is
not easy as giving advise.
Till now, line-by-line port have seemed to be the best with a limited human
source. 

Would you be willing to work on your approach and maintain newer Lucene.Net
releases?

DIGY



-Original Message-
From: Rory Plaire [mailto:codekai...@gmail.com] 
Sent: Thursday, June 30, 2011 1:06 AM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

For what it's worth, I've participated in a number of projects which have
been ported from Java to .Net with varying levels of translation into
the native style and functionalty of the .Net framework. The largest are
NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is that
a line-by-line port isn't as valuable as people would imagine.

Even if we discount the reality that a line-by-line port is really
unachievable due to various differences between the frameworks, keeping even
identical code in sync will always take some work: full automation on this
large of a project is infeasible. During manual effort, therefore, making
readable changes to the code is really not that much more work.

For update maintenance, porting over code from recent versions of both
projects to the .Net versions, and .Nettifying that code is little
trouble. Since both projects use source control, it's easy to see the
changes and translate them.

When it comes to debugging issues, in NTS or NHibernate, I go to the Java
sources, and even if the classes were largely rewritten to take advantage of
IEnumerable or generics or structures, running unit tests, tracing the code,
and seeing the output of each has always been straightforward.

Since I'm using .Net, I'd want the Lucene.Net project to be more .Net than a
line-by-line port of Java, in order to take advantage of the Framework as
well as provide a better code base for .Net developers to maintain. If large
.Net projects ported from Java do this, and have found considerable success,
it is, in my view, a well-proven practice and shouldn't be avoided due to
uncertainty of how the resulting code should work. Ultimately, that is what
unit tests are for, anyway.

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Granroth, Neal V.]

Others have done a much better , more through job of explaining the issues in 
previous discussions.  It would be best to re-read those.

One way to understand it, is if Lucene.NET cannot be compared to the reference 
source code (Lucene core java Lucene) than it becomes nearly impossible to 
validate that Lucene.NET is functioning correctly, that bug fixes made in 
Lucene core have been implemented in Lucene.NET, etc.  The same goes for unit 
tests, if they cannot be compared with the ones from Lucene core line-by-line 
than there is no way to know that they perform the intended tests and run 
correctly.


- Neal
 

-Original Message-
From: Wyatt Barnett [mailto:wyatt.barn...@gmail.com] 
Sent: Wednesday, June 29, 2011 2:57 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Those are pretty strong words -- I'd really like to know why I
shouldn't trust anything but a line-by-line port. Can you explain a
bit?

On Wed, Jun 29, 2011 at 3:47 PM, Granroth, Neal V.
neal.granr...@thermofisher.com wrote:
 This is has been discussed many times.
 Lucene.NET is not valid, the code cannot be trusted, if it is not a 
 line-by-line port.  It ceases to be Lucene.

 - Neal

 -Original Message-
 From: Scott Lombard [mailto:lombardena...@gmail.com]
 Sent: Wednesday, June 29, 2011 1:58 PM
 To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
 Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?



 After the large community response about moving the code base from .Net 2.0
 to Net 4.0 I am trying to figure out what is the need for a line-by-line
 port.  Starting with Digy's excellent work on the conversion to generics a
 priority of the 2.9.4g release is the 2 packages would not be
 interchangeable.  So faster turnaround from a java release won't matter to
 non line-by-line users they will have to wait until the updates are made to
 the non line-by-line code base.



 My question is there really a user base for the line-by-line port?  Anyone
 have a comment?



 Scott

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Rory Plaire]

Of course I'd love to contribute. I'm hopeful I can spend even a few hours a
week doing this when (if...) my people adopt NHibernate.Search.

Troy, I'm going to defer to your sense that there is enough interest and
support from the community to maintain both code bases. It is hard, however,
to restrain my skepticism, which I relate in order to record a sort of
warning to consider. In a perfect world two code-bases could live
side-by-side and even benefit each other. In practice, however, I'm doubtful
that this can be symbiotic relationship. If people contribute more to one
than another, it creates an unhealthy uncertainty about the state of the
project. It also splits any potential future project resources who may be
ambivalent about translation vs. transliteration. Open source projects are
often fragile, and it's hard for me to keep from worrying if there would
need to be a sacrifice at some point to keep the project concentrated enough
to remain viable. While the model of open source is such that *anyone* can
contribute, this very mechanism can also lead to projects that are pulled
back and forth among contributor needs and interests, adding complexity and
instability which ultimately doom them.

-r
On Wed, Jun 29, 2011 at 3:47 PM, Troy Howard thowar...@gmail.com wrote:

 I pretty much agree with Rory.

 And as others have said, this issue has been discussed many times. What is
 most important about the fact that it has been discussed many times is that
 it has not been resolve, even though it has been discussed so many times.

 That means that the both the developer community that contributes to the
 project and the user community that uses the library have an interest in
 *both*. I think we have enough interest and support from the community to
 develop both of these at the same time.

 Some key points:
 - Being a useful index/search library is the goal of any implementation of
 Lucene. Being useful is more important than being identical to one another.
 Don't forget that Java Lucene has bugs, design problems, and may not always
 be the best implementation of Lucene.
 - Unit tests should validate the code's correctness in terms of
 functionality/bugs
 - The library can contain multiple APIs for the same tasks. Fluent? LINQ?
 Just Like Java? Just like pylucene? All of the above?
 - Implementation details between .NET and Java are *very* significant and
 often account for a lot of the bugs that are Lucene.Net only. Our attempt
 to
 be a line-by-line port is what is introducing bugs, not the the other way
 around
 - The only reason we are having this discussion is because C# and Java are
 very similar languages. If this was a F# port or a VB.NET port, we
 wouldn't
 even be discussing this. Instead we'd say make it work the way that makes
 the most sense in {{insert language here}}.


 That said, DIGY has a very good point. Continued development on the library
 is the most important part of the project's goals. A dead project helps no
 one. If the current active contributors are writing a line-by-line port,
 then that's what it will be. If they are writing a complete re-write, then
 that is what it will be. Some might find it easier to write line-by-line,
 but others might find that task daunting. The opposite is also true. It
 depends on the person, how much time they have, and what they consider
 easy or manageable or worth doing.

 As always, if you want the code base to be something specific, submit a
 patch for that, and it will be. If not, then you need to convince someone
 else to write that patch. And just so it's clear, *anyone* can write and
 submit a patch and be a contributor, not just the project committers.

 Thanks,
 Troy

 On Wed, Jun 29, 2011 at 3:06 PM, Rory Plaire codekai...@gmail.com wrote:

  For what it's worth, I've participated in a number of projects which have
  been ported from Java to .Net with varying levels of translation into
  the native style and functionalty of the .Net framework. The largest are
  NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is
  that
  a line-by-line port isn't as valuable as people would imagine.
 
  Even if we discount the reality that a line-by-line port is really
  unachievable due to various differences between the frameworks, keeping
  even
  identical code in sync will always take some work: full automation on
 this
  large of a project is infeasible. During manual effort, therefore, making
  readable changes to the code is really not that much more work.
 
  For update maintenance, porting over code from recent versions of both
  projects to the .Net versions, and .Nettifying that code is little
  trouble. Since both projects use source control, it's easy to see the
  changes and translate them.
 
  When it comes to debugging issues, in NTS or NHibernate, I go to the Java
  sources, and even if the classes were largely rewritten to take advantage
  of
  IEnumerable or generics or structures, running unit tests, tracing 

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Granroth, Neal V.]

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a 
line-by-line port.  It ceases to be Lucene.

- Neal

-Original Message-
From: Scott Lombard [mailto:lombardena...@gmail.com] 
Sent: Wednesday, June 29, 2011 1:58 PM
To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

 

  

 

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Wyatt Barnett]

Those are pretty strong words -- I'd really like to know why I
shouldn't trust anything but a line-by-line port. Can you explain a
bit?

On Wed, Jun 29, 2011 at 3:47 PM, Granroth, Neal V.
neal.granr...@thermofisher.com wrote:
 This is has been discussed many times.
 Lucene.NET is not valid, the code cannot be trusted, if it is not a 
 line-by-line port.  It ceases to be Lucene.

 - Neal

 -Original Message-
 From: Scott Lombard [mailto:lombardena...@gmail.com]
 Sent: Wednesday, June 29, 2011 1:58 PM
 To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org
 Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?



 After the large community response about moving the code base from .Net 2.0
 to Net 4.0 I am trying to figure out what is the need for a line-by-line
 port.  Starting with Digy's excellent work on the conversion to generics a
 priority of the 2.9.4g release is the 2 packages would not be
 interchangeable.  So faster turnaround from a java release won't matter to
 non line-by-line users they will have to wait until the updates are made to
 the non line-by-line code base.



 My question is there really a user base for the line-by-line port?  Anyone
 have a comment?



 Scott

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

As a Lucene.Net user I wouldn't care whether it is line-by-line port or not.

But as a contributer, I would prefer a parallel code that makes the life
easier for manual ports of new releases(until this process is automated)

PS: I presume no one thinks of functional or index-level incompatibility.

DIGY

-Original Message-
From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com] 
Sent: Wednesday, June 29, 2011 10:47 PM
To: lucene-net-u...@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-Original Message-
From: Scott Lombard [mailto:lombardena...@gmail.com] 
Sent: Wednesday, June 29, 2011 1:58 PM
To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

 

  

 

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Michael Herndon]

For the sake of continued conversation, Scott could you define what you mean
by line-by-line port vs non-line-by-line port since technically your the
thread starter?







On Wed, Jun 29, 2011 at 3:58 PM, Digy digyd...@gmail.com wrote:

 As a Lucene.Net user I wouldn't care whether it is line-by-line port or
 not.

 But as a contributer, I would prefer a parallel code that makes the life
 easier for manual ports of new releases(until this process is automated)

 PS: I presume no one thinks of functional or index-level incompatibility.

 DIGY

 -Original Message-
 From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com]
 Sent: Wednesday, June 29, 2011 10:47 PM
 To: lucene-net-u...@lucene.apache.org
 Cc: lucene-net-...@incubator.apache.org
 Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 This is has been discussed many times.
 Lucene.NET is not valid, the code cannot be trusted, if it is not a
 line-by-line port.  It ceases to be Lucene.

 - Neal

 -Original Message-
 From: Scott Lombard [mailto:lombardena...@gmail.com]
 Sent: Wednesday, June 29, 2011 1:58 PM
 To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org
 Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?



 After the large community response about moving the code base from .Net 2.0
 to Net 4.0 I am trying to figure out what is the need for a line-by-line
 port.  Starting with Digy's excellent work on the conversion to generics a
 priority of the 2.9.4g release is the 2 packages would not be
 interchangeable.  So faster turnaround from a java release won't matter to
 non line-by-line users they will have to wait until the updates are made to
 the non line-by-line code base.



 My question is there really a user base for the line-by-line port?  Anyone
 have a comment?



 Scott

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Scott Lombard]

When I look at the goals of Lucene.Net I am trying to understand what is
more important to Lucene.Net users, .NET functionality or a line-for-line
port.

.NET and Java are close but not the same.  In the past when give the choice
between a better .NET way or stay with the Java implementation the project
chose to keep the Java implementation.  If users don't care that it is a
line-for-line port then contributors will have more freedom to use a better
.NET way, while keeping functionality and index compatibility.  

As contributors we can figure out how to get from the Java to Lucene.Net.
This will probably be an automated tool, but the source that the tool
outputs wouldn't need to be highly polished or even compile.  The primary
purpose would be to simplify the process of get from Java to .NET for a
release.


Scott


 -Original Message-
 From: Michael Herndon [mailto:mhern...@wickedsoftware.net]
 Sent: Wednesday, June 29, 2011 4:17 PM
 To: lucene-net-...@lucene.apache.org
 Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
 For the sake of continued conversation, Scott could you define what you
 mean
 by line-by-line port vs non-line-by-line port since technically your the
 thread starter?
 
 
 
 
 
 
 
 On Wed, Jun 29, 2011 at 3:58 PM, Digy digyd...@gmail.com wrote:
 
  As a Lucene.Net user I wouldn't care whether it is line-by-line port or
  not.
 
  But as a contributer, I would prefer a parallel code that makes the life
  easier for manual ports of new releases(until this process is automated)
 
  PS: I presume no one thinks of functional or index-level
 incompatibility.
 
  DIGY
 
  -Original Message-
  From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com]
  Sent: Wednesday, June 29, 2011 10:47 PM
  To: lucene-net-u...@lucene.apache.org
  Cc: lucene-net-...@incubator.apache.org
  Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
  This is has been discussed many times.
  Lucene.NET is not valid, the code cannot be trusted, if it is not a
  line-by-line port.  It ceases to be Lucene.
 
  - Neal
 
  -Original Message-
  From: Scott Lombard [mailto:lombardena...@gmail.com]
  Sent: Wednesday, June 29, 2011 1:58 PM
  To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org
  Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
 
 
 
  After the large community response about moving the code base from .Net
 2.0
  to Net 4.0 I am trying to figure out what is the need for a line-by-line
  port.  Starting with Digy's excellent work on the conversion to generics
 a
  priority of the 2.9.4g release is the 2 packages would not be
  interchangeable.  So faster turnaround from a java release won't matter
 to
  non line-by-line users they will have to wait until the updates are made
 to
  the non line-by-line code base.
 
 
 
  My question is there really a user base for the line-by-line port?
 Anyone
  have a comment?
 
 
 
  Scott
 
 
 
 
 
 
 
 

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

Hi Scott,
Please avoid crossposting(as I do now). Since when I reply to your eMail, it
goes to one of the lists and thread is splitted into two.
It may be good for announcements but not for discussions.

DIGY

-Original Message-
From: Scott Lombard [mailto:lombardena...@gmail.com] 
Sent: Wednesday, June 29, 2011 9:58 PM
To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

 

  

 

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Granroth, Neal V.]

I do not know if too much emphasis should be placed on user vs. 
contributor.  The project needs to also consider those of us who use 
Lucene.NET source releases only.
It is much easier to locally patch/fix the source when I can compare it 
directly to Lucene core.

- Neal
 

-Original Message-
From: Digy [mailto:digyd...@gmail.com] 
Sent: Wednesday, June 29, 2011 2:58 PM
To: lucene-net-...@lucene.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

As a Lucene.Net user I wouldn't care whether it is line-by-line port or not.

But as a contributer, I would prefer a parallel code that makes the life
easier for manual ports of new releases(until this process is automated)

PS: I presume no one thinks of functional or index-level incompatibility.

DIGY

-Original Message-
From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com] 
Sent: Wednesday, June 29, 2011 10:47 PM
To: lucene-net-u...@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-Original Message-
From: Scott Lombard [mailto:lombardena...@gmail.com] 
Sent: Wednesday, June 29, 2011 1:58 PM
To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

 

  

 

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Granroth, Neal V.]

Others have done a much better , more through job of explaining the issues in 
previous discussions.  It would be best to re-read those.

One way to understand it, is if Lucene.NET cannot be compared to the reference 
source code (Lucene core java Lucene) than it becomes nearly impossible to 
validate that Lucene.NET is functioning correctly, that bug fixes made in 
Lucene core have been implemented in Lucene.NET, etc.  The same goes for unit 
tests, if they cannot be compared with the ones from Lucene core line-by-line 
than there is no way to know that they perform the intended tests and run 
correctly.


- Neal
 

-Original Message-
From: Wyatt Barnett [mailto:wyatt.barn...@gmail.com] 
Sent: Wednesday, June 29, 2011 2:57 PM
To: lucene-net-...@lucene.apache.org
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Those are pretty strong words -- I'd really like to know why I
shouldn't trust anything but a line-by-line port. Can you explain a
bit?

On Wed, Jun 29, 2011 at 3:47 PM, Granroth, Neal V.
neal.granr...@thermofisher.com wrote:
 This is has been discussed many times.
 Lucene.NET is not valid, the code cannot be trusted, if it is not a 
 line-by-line port.  It ceases to be Lucene.

 - Neal

 -Original Message-
 From: Scott Lombard [mailto:lombardena...@gmail.com]
 Sent: Wednesday, June 29, 2011 1:58 PM
 To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org
 Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?



 After the large community response about moving the code base from .Net 2.0
 to Net 4.0 I am trying to figure out what is the need for a line-by-line
 port.  Starting with Digy's excellent work on the conversion to generics a
 priority of the 2.9.4g release is the 2 packages would not be
 interchangeable.  So faster turnaround from a java release won't matter to
 non line-by-line users they will have to wait until the updates are made to
 the non line-by-line code base.



 My question is there really a user base for the line-by-line port?  Anyone
 have a comment?



 Scott

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Granroth, Neal V.]

I do not know if too much emphasis should be placed on user vs. 
contributor.  The project needs to also consider those of us who use 
Lucene.NET source releases only.
It is much easier to locally patch/fix the source when I can compare it 
directly to Lucene core.

- Neal
 

-Original Message-
From: Digy [mailto:digyd...@gmail.com] 
Sent: Wednesday, June 29, 2011 2:58 PM
To: lucene-net-...@lucene.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

As a Lucene.Net user I wouldn't care whether it is line-by-line port or not.

But as a contributer, I would prefer a parallel code that makes the life
easier for manual ports of new releases(until this process is automated)

PS: I presume no one thinks of functional or index-level incompatibility.

DIGY

-Original Message-
From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com] 
Sent: Wednesday, June 29, 2011 10:47 PM
To: lucene-net-u...@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-Original Message-
From: Scott Lombard [mailto:lombardena...@gmail.com] 
Sent: Wednesday, June 29, 2011 1:58 PM
To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

 

  

 

RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Digy]

 I do not know if too much emphasis should be placed on user vs.
contributor.  
I am sorry for this misunderstanding.
What I tried to say with contributor(not committer) was the people that
works on Lucene.Net source code, not the ones who just consume it.

DIGY

-Original Message-
From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com] 
Sent: Wednesday, June 29, 2011 11:23 PM
To: lucene-net-...@lucene.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

I do not know if too much emphasis should be placed on user vs.
contributor.  The project needs to also consider those of us who use
Lucene.NET source releases only.
It is much easier to locally patch/fix the source when I can compare it
directly to Lucene core.

- Neal
 

-Original Message-
From: Digy [mailto:digyd...@gmail.com] 
Sent: Wednesday, June 29, 2011 2:58 PM
To: lucene-net-...@lucene.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

As a Lucene.Net user I wouldn't care whether it is line-by-line port or not.

But as a contributer, I would prefer a parallel code that makes the life
easier for manual ports of new releases(until this process is automated)

PS: I presume no one thinks of functional or index-level incompatibility.

DIGY

-Original Message-
From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com] 
Sent: Wednesday, June 29, 2011 10:47 PM
To: lucene-net-u...@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-Original Message-
From: Scott Lombard [mailto:lombardena...@gmail.com] 
Sent: Wednesday, June 29, 2011 1:58 PM
To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

 

  

 

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Troy Howard]

I pretty much agree with Rory.

And as others have said, this issue has been discussed many times. What is
most important about the fact that it has been discussed many times is that
it has not been resolve, even though it has been discussed so many times.

That means that the both the developer community that contributes to the
project and the user community that uses the library have an interest in
*both*. I think we have enough interest and support from the community to
develop both of these at the same time.

Some key points:
- Being a useful index/search library is the goal of any implementation of
Lucene. Being useful is more important than being identical to one another.
Don't forget that Java Lucene has bugs, design problems, and may not always
be the best implementation of Lucene.
- Unit tests should validate the code's correctness in terms of
functionality/bugs
- The library can contain multiple APIs for the same tasks. Fluent? LINQ?
Just Like Java? Just like pylucene? All of the above?
- Implementation details between .NET and Java are *very* significant and
often account for a lot of the bugs that are Lucene.Net only. Our attempt to
be a line-by-line port is what is introducing bugs, not the the other way
around
- The only reason we are having this discussion is because C# and Java are
very similar languages. If this was a F# port or a VB.NET port, we wouldn't
even be discussing this. Instead we'd say make it work the way that makes
the most sense in {{insert language here}}.


That said, DIGY has a very good point. Continued development on the library
is the most important part of the project's goals. A dead project helps no
one. If the current active contributors are writing a line-by-line port,
then that's what it will be. If they are writing a complete re-write, then
that is what it will be. Some might find it easier to write line-by-line,
but others might find that task daunting. The opposite is also true. It
depends on the person, how much time they have, and what they consider
easy or manageable or worth doing.

As always, if you want the code base to be something specific, submit a
patch for that, and it will be. If not, then you need to convince someone
else to write that patch. And just so it's clear, *anyone* can write and
submit a patch and be a contributor, not just the project committers.

Thanks,
Troy

On Wed, Jun 29, 2011 at 3:06 PM, Rory Plaire codekai...@gmail.com wrote:

 For what it's worth, I've participated in a number of projects which have
 been ported from Java to .Net with varying levels of translation into
 the native style and functionalty of the .Net framework. The largest are
 NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is
 that
 a line-by-line port isn't as valuable as people would imagine.

 Even if we discount the reality that a line-by-line port is really
 unachievable due to various differences between the frameworks, keeping
 even
 identical code in sync will always take some work: full automation on this
 large of a project is infeasible. During manual effort, therefore, making
 readable changes to the code is really not that much more work.

 For update maintenance, porting over code from recent versions of both
 projects to the .Net versions, and .Nettifying that code is little
 trouble. Since both projects use source control, it's easy to see the
 changes and translate them.

 When it comes to debugging issues, in NTS or NHibernate, I go to the Java
 sources, and even if the classes were largely rewritten to take advantage
 of
 IEnumerable or generics or structures, running unit tests, tracing the
 code,
 and seeing the output of each has always been straightforward.

 Since I'm using .Net, I'd want the Lucene.Net project to be more .Net than
 a
 line-by-line port of Java, in order to take advantage of the Framework as
 well as provide a better code base for .Net developers to maintain. If
 large
 .Net projects ported from Java do this, and have found considerable
 success,
 it is, in my view, a well-proven practice and shouldn't be avoided due to
 uncertainty of how the resulting code should work. Ultimately, that is what
 unit tests are for, anyway.