Details
-
Story
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Changes to JCasGen approach.
Allow users an easy migration from existing JCasGen classes
- a reporting tool that identifies existing JCas gen classes being used
- tooling support for setting up "merged" JCasGen class definitions from multiple sources
- Goal: support PEARs having different (but mergable) JCasGen definitions
Internal: only one class per type - the xxx_type class is removed in UV3
- document migration path for users previously using xxx_type capabilities for low-level CAS operation
Document use-cases for JCasGen customization and changes possible due to new support for JavaObjects as data in Features.
Document the use-cases supported, including
- A single set of JCasGen classes used for different type systems
- External semi-manual merging of JCasGen classes from PEARs and their
containers - Continuing to have JCasGen optional