Yes the real 2.9.4 is in the trunk. 2.9.4g is currently neither 2.9.4 nor 3.0.3. But having an intermediate tag/release could also be good before removing deprecated methods.
DIGY On Tue, Jul 5, 2011 at 5:19 PM, Scott Lombard <lombardena...@gmail.com>wrote: > 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(List<string> stopWords) > > > > - Query.ExtractTerms(ICollection<string>) > > > > - 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 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|lin&versionId=- > > 1&issue > > > >> > > > > > >> > > > > > >> > > > > >> > > > > > > > > > Status=all&selectedProjectId=12310290&reportKey=com.sourcelabs.jira.plugin > > .r > > > >> > > eport.contributions%3Acontributionreport&Next=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.org< > > > >> > 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.granroth@**thermofisher.com< > > > >> neal.granr...@thermofisher.com> > > > >> > > > ] > > > >> > > > Sent: 29 June 2011 20:47 > > > >> > > > To: lucene-net-user@lucene.apache.**org< > > > >> > > lucene-net-u...@lucene.apache.org> > > > >> > > > Cc: > > > >> > > lucene-net-dev@incubator.**apache.org< > > > >> > 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:lombardenator@gmail.**com<lombardena...@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.**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 > > > >> > > > ------------------------------**--------------------------- > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > > > > > >
