uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Updated] (UIMA-5384) uv3 migration tool class path setup
Date Sun, 09 Apr 2017 14:03:41 GMT

     [ https://issues.apache.org/jira/browse/UIMA-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marshall Schor updated UIMA-5384:
---------------------------------
    Description: 
There are multiple issues with the migrateClasspath setup for v3 migration.  

There are two uses of the classpath.  
* One is for decompiling the v2 compiled classes, when migrating from classes - roots.
* The other is for (optional) compiling of the resulting converted source.  These is done
for the use case where the v2 classes were in JARs or PEARs, and the result of the conversion
is new versions of these JARs or PEARs with converted JCas classes. 

The classpath passed for migrateClasspath should be the v2 classpath needed for decompiling
the v2 JCas classes. When recompiling, the classpath for v3 uimaj-core is prepended.

migrateClasspath is temporarily augmented when migrating PEAR files, by prepending any PEAR
classpath specs.
A separate Jira improved the migrateClasspath to permit the Java style of classpath specs
using a trailing wildcard (*).

Changes needed:

* if the migrateClasspath argument is not set:
** if migrating from classes roots, treat this as an error; migrateClasspath is required in
order to properly decompile.
*** Add a note that this classpath must include the classes being migrated, because they are
read from that classpath.
** If migrating from sources roots, if the migrateClasspath is not set, substitute the application
classpath, with a warning.

* for compiling: 
*# do the PEAR prepending if the source came from a pear.
*# prepend at the very front, the uimaj-core-v3 (or the app classpath).

  was:
There are multiple issues with the migrateClasspath setup for v3 migration.  

There are two uses of the classpath.  
* One is for decompiling the v2 compiled classes, when migrating from classes - roots.
* The other is for (optional) compiling of the resulting converted source.  These is done
for the use case where the v2 classes were in JARs or PEARs, and the result of the conversion
is new versions of these JARs or PEARs with converted JCas classes. 

The classpath passed for migrateClasspath should be the v2 classpath needed for compiling
the v2 JCas classes.

migrateClasspath is temporarily augmented when migrating PEAR files, by prepending any PEAR
classpath specs.
A separate Jira improved the migrateClasspath to permit the Java style of classpath specs
using a trailing wildcard (*).

Changes needed:

* if the migrateClasspath argument is not set:
** if migrating from classes roots, treat this as an error; migrateClasspath is required in
order to properly decompile.  This must include the v2 uimaj-core for proper decompiling.
** If migrating from sources roots, substitute the application classpath, with a warning.

* refactor handling of migrateClasspath so that 
** it is converted once to the URL[] (processing any wild card or directory expansions)
** augmentations are done using that converted form
* for both decompiling and compiling:
*# when within a JAR, prepend that JAR to migrateClasspath

* for compiling: 
*# do the PEAR prepending if the source came from a pear.
*# prepend at the very front, the uimaj-core-v3 (or the app classpath).
*# set the sourcePath compiler arg to converted/v3 to pick up any converted source (see http://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html#BHCJJJAJ)


> uv3 migration tool class path setup
> -----------------------------------
>
>                 Key: UIMA-5384
>                 URL: https://issues.apache.org/jira/browse/UIMA-5384
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework, Tools
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>             Fix For: 3.0.0SDK-beta
>
>
> There are multiple issues with the migrateClasspath setup for v3 migration.  
> There are two uses of the classpath.  
> * One is for decompiling the v2 compiled classes, when migrating from classes - roots.
> * The other is for (optional) compiling of the resulting converted source.  These is
done for the use case where the v2 classes were in JARs or PEARs, and the result of the conversion
is new versions of these JARs or PEARs with converted JCas classes. 
> The classpath passed for migrateClasspath should be the v2 classpath needed for decompiling
the v2 JCas classes. When recompiling, the classpath for v3 uimaj-core is prepended.
> migrateClasspath is temporarily augmented when migrating PEAR files, by prepending any
PEAR classpath specs.
> A separate Jira improved the migrateClasspath to permit the Java style of classpath specs
using a trailing wildcard (*).
> Changes needed:
> * if the migrateClasspath argument is not set:
> ** if migrating from classes roots, treat this as an error; migrateClasspath is required
in order to properly decompile.
> *** Add a note that this classpath must include the classes being migrated, because they
are read from that classpath.
> ** If migrating from sources roots, if the migrateClasspath is not set, substitute the
application classpath, with a warning.
> * for compiling: 
> *# do the PEAR prepending if the source came from a pear.
> *# prepend at the very front, the uimaj-core-v3 (or the app classpath).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message