On 1/13/2017 2:51 PM, Richard Eckart de Castilho wrote:
> Hi Marshall,
>
>> On 13.01.2017, at 04:50, Marshall Schor <m...@schor.com> wrote:
>>
>> 1) I made a version of uimaFIT and Ruta for v3, and called them by some
>> different version number.  
>>
>> Having a separate version allows the builds to create separate sets of Maven
>> objects, which don't "overlay" the others.
>>
>> The POM changes are:
>>
>>  a) switching the Java version to 8
>>  b) depending on uima v3 (3.0.0-SNAPSHOT)
>>  c) Ruta has a property for the uima version, the uimaFIT version, both 
>> updated
>> to the appropriate versions.
> If we do not want to release two versions of uimaFIT/Ruta but only be able to
> build the same source against uimaV2 and uimaV3, then we could use a profile
> in the POM to control the dependencies and set up build jobs on Jenkins to 
> activate either uimaV2-mode or V3-mode. 
>
> But I guess a uimaFIT/Ruta compiled against V2 is not binary-compatible with 
> one
> compiled against V3, is it?
The .class files are different java versions.  I did try compiling ruta with v3
using Java 7, and it complained during compile that some class referenced
indirectly referred to an unknown class "Stream" (one present in Java 8, not in
7). 
>
>> ------------------
>>
>> 2) uimaFIT has some JCas cover classes that are not generated by the build, 
>> but are
>> in source code.
> I don't think they are customized. Should be possible to use the JCasGen 
> plugin everywhere.
Great.
>
>> ------------------
>>
>> 3) Some test cases that depend on the internals of V2 needed updating in 
>> uimaFIT.
> Did you commit these changes anywhere? Are they backwards-compatible with V2?
Not yet committed.  They are backwards-compatible with v2.  Of course, the other
changes (changing poms for Java versions, uima versions) currently are not
backwards compatible.
-Marshall
>
> Cheers,
>
> -- Richard

Reply via email to