[
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
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)
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:
* migrateClasspath 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 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)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
