RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
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 and
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
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?
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 to
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
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
