I'm guessing that realistically, there will be a transition period for migration to happen to V3 (many reasons, including the fact that new stuff may come with new bugs that get fixed over time...).
Here's some thinking about how to **not** have two versions of dependent big-projects like uimaFIT and Ruta. The goal: have one "trunk" for dependent big-projects, where the resulting build artifacts could work with both UIMA v2 or v3. The main issue I think is that the output JAR artifacts would need to be in two sets because of these differences: 1. one requiring Java 7 and the other, Java 8. 2. one having JCasGen classes for v2, the other for v3 (1) could be eliminated by moving the base projects to Java 8 as a minimum. This might not be too much of a burden on our user community? Java 7 support (public updates) ended Apr 2015, although users can (and do) purchase support contracts for 4, 7, or more years. (2) might be managed by having 2 modules within the big projects, for example using names like ruta-jcasgen-v2 and ruta-jcasgen-v3, and having maven build both of them. (1) could also be managed this way - by having Jar-producing modules have two versions of built artifacts (for example, ruta-core-v2 and ruta-core-v3). When a user wants to run with a particular version, they would need a way to order the two Jars (or select just the right Jar). Other ideas? -Marshall On 1/13/2017 5:43 AM, Peter Klügl wrote: > 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 >> >
