[
https://issues.apache.org/jira/browse/UIMA-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor updated UIMA-4518:
---------------------------------
Description:
Add a standalone tooling for migrating v2 JCas classes to V3 style, while
preserving any customization that may have been done.
Initial approach:
* command line tool,
* inputs are file system "roots" which are searched for either .java or .class
files, recursively, including within Jar files.
** For all that are likely JCas classes (use various heuristics, including if
there is a paired ..._Type class), migrate the source form.
*** If starting with .class files, decompile those first to get the source
form.
* The migration consists of first parsing the source into an AST (Java Abstract
Syntax Tree), and then having a view visitor methods to modify selected parts
of the tree, including getters/setters and the 2-arg constructor.
* The migration tool should also report summaries of what it did, and handle
things like multiple instances (including identifying which of these are
ignorable because the files are all the same, and which have differences - so
the user can decide).
was:Some of the discussion for uv3x (UIMA Version 3 experiments) involve a
new incompatible approach for JCas cover classes. To aid in migration,
develop tooling that will identify those cover classes which have been
customized (hopefully, a small number). This has two parts: one is dumping
(under the control of some flag) decompiled versions of all loaded JCas cover
classes, and another tool that inspects those and determines which ones have
been customized. Special handling is needed for PEARs which might redefine the
cover classes.
> uv3x Customized JCas cover class migration tooling
> --------------------------------------------------
>
> Key: UIMA-4518
> URL: https://issues.apache.org/jira/browse/UIMA-4518
> Project: UIMA
> Issue Type: New Feature
> Components: Core Java Framework
> Reporter: Marshall Schor
> Priority: Minor
>
> Add a standalone tooling for migrating v2 JCas classes to V3 style, while
> preserving any customization that may have been done.
> Initial approach:
> * command line tool,
> * inputs are file system "roots" which are searched for either .java or
> .class files, recursively, including within Jar files.
> ** For all that are likely JCas classes (use various heuristics, including if
> there is a paired ..._Type class), migrate the source form.
> *** If starting with .class files, decompile those first to get the source
> form.
> * The migration consists of first parsing the source into an AST (Java
> Abstract Syntax Tree), and then having a view visitor methods to modify
> selected parts of the tree, including getters/setters and the 2-arg
> constructor.
> * The migration tool should also report summaries of what it did, and handle
> things like multiple instances (including identifying which of these are
> ignorable because the files are all the same, and which have differences - so
> the user can decide).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
