[
https://issues.apache.org/jira/browse/UIMA-5421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor updated UIMA-5421:
---------------------------------
Description:
The design for the migration tool has some defects. The main one is it should
migrate all versions
# the migrate from sources vs from classes should operate differently:
## sources
##* migrate the source, no subsequent compilation; no reassembly (in Jars or
PEARs)
##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be
rebuilt and advising to delete the xxx_Type.java files.
## classes
##* decompile. Always use the original byte array for decompiling (current
impl switches to the version from the classpath). Arrange the migrate classpath
to put any Jar or Pear-classpath in front.
##* do a compile using above modified migrate classpath (plus uv3 in front) and
reassembly step (if class was found in Jars or Pears, an no compile errors) by
copying the original assembly and updating the class part, including deleting
the xxx_Type.class files.
# drop support for Jars inside Jars; only support the nesting case of Jars
inside Pears because more general support makes the re-assembly step overly
complex
# change the output naming convention to support multiple compiled migrations -
for example, having the same class inside multiple updated Jars, with obvious
tracking between the output pathnames and the original, based on a new concept
of root-id, an incrementing int starting with 1, and suffixed with a J or P if
for a Jar or a PEAR.
# update the version of the parser and decompiler dependencies to the current
versions
# update the documentation.
# switch to uniform way of internally identifying artifacts - rootId + fully
qualified class name
# properly handle jars containing pears, pears containing jars.
was:
The design for the migration tool has some defects. The main one is it should
migrate all versions
# the migrate from sources vs from classes should operate differently:
## sources
##* migrate the source, no subsequent compilation; no reassembly (in Jars or
PEARs)
##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be
rebuilt and advising to delete the xxx_Type.java files.
## classes
##* decompile. Always use the original byte array for decompiling (current
impl switches to the version from the classpath). Arrange the migrate classpath
to put any Jar or Pear-classpath in front.
##* do a compile using above modified migrate classpath (plus uv3 in front) and
reassembly step (if class was found in Jars or Pears, an no compile errors) by
copying the original assembly and updating the class part, including deleting
the xxx_Type.class files.
# drop support for Jars inside Jars; only support the nesting case of Jars
inside Pears because more general support makes the re-assembly step overly
complex
# change the output naming convention to support multiple compiled migrations -
for example, having the same class inside multiple updated Jars, with obvious
tracking between the output pathnames and the original, based on a new concept
of root-id, an incrementing int starting with 1, and suffixed with a J or P if
for a Jar or a PEAR.
# update the version of the parser and decompiler dependencies to the current
versions
# update the documentation.
> uv3 migration tool design fixes
> -------------------------------
>
> Key: UIMA-5421
> URL: https://issues.apache.org/jira/browse/UIMA-5421
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework, Tools
> Affects Versions: 3.0.0SDK-alpha02
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Fix For: 3.0.0SDK-beta
>
>
> The design for the migration tool has some defects. The main one is it
> should migrate all versions
> # the migrate from sources vs from classes should operate differently:
> ## sources
> ##* migrate the source, no subsequent compilation; no reassembly (in Jars or
> PEARs)
> ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be
> rebuilt and advising to delete the xxx_Type.java files.
> ## classes
> ##* decompile. Always use the original byte array for decompiling (current
> impl switches to the version from the classpath). Arrange the migrate
> classpath to put any Jar or Pear-classpath in front.
> ##* do a compile using above modified migrate classpath (plus uv3 in front)
> and reassembly step (if class was found in Jars or Pears, an no compile
> errors) by copying the original assembly and updating the class part,
> including deleting the xxx_Type.class files.
> # drop support for Jars inside Jars; only support the nesting case of Jars
> inside Pears because more general support makes the re-assembly step overly
> complex
> # change the output naming convention to support multiple compiled migrations
> - for example, having the same class inside multiple updated Jars, with
> obvious tracking between the output pathnames and the original, based on a
> new concept of root-id, an incrementing int starting with 1, and suffixed
> with a J or P if for a Jar or a PEAR.
> # update the version of the parser and decompiler dependencies to the current
> versions
> # update the documentation.
> # switch to uniform way of internally identifying artifacts - rootId + fully
> qualified class name
> # properly handle jars containing pears, pears containing jars.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
