lol, I thought Mentors helped progress the project, not divert its userbase :) j/k, just seeing the irony.
Since it was mentioned as an example of how a project should mature on ASF, I'd rather hear from a committer on Solr on how we can encourage potential committers in Lucene.Net. Its clear that this community is mostly used to downloading work other people do and feeding back to a developer pretty much as you see in sourceforge, or codeproject. Using peer to peer as a metaphor, how do we turn leechers into seeders? I've tried to read mountains of material on the ASF website, but I'll be honest, it reads like the work of project managers; I'm just a simple coder. Where is the plain English guidance that demonstrates how a community can get involved? So far, I'm not seeing much benefit or assistance to the project by complying with the ASF process. Might this project have been as well to stay on sourceforge, or even move to Codeplex.com where a simpler, flexible approach can be more appealing to developers? Doug On Mon, 2007-03-12 at 11:41 -0400, Erik Hatcher wrote: > Sure, Solr is Java... but its a server process just like your > database server or any other service you rely on in which its > implementation language is irrelevant to your needs. Yes, it > requires a JVM, but other than that you can drop it in and use it. > > Erik > > On Mar 12, 2007, at 6:15 AM, Jokin Cuadrado wrote: > > > But solr currently is only for java, and as long as I understand they > > want a solution that can be installed in both .net and java systems. > > Maybe in their case, and as long as they develop in java, running > > their search engine over the ikvm virtual machine would be a better > > solution for maintainability if they want to target clients that have > > a .net architecture > > > > -- > > Jokin > > > > On 3/12/07, Erik Hatcher <[EMAIL PROTECTED]> wrote: > >> James - have you researched whether Solr is a good fit for this > >> particular use case? Solr is quite amazing, and I strongly recommend > >> it for cases of cross-language needs. > >> > >> Erik > >> > >> > >> On Mar 11, 2007, at 9:29 PM, Shaw, James wrote: > >> > >> > I've posted the following comment in the blog but I think it's > >> worth > >> > mentioning our company's use case of Lucene and our appreciation of > >> > API > >> > parity with Java Lucene: > >> > > >> > Hi, all, > >> > Just want to say that having parity with the Java API's does > >> have its > >> > value, at least to our company. Our company is developing a > >> portable > >> > search engine on top of Lucene that will work on both Java and .NET > >> > platforms. It's basically a wrapper around Lucene written in > >> > constrained > >> > Java that will be translated automatically by a Java to C# > >> translator > >> > we've developed. If the Java and .NET versions of the API's > >> differ too > >> > much then we will have to have an abstraction layer on top of the > >> > platform specific Lucene. > >> > > >> > The Java and .NET equivalence is very important to us and is the > >> main > >> > reason we picked Lucene over other search engines for the the > >> > company-wide shared search component that's to be embedded in > >> both our > >> > desktop and web applications, and while I know you can still keep > >> > functional parity with a different .NET API's (same index > >> structure, > >> > same search results given the same query, etc), having the same > >> > API's as > >> > Java definitely makes writing our wrapper component a lot easier. > >> >
