Hi,
I think the idea to add the possibility to specify interfaces would be a nice
enhancement, since there are some places in our case where this would have made
life easier, especially if specifying multiple interfaces are allowed. I don’t
think interfaces will necessarily address all issues
Yes, That's what I did with the AnnotationWrapper class I wrote (see my
other messages on that same thread).
It's a bit hacky, so I was hoping that there was a more UIMA native
solution to this problem.
On Mon, Nov 18, 2019 at 12:33 PM Olga Patterson
wrote:
> If you just want an easier way to
If you just want an easier way to manipulate annotations, you can have a
utility class that would have all methods separate from the annotation types
Example code from
http://decipher.chpc.utah.edu/nexus/index.html#nexus-search;classname~Annotationlibrarian
gov.va.vinci
Here is an improved version of my AnnotationWrapper class. This one will
raise an exception if you try to instantiate a wrapper directly through its
constructor, instead of through AnnotationWrapper.wrap().
The reason for this are explained in the Synopsis test.
On Fri, Nov 15, 2019 at 6:25 PM
FYI, attached is a ZIP file that contains my AnnotationWrapper solution to
this problem. It's a bit of a hack, but it has worked for me.
The ZIP file contains the following classes:
- MyAnnotation.java: subclass of Annotation
- MyAnnotationWrapper.java: The wrapper for MyAnnotation.
-
On 15. Nov 2019, at 17:59, Marshall Schor wrote:
>
> I'm wondering how to arrange things so that for JCas class "x.y.z.Foo",
>
> you could have an associated class or interface that could make use of the
JCasGen could generate an interface "IMyAnnotation" which defines the accessors
methods.
Interesting...
I'm wondering how to arrange things so that for JCas class "x.y.z.Foo",
you could have an associated class or interface that could make use of the
getters and setters for the features in the Foo type.
-Marshall
On 11/15/2019 11:34 AM, Richard Eckart de Castilho wrote:
> On 15.
On 15. Nov 2019, at 17:26, Marshall Schor wrote:
>
> Also, you might not run the JCasGen code very often, because it only would
> need
> to be run if the type system changed.
I think with Java supporting default methods in interfaces these days, it would
be great
if there was a way to have an
On 11/15/2019 11:20 AM, Alain Désilets wrote:
> Yeah, but won't my additions be destroyed the next time I modify the XML
> file and regenerate the typesystem?
Maybe not. It might depend on exactly how you are generating. The basic
JCasGen software (that builds the code) is careful to preserve
On 15. Nov 2019, at 17:20, Alain Désilets wrote:
>
> Yeah, but won't my additions be destroyed the next time I modify the XML
> file and regenerate the typesystem?
Afaik yes. That's why such files get committed to the version control and are
not regenerated all the time. If the XML changes and
Yeah, but won't my additions be destroyed the next time I modify the XML
file and regenerate the typesystem?
On Fri, Nov 15, 2019 at 10:58 AM Marshall Schor wrote:
> Even though the JCas classes can be generated from the XML file, you are
> allowed
> to add additional things to those source
Even though the JCas classes can be generated from the XML file, you are allowed
to add additional things to those source files, including
- additional fields
- additional methods
See
http://uima.apache.org/d/uimaj-2.10.4/references.html#ugr.ref.jcas.augmenting_generated_code
-Marshall
On Thu, Nov 14, 2019 at 4:51 PM Richard Eckart de Castilho
wrote:
> Sure. You generate the JCas classes once and then you add the methods you
> want
> to them. Cf. e.g.
>
>
>
Sure. You generate the JCas classes once and then you add the methods you want
to them. Cf. e.g.
One of the things that drives me nuts about the UIMA type definition system
is that it seems very hard (if not impossible?) to create new types of
annotation that have additional methods.
My approach to dealing with that has been to wrap the annotation into a
wrapper class that decorates the
15 matches
Mail list logo
