This page discusses use cases and operation in V3 related to migrating V2 JCas classes to V3 and handling PEAR files which have embedded JCas classes.

Reporting and Automated Conversions

When a user starts running a pipeline (or calls some other UIMA API operations, see section under "When"), some migrating actions and reporting occurs.  For example, checking is done to validate JCas classes, looking for various conflicts, or version issues.  Automatic conversion of V2 JCas classes may be attempted; these may fail when the user has customized the JCas definition from the plain vanilla one JCasGen created.  Reports can be generated describing the state of affairs detected when starting a pipeline, etc.

We divide these topics here into When, What, and Where:

• When - what events trigger the reporting or converting actions
• What - When the event trigger happens, what is done? If reporting, what is being reported?
• Where - Where does the output go, how is it organized?

Common Use Cases

• A User starts a pipeline described by a descriptor; has JCas classes defined uniquely for all UIMA types in the pipeline, generated using UIMA V3.  In this case, the pipeline starts up, perhaps optionally reporting to a log.
• Same, but the user is using V2 standard JCas Gen with no (or trivial) customization: V3 classes are auto-generated.
• Same, but there is non-trivial customization.  The pipeline generates a report, with enough information to permit a developer to manually integrate customization into a V3 version of the class.
• A User starts a pipeline having 1 (or more) embedded PEAR files. If the PEAR files do not define any JCas classes, things run as now, with PEAR classpath isolation.  If the PEAR defines JCas classes, these are "promoted" to outside-the-PEAR, if no conflict exists with same-named classes; otherwise, if these can be trivially merged, they are; otherwise the pipeline isn't run and a report is generated.

When - events that trigger reporting or converting actions