Mailing-List: contact uima-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: uima-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: UIMA Apache is a real pain
Date: Thu, 30 Aug 2007 16:12:16 +0200
Message-ID: <F3BED77B64E715419071BBFC02F9F1BC020277F1@EXV01001.GlobalSP.local>
Thread-Topic: UIMA Apache is a real pain
Thread-index: AcfrCa29eb69rBQESf+aB77BsX2qogABYf/w
References: <46D5F2E8.50507@hermeneute.com> <46D621ED.5000200@schor.com>
 <46D6797A.2090902@serff.net>
 <F3BED77B64E715419071BBFC02F9F1BC02027742@EXV01001.GlobalSP.local>
 <46D6C5D1.5090706@schor.com>
From: "Pascal Coupet" <pascal.coupet@temis.com>
To: <uima-user@incubator.apache.org>


Hi Marshall,

The guy who tested the source part during our migration test got an
error on XCAS Initializers and conclued maybe wrongly that they were
removed from version 2.2. We are investigating that again and I let you
know.=20

No problem for Java 5. It's a good move for us and we are already
compatible.

Pascal =20

-----Original Message-----
From: Marshall Schor [mailto:msa@schor.com]=20
Sent: Thursday, August 30, 2007 3:28 PM
To: uima-user@incubator.apache.org
Subject: Re: UIMA Apache is a real pain

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.=20
>
> 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. =20
>
> 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]=20
> 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=20
> 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=20
> 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=20
> just don't know...), so it seems almost necessary that people move to=20
> Apache if they want to get new features, etc.=20
>
> Good Luck!
> Andrew
> Marshall Schor wrote:
>  =20
>> Hi -
>>
>> Sorry to hear you're having such a frustrating time!=20
>>
>> It's a little hard to figure out what might be helpful here without
>>    =20
> some
>  =20
>> 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?=20
>>
>> We're continually trying to balance going forward with keeping
>>    =20
> backwards
>  =20
>> compatibility.  When moving to Apache UIMA, there was a need to
change
>> the package names (to org.apache.uima...) - that was the biggest
>>    =20
> change
>  =20
>> that required users to change their code and recompile.  We included
a
>> utility that attempted to update the source for these changes - were
>>    =20
> you
>  =20
>> able to make use of it?
>>
>> -Marshall
>>
>>
>> Christian Mauceri wrote:
>>  =20
>>    =20
>>> 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 =3D UIMAFramework.getXMLParser()
>>>                .parseCpeDescription(
>>>                        new
>>> XMLInputSource(cpeFile.getLocation().toOSString()));
>>> CollectionProcessingEngine cpe =3D
>>> UIMAFramework.produceCollectionProcessingEngine(cpeDesc);
>>>
>>> then something like
>>>
>>>                        monitor.beginTask("Starting CPE", nod);
>>>                        //Create and register a Status Callback
>>>      =20
> Listener
>  =20
>>>                                            =20
>>> StatusCallbackListenerImpl cbl =3D
>>>                            new StatusCallbackListenerImpl(monitor);
>>>                        cpe.addStatusCallbackListener(cbl);
>>>                                              cpe.process();
>>>                                              while
>>>      =20
> (!cbl.isFinished()){
>  =20
>>>                            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!
>>>
>>>
>>>    =20
>>>      =20
>>  =20
>>    =20
>
>
>
>
>  =20