Hi,
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 sometime) 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? Best, Peter 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 2.3.0.3-SNAPSHOT version. For Ruta, I > started > with the 2.5.0 (tag) and made a 2.5.0.1-SNAPSHOT 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 >
