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:[EMAIL PROTECTED] > Sent: Thursday, August 30, 2007 10:02 AM > To: [email protected] > 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! >>> >>> >>> >>> >> >> > > > > >
