I was naively hoping that we do not need to maintain/develop two
versions of, e.g., Ruta. In my opinion, this is really painful in SVN
compared to git or mercurial.

I assume the changes in the POM are not so problematic at all, maybe? A
user could set the Java-level to 8 and add a dependency to uimaj-core 3
and ruta-core 2.5.0 in his project. The uimaj-core dependency wins over
that one defined in ruta, and ruta-core compiled with Java 7 should also
work in Java 8.

The JCas cover classes are, however, problematic. There is also a
manual/edited one in ruta-core: RutaBasic

(As I mention in previous mails, I am thinking about making it optional

I thought we could maybe just make a synchronous 3.0.0 release of uimaj,
uimaFIT and ruta, (and uima-as, uima-ducc, ...). Is it likely that
someone requires to work with uimaj-core 3 combined with a lower version
of ruta or uimaFIT? Could there be a reason not to upgrade all
dependencies at once?



Am 13.01.2017 um 04:50 schrieb Marshall Schor:
> I'm wondering how to do the version management for v3 style components.  
> Here's
> what I did for testing:
> 1) I made a version of uimaFIT and Ruta for v3, and called them by some
> different version number.  For instance, for uimaFIT, I started with
> 2.3.0-SNAPSHOT (trunk) and made a version.  For Ruta, I 
> started
> with the 2.5.0 (tag) and made a version.
> 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.
> I'm not sure this is the best idea about version numbers.  I suspect we will 
> be
> maintaining two version streams for a while, so perhaps having a uniform 3.x.x
> for Ruta and uimaFIT would be good.  But it's also a bit of a pain to have two
> versions.  I've managed to keep version 2.x and 3.x of UIMA more or less in
> sync, using the svn "merge" command, which seems to work pretty well.  Maybe
> there's a better way though...
> ------------------
> 2) A main change for using UIMA v3 is to have updated JCasGen classes.  Ruta 
> and
> some parts of uimaFIT use the maven plugin for JCasgen to generate the JCas
> cover classes as part of the build.  This is ideal; no "migration" is needed;
> just run the build and the v3 versions of the JCas classes are generated.
> uimaFIT has some JCas cover classes that are not generated by the build, but 
> are
> in source code.  It would be simpler if these could be also generated.  If 
> this
> is not possible (perhaps because they've been "customized"), they can be
> converted using the migration tool.  I did this for the uimaFIT classes that
> were not generated by the build.
> ------------------
> 3) Some test cases that depend on the internals of V2 needed updating in 
> uimaFIT.
> 4) One test in Ruta creates pipelines in succession (using uimaFIT) and sees 
> if
> the type system is != to a previous one as a signal initialize some Ruta
> representations of types.  In Version 3, equal type systems are consolidated,
> and one of the tests had such, and so part of the Ruta initialization was
> skipped, which caused an error.
> 5) Some of the tests in Ruta using some internals of uima needed some 
> tweaking.
> -----------------
> I'm planning on reviewing and checking in the uv3 changes tomorrow.  I guess 
> we
> need to figure out how to have a v3 version of uimaFIT / Ruta, either
> temporarily in a branch, or some other way.
> -Marshall

Reply via email to