lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Howard <thowar...@gmail.com>
Subject Re: Vote thread started on general@lucene.apache.org
Date Thu, 30 Dec 2010 20:39:24 GMT
It's my opinion that we can basically commoditize an automated port
which will fulfill the needs of the community, and allow the project
to, at minimum, continue to release, in a timely fashion, direct ports
of the Java Lucene releases...

Meanwhile we can continue the efforts represented in Lucere, Lucille,
and Aimee.Net to create an alternative API for Lucene.Net which may or
may not include completely re-written code, depending on the
specifics.

I think both concepts can co-exist in a single project and that this
will be the best way to move forward. If you followed the Lucere
project, you'll see that my approach with TDD and Contract Driven
Design was intended to facilitate just such an arrangement.

Thanks,
Troy


On Thu, Dec 30, 2010 at 12:32 PM, Prescott Nasser <geobmx540@hotmail.com> wrote:
>
> In incubator we can probably rewrite the description of the project - but in the past
we were pushed from doing anything but a straight port becuase the description of the project
was "line by line port" - where a tool makes sense, and .NET specific contructs are basically
avoided becuase that wouldn't be a line by line port. We talked about using things like Enums
but we were shot down from this idea by someone...
>
> I agree with you whole heartly about utilizing sharpen and jvm just to port the code.
The Lucere project was the idea of rewriting the java code to .Net, using standard constructs.
I think the goal for the ASF project was to minimize work needed to be done to upgrade to
new java things that come out. If we purse this direction, then every change needs to be manually
ported. I've already said I think that is do-able once we are on part with the latest java.
>
>
> ~Prescott Nasser
> prescott.nasser@hotmail.com
> 650.208.4205
>
>
>
>
>> Subject: RE: Vote thread started on general@lucene.apache.org
>> Date: Thu, 30 Dec 2010 15:24:32 -0500
>> From: stemarie@brain-bank.com
>> To: lucene-net-dev@lucene.apache.org
>> CC: lucene-net-user@lucene.apache.org
>>
>> I think it took be 5 "deletes" of this e-mail and complete rewrites to try to say
this in the best way possible:
>>
>> First off, Sharpen is a java tool (from the db4o SVN I found) - using sharpen to
port lucene to .net means that people now have to install a jvm on their computers in order
to contribute. While this may seem like it makes perfect sense in fact it is this type of
requirements that scares pure .net developers away. You cannot ask someone to install a bunch
of tools "outside" of their comfort zone in order to create a tool that works in their world.
Furthermore, it's also saying that now - not only do contributors need to know java and have
a jvm, but then they also need to know sharpen in order to make a c# product.
>>
>> Gentlemen, I would gladly contribute - I can assure you that I wouldn't be the best
but I would be happy to lend a hand - but speaking strictly for myself I don't see myself
learning 2-3 new pieces of technologies when I feel that I should just be a good c# programmer
to help out.
>>
>> Would it not make more sense, given the fact that we want to reduce work and make
a quality product that we become more selective about *what* goes through Sharpen and what
can be hand-crafted? IE: Do we really need to port the Java methods of writing to files and
handling Threading? What about WCF?
>>
>>
>>
>> Karell Ste-Marie
>> C.I.O. - BrainBank Inc
>>
>>
>> -----Original Message-----
>> From: Troy Howard [mailto:thoward37@gmail.com]
>> Sent: Thursday, December 30, 2010 2:46 PM
>> To: lucene-net-dev@lucene.apache.org
>> Cc: lucene-net-user@lucene.apache.org
>> Subject: Re: Vote thread started on general@lucene.apache.org
>>
>> That is exactly what I would suggest. Sharpen looks like a great tool, since you
can customize it's behaviour. In fact, the only downside is that you have to customize it's
behaviour which requires a lot of upfront work.
>>
>> Thanks,
>> Troy
>>
>>
>> On Thu, Dec 30, 2010 at 11:42 AM, Prescott Nasser <geobmx540@hotmail.com> wrote:
>> >
>> > Maybe I'm misunderstanding you, but I think the technology is there - no generic
porting tool will be 100%, it will always require pre/post processing. Sharpen is a pretty
good generic conversion tool.
>> >
>> > I agree in that I think we need to focus on a process utilizing a tool such
as sharpen and developing the pre/post processing clean up scripts that are specific to Lucene.
>> >
>> > ~Prescott
>

Mime
View raw message