uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: UIMA Apache is a real pain
Date Thu, 30 Aug 2007 13:46:27 GMT
Hi Christian -

I see you are doing some fancy Eclipse plugin programming :-)  We
appreciate your comments - you can probably teach us a few tricks here, too!

Things that we deprecate are not (at least not intentionally :-) removed
until we're pretty sure it won't affect our users; we value having our
users be able to depend on keeping things stable/working, where possible.

We use deprecation to signal that new work using these APIs should use
the new method(s); but previous code should still run (unless there is
some very unusual circumstance).

When you say "... are no longer accepted by the compiler" - did you mean
it compiled, but you got a deprecation warning?  If so, it still should
have worked, I think.  If the deprecation messages bother you, you can
turn them off in Eclipse (you probably know how to do this already - but
for others reading this note:  menu in Eclipse 3.3: windows ->
preference ->java -> compiler -> Errors/Warnings , then scroll down to
"Deprecated and Restricted APIs").

Finally, because you're doing here some advanced techniques (e.g.
building up a descriptor inside an Eclipse plugin, at run-time), you're
venturing into areas of the framework that are perhaps less well
documented - so please feel free to ask questions (and perhaps suggest
improvements to the docs).


Christian Mauceri wrote:
> 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!

View raw message