Just wanted to pipe in here... my company is also going to be utilizing Lucene.net (I'm the Lucene evangelist) and I will definitely be willing to start contributing to the update effort. I agree with the points George made below... It'd be nice to get trunk up to date, and be able to pull patches from the Lucene parent project. I'd also love to see some c# language features utilized at that point, if possible.
Peter Mateja Sent from my iPhone On Nov 6, 2010, at 12:45, Barry Latimer <blat...@gmail.com> wrote: > George, > > Great summary of everything that is going on with Lucene.NET. Once you > produce that actionable list of items I'm more than willing to help out > where I can. > > On Fri, Nov 5, 2010 at 8:39 PM, George Aroush <geo...@aroush.net> wrote: > >> Hi Everyone, >> >> Again, my apology for the long post, but like I did before, I am going to >> reply in one post to answer and clarify questions around this subject -- >> again, my points and clarification below are in no particular order or >> importance. >> >> 1) SVN: Whatever backend source repository is used, as long as the tool is >> doing its job, should not hinder a developer -- SVN is well know, and >> competes against much larger and complex similar product. As long as >> Lucene.Net will be released under ASF, it's required that all ASF codes be >> hosted on ASF's SVN. This is to insure legal issues don't arise. In >> addition (I'm not sure how many know this) if you want to submit fixes, or >> code, and you are not a committer, the only way your work will be accepted >> is if: a) you do so through ASF's JIRA, b) include the ASF license terms >> (if >> it's new code and not a patch). Otherwise, your code will be rejected. >> >> 2) CodePlex.com: Lucene.Net being at ASF has far more benefit because it >> has >> Java Lucene to fall back to. There has been a lot of cross post to Java >> Lucene and Lucene.Net mailing list from various users. In addition, PMC of >> both projects have mutual support. What's more, if we manage to mature >> Lucene.Net, being at ASF means we WILL have influence on Java Lucene (this >> already happened in the past -- we made an API change in Lucene.Net and >> requested it for Java Lucene to sync up with Lucene.Net). Also, if you >> search "lucene.net" on CodePlex.com, you will see over 3 dozen projects >> using it in one form or another -- thus, the exposure is already there, and >> folks do know about Lucene.Net. Finally, if anyone wants to move >> Lucene.Net >> out of ASF, you can do so, but you can't call it Lucene.Net as ASF owns >> that >> name (I signed a release form when I moved dotLucene from SourceForge.net >> to >> ASF back in 2004; Grant can pull it out if need be). I made this move >> because: a) ASF has a brand name, b) dotLucene can benefit from Java Lucene >> under one umbrella. Btw, Java Lucene was originally on SourceForge.net >> before moving to ASF. >> >> 3) ASF + MSFT working together: We, as developers, can champion it, >> however, >> ASF legal will have to get involved and has the final say. I want to point >> this out to emphasize that ASF is more than a project or code repository. >> This is why the brand name is important and why there are standard that ASF >> expects of its projects. If you haven't already, please subscribe to >> general[AT]incubator.apache.org and you will see broader discussions about >> other projects with ASF PMCs. >> >> 4) line-by-line port and what got us here: As I have pointed out before, >> this has a lot of benefits (I don't want to repeat them, you can read my >> earlier post). Yes, a line-by-line is tedious and not sexy, however, this >> isn't why we are here (i.e.: Grant's email). We are here because: a) the >> jump from 2.4.x to 2.9.x port was huge in terms of Java Lucene code changes >> and new code, and b) JLCA is no longer supported by MS to understand new >> Java code (it used to port over 80% of the code and the rest I finished off >> via scripts I wrote or manually). Here is a fact about 2.9.1 release. If >> you look at its release date, you will see that Java Lucene 2.9.1 was >> released on Nov. 6, 2009 and Lucene.Net 2.9.1 was released (via SVN) on >> Feb. >> 17, 2010. Yes, that is 3 months delay, but if you look under the hood, >> Lucene.Net 2.9.1 "beta" was made available on Nov 16 2009 -- this beta >> release, is what's known as the "initial line-by-line port" -- is the bulk >> of the port work. Now, a) I don't think 3 month delay is too long, but yes >> I would like it shortened, and b) subsequent releases, 2.9.x to 3.0.x, >> should be way simpler because the port is a delta of the two versions. So, >> again, we are here because no one bothered to work on the port after >> releasing 2.9.x -- not necessarily the next port will be hard because the >> delta shouldn't be too large. >> >> 5) .NET'fying (again): I want to bring this up again because it's something >> keeps came up as back as 2005 and is up again now. When finished working >> on >> 2.9.x, we sync'ed up Java Lucene and Lucene.Net code base as well as >> release >> dates very well. The plan was to achieve commit-per-commit port moving >> forward -- i.e.: once a SVN commit for Java Lucene takes place, we port >> that >> commit to Lucene.Net within a week. This would have: a) kept Lucene.Net >> code base in sync with Java Lucene and thus eliminating the bulk port that >> I >> have been doing, b) allow us to -- selectively -- change both the internal >> and external code of Lucene.Net to be more .NET'es. Unfortunately, this >> didn't go through as I wasn't able to commit to Lucene.Net (I was absent >> from the project since early this year due to family emergency) and no one >> picked up the project to continue working on it. It seems to me the >> community was happily using 2.9.x and didn't bother to think about "what's >> next" until when Grant's email arrived! (Sorry if this last statement >> sounding harass; it's not what I want to portray, other than emphasize that >> users have to be contributors too for Lucene.Net to be successful). Btw, >> the port isn't just the core Lucene code, it's also all the test code that >> come with Java Lucene. >> >> 6) Wrapping Java Lucene with WCF, using IKVM or adding a .NET'es layer: >> Those are fine ideas, and maybe valuable to have -- you are welcome to >> start >> such a project if you want. There are already such ports out there for >> languages other than C# (check out PyLucene, PLucene, Lucy, etc. they are >> not line-by-line port) The line-by-line port has more values as has been >> highlighted several times. My point here is, there is nothing stopping >> anyone from starting an alternative port, but I believe our energy would be >> misplaced. >> >> 7) Comparing Lucene.Net to project X's Java to .NET port: Some examples >> that >> come up, such as NUnit, NHibernation, and NAnt, are not a fair comparison. >> NUnit is much smaller and is not compatible to JUnit (API, as well as >> parameters, and classes don't match up). I submit to you that if NUnit >> maintained compatibly with JUnit (like Lucene.Net with Java Lucene does), >> the port of the Lucene test code would have been a breeze, but it's not. >> >> 8) Companies backing Lucene.Net: I'm glad to see the list, and I know few >> others (big ones) but can't name them unless if they want to speak up. The >> question is, who will jump in first and provide resources? To any such >> company, it's in your interest to do so. Why? Once someone from your >> company proves that s/he is active and contributes, s/he will be nominated >> to become a committer. That committer is now representing YOUR and thus, >> your vote counts. In effect, you can define the direction of Lucene.Net. >> To start with, at a minimum, if those companies do promote Luene.Net (via >> "powered by") and are willing to have their name listed on Lucene.Net's >> home >> page, that would be a good start. Next, those companies should add some >> blob in their product and on their website that they are using Lucene.Net. >> >> 9) Visual Studio 2005/2010 IDE support (or other build-env.): This the >> least >> of our concern. How often new files get added/renamed/removed/moved that >> require someone to commit changes to the VS build file? Also, only >> committers can check-in changes; I bet you committers don't mind taking >> over >> this small task of maintaining the IDE build file(s) if folks are actively >> working on more relevant task. On my machine, I have VS 98, 2005 and 2010. >> Why? Where I work, we support apps built with all of those versions (and >> did I mention on Linux, Solaris, and AIX -- sorry, no Mac). What we should >> care about is targeting the lowest common, widely acceptable framework, >> such >> as 2.0. If anyone needs Lucene.Net for a more recent framework, you can >> build it off the source. What would be more helpful is if we provide >> binaries releases for Windows CE, Compact Framework, Framework 2.0, 3, et. >> al. for folks who can't / don't want to build off the source. >> >> If you have read this far, thank you! :-) Now, I was suppose to put >> together a list of actionable tasks for the short term need of Lucene.Net. >> I promise that I will do so over the weekend. >> >> Thanks, >> >> -- George >> >>
