After thinking about this some more here's my a proposed plan of action:
1) We explicilty document that "feature extension" (meaning the practice of defining a type in two different places, with different features, causing those feature sets to be merged) is incompatible with JCAS. The "owner" of a type (whoever defined it first) should get to choose the features and generate the one and only JCas class. If a user of this type wants to add their own features, UIMA supports this only through the "plain" CAS API, not the JCAS. JCasGen and CDE should give warnings when they encounter multiple non-identical definitions of the same type. 2) The UIMA Framework "owns" the definition of uima.tcas.DocumentAnnotation and its corresponding JCAS class. So users MAY NOT have their own JCAS cover classes for DocumentAnnotation. JCasGen should stop generating DocumentAnnotation classes. 3) We will provide a convient way for users to define their own global metadata types and easily access them in the CAS. 4) Migration path: Users must delete any DocumentAnnotation JCas cover class that they have. If they have added custom features, then they either have to change their code to not use JCAS (for accessing these particular features), or they have to define their own global metadata type and change their code to use that rather than the DocumentAnnotation. I don't think there's a good way to make JCAS and feature extension coexist happily, so let's acknowledge that they don't. It's never ideal to break users' code but I think this is worth it. I'm guessing most users haven't used feature extension anyway, so the effect is minor. Thoughts? -Adam
