uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Mauceri <mauc...@hermeneute.com>
Subject Re: UIMA Apache is a real pain
Date Thu, 30 Aug 2007 13:03:31 GMT
Andrew,

see my answer. Things are a little bit more difficult when you generate 
the descriptors on the fly because it's not just a matter of changing 
the content of static ones.  But yes I trust  Marshall  on that, it is  
just  that  I think we should think twice before deprecating methods. 
Besides I believe one great virtue of a standard is stability and well I 
spent far too much time on this necessary upgrade to Eclipse 3.3 and I 
would have been more than happy not to be obliged to move on UIMA Apache 
on top of that.

Andrew Serff wrote:
> 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!
>>>
>>>
>>>     
>>
>>   
>
>
>
>

-- 
Cordialement/Regards
Christian Mauceri
http://hermeneute.com/Christian


Mime
View raw message