You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2015/10/29 12:49:27 UTC
[jira] [Updated] (UIMA-4666) UV3 JCasGen
[ https://issues.apache.org/jira/browse/UIMA-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor updated UIMA-4666:
---------------------------------
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
was:
Changes to JCasGen approach.
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
> UV3 JCasGen
> -----------
>
> Key: UIMA-4666
> URL: https://issues.apache.org/jira/browse/UIMA-4666
> Project: UIMA
> Issue Type: Story
> Reporter: Marshall Schor
>
> 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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)