uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: Sandbox: LuCas Lucene update
Date Wed, 13 Apr 2011 15:24:48 GMT
Hello again Erik,
from what I've seen and tested your patch looks good, if Jörn's tests behave
as expected I think we can commit it.

2011/4/13 Tommaso Teofili <tommaso.teofili@gmail.com>

> Thanks Erik,
> I'm going to review your patch now :)
> The capabilities you mentioned are not implemented yet in Solrcas but I
> hope we can bring them there as well.
> Regads,
> Tommaso
> 2011/4/13 Erik Fäßler <erik.faessler@uni-jena.de>
>>  Am 13.04.2011 14:49, schrieb Jörn Kottmann:
>>  On 4/13/11 2:44 PM, Erik Fäßler wrote:
>>>>  Hello Tommaso,
>>>> thanks a lot for your reply :) I will follow the steps you gave me as
>>>> soon as there is a little time for this.
>>>> Also thanks for the SolrCas hint. I think we already talked about this.
>>>> As far as I understood, Solrcas as well as the Solr-UIMA integration lack
>>>> some of the features offered by LuCas, for example the alignment of
>>>> TokenStreams which allows you to merge multiple CAS indexes into a single
>>>> Lucene field where position_increments are adjusted to stack Lucene tokens
>>>> with the same offsets. Please (!!) tell me when I'm wrong here, as I am
>>>> still working on my own ways to use UIMA together with Solr.
>>> I might have time next week to work on the Lucas component, because I
>>> also need it for a project.
>>> Maybe that would be a good chance to apply and test your patch.
>>> Jörn
>> Great - as its best to get things done quickly, I just updated my version
>> to the latest trunk version, made sure the tests are still running and
>> created the patch. The corresponding Jira issue can be found at
>> https://issues.apache.org/jira/browse/UIMA-2126
>> If something is wrong with the issue, please let me know - it's the first
>> I've created (e.g. I expect the "Affects Version/s" field to not match the
>> issue, but I could be wrong).
>> Erik
>> **

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message