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.) 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? 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? 3) What should the migration story be for existing user code? -Adam
