[jira] [Updated] (UIMA-5421) uv3 migration tool design fixes
[ 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)
[jira] [Updated] (UIMA-5421) uv3 migration tool design fixes
[ 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-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 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 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 > 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-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 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5421) uv3 migration tool design fixes
[ 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. 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-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 > 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
[jira] [Updated] (UIMA-5421) uv3 migration tool design fixes
[ 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
[jira] [Updated] (UIMA-5421) uv3 migration tool design fixes
[ 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