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 19:46:18 GMT
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
>
>
>
>> Subject: RE: RE: Vote thread started on general@lucene.apache.org
>> Date: Thu, 30 Dec 2010 14:29:21 -0500
>> From: stemarie@brain-bank.com
>> To: lucene-net-dev@lucene.apache.org; lucene-net-user@lucene.apache.org
>>
>> Folks,
>>
>> I will freely admit that I'm seizing the opportunity to raise an old
>> point - but that problem would be non-existent if this was a project
>> that implemented a methodology as opposed to being a continuous port
>> effort. I will even go as far as suggesting that this would broaden (and
>> ease) the recruitment of committers. It almost feels like the goal is
>> not simply to port Lucene.java to Lucene.net but to also develop a
>> technology that ports things automatically. I would almost suggest that
>> this in itself could be an ASF TLP. It still feels to me that everyone
>> is trying to cut the head off a two-headed dragon with a single sword
>> and a single motion.
>>
>> Once search algorithms was discovered and implemented - it should be up
>> to the language-specific programmers to implement these and optimize
>> these as they see fit. Both languages have their strengths and their own
>> frameworks - at the moment the java side has great benefits which in
>> turn greatly hinder the success of the .net side.
>>
>> In a nutshell, while some cultures seem to be better at courtship - the
>> fact that I don't speak some of these languages shouldn't make me less
>> good at it.
>>
>> I think that a project for a Java->NET and NET->Java would be a great
>> idea. Again, it would allow a lot of people that are doing the same for
>> hundreds of other projects to simply pool their efforts.
>>
>> Just my Canadian 2 cents (which is almost at par with the American cents
>> these days)
>>
>>
>> Karell Ste-Marie
>> C.I.O. - BrainBank Inc
>>
>> -----Original Message-----
>> From: Lombard, Scott [mailto:slombard@KINGINDUSTRIES.COM]
>> Sent: Thursday, December 30, 2010 2:17 PM
>> To: lucene-net-dev@lucene.apache.org; lucene-net-user@lucene.apache.org
>> Subject: RE: RE: Vote thread started on general@lucene.apache.org
>>
>> Marco,
>>
>> My feeling would be to create strong automated conversion tools to allow
>> java Lucene to be ported in to .NET in as few steps and as possible.
>> The .net style goal is a noble one, but will require a significant more
>> commitment to the project in the future. As each new version of java
>> Lucene will have to be integrated by hand into the .net version.
>>
>> As the conversion tools get more advanced and robust .net style code may
>> be implemented as part of the automated conversion process.
>>
>>
>> Scott
>

Mime
View raw message