Adam Lally wrote:
Yes, this topic again...
While working on a utility to migrate code from IBM UIMA to Apache
UIMA, I encountered the case where the user's project has a definition
of com.ibm.uima.jcas.tcas.DocumentAnnotation. That's because JCasGen
creates this, to account for cases where the user has defined their
own features to add to DocumentAnnotation.
As far as the migration goes, this would need to become
org.apache.uima.jcas.tcas.DocumentAnnotation. But I can't do that
with search-and-replace, I'd actually have to move the file to a
different directory. Instead of doing that, this may become a manual
migration step. (If the user did not add custom code, just deleting
this file and rerunning JCasGen is sufficient.)
I would recommend that the migration tool move the file (to the new
'package').
It also occurred to me that we lost uima_jcas_builtin_types.jar as
part of our Maven restructuring. This jar contained the
DocumentAnnotation class, which was not in uima_core.jar. This was
done so that applications could exclude this jar from their classpath
to allow a user-generated DocumentAnnotation class to be used instead
of the one that ships with UIMA. But this is pretty ugly.
Questions:
1) Do we continue to support adding features to DocumentAnnotation?
It breaks a lot of user code if we stop supporting this. We might
consider doing
this as part of the change-over to Apache, but if we did, I think we
would need
to implement the ability for users to more easily store and find data in
the CAS that
they were using the Document Annotation for, before.
2) If so, should we delete the JCAS DocumentAnnotation class from the
framework code entirely, to avoid the problem that required the
uima_jcas_builtin_types.jar workaround?
If it is deleted, it might break old code generated before JCasGen was
modified
to create this class. In that case, there would be no JCas cover class
for it at all.
That's unlikely to be a problem, unless the user was looking for the
only default
built-in feature (language). And there's an easy work-around - run JCasGen.
I don't recall other reasons for having it - does anyone else?
3) What should the migration story be for existing user code?
Depends if we keep the ability to expand the features of this class or
not, and
if we implement an easier way to get specific data items from the CAS.
-Marshall
