[
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 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. Arrange the migrate classpath to put any Jar or Pear 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) 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 Jar pathname and the original.
# update the version of the parser and decompiler dependencies to the current
versions
was:
The design for the migration tool has some defects:
# 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. Arrange the migrate classpath to put any Jar or Pear in front
##* do a compile and reassembly step (if class was found in Jars or Pears) 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 Jar pathname and the original.
# update the version of the parser and decompiler dependencies to the current
versions
> 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 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. Arrange the migrate classpath to put any Jar or Pear 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) 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 Jar pathname and the original.
> # update the version of the parser and decompiler dependencies to the current
> versions
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
