One feature of PEAR packaging of components, is that it implements classpath isolation. So within a PEAR, it can make use of JCas and this will not in any way force the types into other people's type systems, I think. The classes you define within the PEAR will only be "visible" within the PEAR. Outside of the PEAR, in other components in the pipeline, you can have classes with identical names and namespaces, that know nothing about the UIMA types or the JCas definitions in use within the PEAR.
Does this kind of isolation capability address your concern about forcing the types into other people's type systems? Or is it something else? -Marshall On 9/9/2016 5:24 PM, Joern Kottmann wrote: > My point is about b when someone is using Jcas the compile time static > typing is forcing these types into me type system and the classes have to > be on my classpath. It is impossible to use Jcas and not force the types > into other people's type systems. And my opinion is that this is just wrong. > > A framework like Uima has to make it easy to reuse components and in my > opinion strict compile time typing makes that really difficult to achieve. > > But maybe I am wrong and people have some good examples of Jcas based AEs > which are nice to reuse in a simple custom pipeline. > > Jörn > > On Sep 9, 2016 17:58, "Marshall Schor" <[email protected]> wrote: > >> Hi Jörn, >> >> I think people really want to understand the details about why: >> >> a) you are forced to use JCas just because an AE is using it (I assume you >> must >> mean, outside of that AE). Other AEs don't need to use the JCas, so I'm >> misunderstanding something I think, about your point. >> >> b) why JCas isn't acceptable (specifics?). I understand wanting APIs that >> allow >> "dynamic" specifications of types, which UIMA has in its plain CAS APIs. It >> sounds like you see no benefit from what I'll call "compile-time" static >> typing >> style of APIs, which the JCas implies; is that what we're discussing? >> >> Thanks again for your input! >> >> -Marshall >> On 9/9/2016 10:09 AM, Joern Kottmann wrote: >>> Well you are forced to use it when you have to use an AE using it. >>> I think the problem with the JCas is that people think, because we are >>> offering it as part of UIMA, that is is acceptable to use it, but the >> truth >>> is it really isn't. If it would be me deciding, the JCas would be the >> first >>> thing >>> I would throw away for UIMA 3 (and also many other things). >>> >>> Jörn >>> >>> On Fri, Sep 9, 2016 at 4:00 PM, Richard Eckart de Castilho < >> [email protected]> >>> wrote: >>> >>>> On 09.09.2016, at 15:49, Peter Klügl <[email protected]> wrote: >>>>> I get the point with code generation though. >>>>> >>>>> Am 09.09.2016 um 15:11 schrieb Joern Kottmann: >>>>>> I am personally think the convenience the JCas brings is outweighed >> many >>>>>> times by all the complexity >>>>>> and disadvantages which come with it, e.g. code generation step, >> having >>>>>> extra special classes and mostly impossible >>>>>> to reuse the written code. >>>> Again, nothing forces anybody to actually make use of the JCas. >>>> If it does not match your taste, then do not use it. >>>> >>>> If you find the CAS interface to be lacking some convenience, >>>> check out the getFeature() and setFeature() methods in uimaFIT FSUtil >>>> and also the CasUtil select* methods in uimaFIT. >>>> >>>> Cheers, >>>> >>>> -- Richard >>
