Hi Pascal -
When you say the CAS Initializers "disappeared" - what is it that you're
looking for that's no longer there,
specifically? I don't think we intentionally removed this in the
implementation.
Another thing we're contemplating is "requiring" the Java 5 level (or
later) in future UIMA releases. Would that be
costly for your projects?
-Marshall
Pascal Coupet wrote:
> We are also in the process to move our product to the UIMA version. We
> got a working version within hours without special problem and it's a
> big product using the whole framework.
>
> I think that there is still some support on the IBM version since
> OmniFind is using it but using the UIMA version is a good move. The
> design is cleaner and it's better to be on the mainstream for support,
> features and interoperability.
>
> The costliest part for us is to convert all our sources using CAS
> Initializers since it was deprecated in version 2 and disappeared in
> version 2.2 . I'm wondering if there is a way to build a version 2.2
> with XCAS Initializer support?
>
> Thanks,
>
> Pascal
>
> Pascal Coupet
>
> -----Original Message-----
> From: Andrew Serff [mailto:lists@serff.net]
> Sent: Thursday, August 30, 2007 10:02 AM
> To: uima-user@incubator.apache.org
> Subject: Re: UIMA Apache is a real pain
>
> I can attest to only having to change the package names. I converted
> the BaLIE Annoator in a matter of seconds by just changing the package
> names to use the apache package names. I didn't have to change anything
>
> else to use it under the Apache UIMA. So I'd keep on trying, let
> everyone know what your specific problem is and I'm sure someone will be
>
> able to help you. IBM isn't moving forward on the UIMA SDK (unless I
> just don't know...), so it seems almost necessary that people move to
> Apache if they want to get new features, etc.
>
> Good Luck!
> Andrew
> Marshall Schor wrote:
>
>> Hi -
>>
>> Sorry to hear you're having such a frustrating time!
>>
>> It's a little hard to figure out what might be helpful here without
>>
> some
>
>> further details. I don't think anything changed in the implementation
>> that would alter the behavior you describe regarding CPEs. Can you
>> describe what's going wrong?
>>
>> We're continually trying to balance going forward with keeping
>>
> backwards
>
>> compatibility. When moving to Apache UIMA, there was a need to change
>> the package names (to org.apache.uima...) - that was the biggest
>>
> change
>
>> that required users to change their code and recompile. We included a
>> utility that attempted to update the source for these changes - were
>>
> you
>
>> able to make use of it?
>>
>> -Marshall
>>
>>
>> Christian Mauceri wrote:
>>
>>
>>> I spent some hours in trying to port my old UIMA IBM Appli in the
>>> Apache version and it's a real pain where you know. I do not
>>> understand why to change things at this point and make things so
>>> difficult for the others. I do not see the benefit for anybody, one
>>> can imagine the decision to use UIMA is not spending all the time in
>>> trying to understand the deprecated functions, the PATH rules etc.
>>> Something becomes a standard because it is supposed to be useful and
>>> make people life easier. For my deepest regret it is not the case for
>>> this version of UIMA. Among other thing I cannot understand why it is
>>> not possible to embed in simple way descriptors and CPEs in a plugin
>>> and forget the machinery beyond, let's imagine if for instance EMF
>>> produced such head ache.
>>> In the IBM version it was possible to generate a CPE and put it in a
>>> folder with the other descriptors and have an Eclipse action doing
>>> something like :
>>>
>>> CpeDescription cpeDesc = UIMAFramework.getXMLParser()
>>> .parseCpeDescription(
>>> new
>>> XMLInputSource(cpeFile.getLocation().toOSString()));
>>> CollectionProcessingEngine cpe =
>>> UIMAFramework.produceCollectionProcessingEngine(cpeDesc);
>>>
>>> then something like
>>>
>>> monitor.beginTask("Starting CPE", nod);
>>> //Create and register a Status Callback
>>>
> Listener
>
>>>
>>> StatusCallbackListenerImpl cbl =
>>> new StatusCallbackListenerImpl(monitor);
>>> cpe.addStatusCallbackListener(cbl);
>>> cpe.process();
>>> while
>>>
> (!cbl.isFinished()){
>
>>> if(monitor.isCanceled()){
>>> cpe.stop();
>>> return Status.CANCEL_STATUS;
>>> }
>>> }
>>>
>>> without worrying about the CLASSPATH or I do not know what, why is it
>>> that difficult now? Because we have to suffer before having the right
>>> to use this so wonderful framework?
>>>
>>> I'm at 1 month from a crucial deadline, I need the Eclipse 3.3
>>> version, I regret my first choice, deeply!
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
|