[UIMA-5421] uv3 migration tool design fixes

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.0SDK-alpha02
• Fix Version/s: 3.0.0SDK-beta
• Component/s: Core Java Framework, Tools
• Assignee: Marshall Schor
• Reporter: Marshall Schor
• Created: 05/May/17 14:47
• Updated: 02/Jun/17 17:59
• Resolved: 02/Jun/17 17:59

Description

The design for the migration tool has some defects. The main one is it should migrate all versions

1. the migrate from sources vs from classes should operate differently:
   1. 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.
   2. 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.
2. 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.
3. update the version of the parser and decompiler dependencies to the current versions
4. update the documentation.
5. properly handle jars containing pears, pears containing jars.
6. allow no migrate classpath when migrating from classes (useful for migrating Pear files)
7. 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)
8. print out all compiler errors and messages