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 > >
