[
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 the uv3 core 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.
# 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.
# update the version of the parser and decompiler dependencies to the current
versions
# update the documentation.
# properly handle jars containing pears, pears containing jars.
# allow no migrate classpath when migrating from classes (useful for migrating
Pear files)
# break the compile step for a container into multiple sets of compilation
units, if different versions exist for the same classname (otherwise get
compiler error - duplicate definition)
# print out all compiler errors and messages
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.
# switch to uniform way of internally identifying artifacts - rootId + fully
qualified class name
# properly handle jars containing pears, pears containing jars.
> 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 the uv3 core 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.
> # 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.
> # update the version of the parser and decompiler dependencies to the current
> versions
> # update the documentation.
> # properly handle jars containing pears, pears containing jars.
> # allow no migrate classpath when migrating from classes (useful for
> migrating Pear files)
> # break the compile step for a container into multiple sets of compilation
> units, if different versions exist for the same classname (otherwise get
> compiler error - duplicate definition)
> # print out all compiler errors and messages
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
