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 10:46:21 GMT
Hi Marshall,

sorry it was late and I was tired. I eventually found the solution. The 
problem came from the deprecation of  setDescripor, for instance the 
statements:

            CpeIntegratedCasProcessor basf =
                CpeDescriptorFactory.produceCasProcessor("BasicForms");
            
basf.setDescriptor(root.getLocation().append(BasicFormPath).toOSString());

are no longer accepted by the compiler, I replaced them by things like:

            CpeIntegratedCasProcessor basf =
                CpeDescriptorFactory.produceCasProcessor("BasicForms");
            CpeComponentDescriptor ccd = 
UIMAFramework.getResourceSpecifierFactory().createDescriptor();
            ccd.setSourceUrl(new 
URL("file://"+root.getLocation().append(BasicFormPath).toOSString()));
            basf.setCpeComponentDescriptor(ccd);

And it was a mistake, the change should have been:

            CpeIntegratedCasProcessor basf =
                CpeDescriptorFactory.produceCasProcessor("BasicForms");
            CpeComponentDescriptor ccd = 
UIMAFramework.getResourceSpecifierFactory().createDescriptor();
            //ccd.setSourceUrl(new 
URL("file://"+root.getLocation().append(BasicFormPath).toOSString()));
            CpeInclude cpeInclude = 
UIMAFramework.getResourceSpecifierFactory().createInclude();
            
cpeInclude.set(root.getLocation().append(BasicFormPath).toOSString());
            ccd.setInclude(cpeInclude);
              basf.setCpeComponentDescriptor(ccd);

Another very important point to highlight is not to forget (as you 
taught me some months ago) to replace in the manifest plugin:

Eclipse-BuddyPolicy: registered
Eclipse-RegisterBuddy: com.ibm.uima.debug,
 com.ibm.uima.desceditor,
 com.ibm.uima.jcas.jcasgenp,
 com.ibm.uima.pear,
 com.ibm.uima.runtime

by :

Eclipse-BuddyPolicy: registered
Eclipse-RegisterBuddy:
 org.apache.uima.debug,
 org.apache.uima.desceditor,
 org.apache.uima.jcas.jcasgenp,
 org.apache.uima.pear,
 org.apache.uima.runtime

In order to make UIMA recognizes the plugin's classes. On this topic I 
noticed only org.apache.uima.runtime contains the instruction 
'Eclipse-BuddyPolicy: registered' in its manifest. I added it in the 
other plugins because I believe it could provoke error messages when 
editing the generated descriptors in the application project (even if it 
is not the purpose)

So, sorry for this access of bad mood, I do not regret th have chosen 
UIMA, you guys have done a great work!


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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message