Of course I'd love to contribute. I'm hopeful I can spend even a few hours a
week doing this when (if...) my people adopt NHibernate.Search.
Troy, I'm going to defer to your sense that there is enough interest and
support from the community to maintain both code bases. It is hard, however,
to restrain my skepticism, which I relate in order to record a sort of
warning to consider. In a perfect world two code-bases could live
side-by-side and even benefit each other. In practice, however, I'm doubtful
that this can be symbiotic relationship. If people contribute more to one
than another, it creates an unhealthy uncertainty about the state of the
project. It also splits any potential future project resources who may be
ambivalent about translation vs. transliteration. Open source projects are
often fragile, and it's hard for me to keep from worrying if there would
need to be a sacrifice at some point to keep the project concentrated enough
to remain viable. While the model of open source is such that *anyone* can
contribute, this very mechanism can also lead to projects that are pulled
back and forth among contributor needs and interests, adding complexity and
instability which ultimately doom them.
-r
On Wed, Jun 29, 2011 at 3:47 PM, Troy Howard <thowar...@gmail.com> wrote:
> I pretty much agree with Rory.
>
> And as others have said, this issue has been discussed many times. What is
> most important about the fact that it has been discussed many times is that
> it has not been resolve, even though it has been discussed so many times.
>
> That means that the both the developer community that contributes to the
> project and the user community that uses the library have an interest in
> *both*. I think we have enough interest and support from the community to
> develop both of these at the same time.
>
> Some key points:
> - Being a useful index/search library is the goal of any implementation of
> Lucene. Being useful is more important than being identical to one another.
> Don't forget that Java Lucene has bugs, design problems, and may not always
> be the best implementation of Lucene.
> - Unit tests should validate the code's "correctness" in terms of
> functionality/bugs
> - The library can contain multiple APIs for the same tasks. Fluent? LINQ?
> Just Like Java? Just like pylucene? All of the above?
> - Implementation details between .NET and Java are *very* significant and
> often account for a lot of the bugs that are Lucene.Net only. Our attempt
> to
> be a "line-by-line" port is what is introducing bugs, not the the other way
> around
> - The only reason we are having this discussion is because C# and Java are
> very similar languages. If this was a F# port or a VB.NET port, we
> wouldn't
> even be discussing this. Instead we'd say "make it work the way that makes
> the most sense in {{insert language here}}".
>
>
> That said, DIGY has a very good point. Continued development on the library
> is the most important part of the project's goals. A dead project helps no
> one. If the current active contributors are writing a line-by-line port,
> then that's what it will be. If they are writing a complete re-write, then
> that is what it will be. Some might find it easier to write line-by-line,
> but others might find that task daunting. The opposite is also true. It
> depends on the person, how much time they have, and what they consider
> "easy" or "manageable" or "worth doing".
>
> As always, if you want the code base to be something specific, submit a
> patch for that, and it will be. If not, then you need to convince someone
> else to write that patch. And just so it's clear, *anyone* can write and
> submit a patch and be a contributor, not just the project committers.
>
> Thanks,
> Troy
>
> On Wed, Jun 29, 2011 at 3:06 PM, Rory Plaire <codekai...@gmail.com> wrote:
>
> > For what it's worth, I've participated in a number of projects which have
> > been "ported" from Java to .Net with varying levels of "translation" into
> > the native style and functionalty of the .Net framework. The largest are
> > NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is
> > that
> > a line-by-line port isn't as valuable as people would imagine.
> >
> > Even if we discount the reality that a line-by-line port is really
> > unachievable due to various differences between the frameworks, keeping
> > even
> > identical code in sync will always take some work: full automation on
> this
> > large of a project is infeasible. During manual effort, therefore, making
> > readable changes to the code is really not that much more work.
> >
> > For update maintenance, porting over code from recent versions of both
> > projects to the .Net versions, and ".Nettifying" that code is little
> > trouble. Since both projects use source control, it's easy to see the
> > changes and translate them.
> >
> > When it comes to debugging issues, in NTS or NHibernate, I go to the Java
> > sources, and even if the classes were largely rewritten to take advantage
> > of
> > IEnumerable or generics or structures, running unit tests, tracing the
> > code,
> > and seeing the output of each has always been straightforward.
> >
> > Since I'm using .Net, I'd want the Lucene.Net project to be more .Net
> than
> > a
> > line-by-line port of Java, in order to take advantage of the Framework as
> > well as provide a better code base for .Net developers to maintain. If
> > large
> > .Net projects ported from Java do this, and have found considerable
> > success,
> > it is, in my view, a well-proven practice and shouldn't be avoided due to
> > uncertainty of how the resulting code should work. Ultimately, that is
> what
> > unit tests are for, anyway.
> >
>
