The v3 tooling in eclipse is definitely **not** compatible with v2. The obvious reasons are the ones you noted (jcas gen generates different things). I suspect it is not feasible to make a version of the plugins that work with v2 and v3 (without a large amount of work).
And, you're correct that the dependent eclipse plugins (Ruta) would be different (at least their JCas classes would, and perhaps other things). So a user would need to have separate Eclipse instances and install either the v2 or the v3 plugins into them (but not both). I guess I'm leaning toward having another composite top-level site (eclipse-update-site-v3) for the v3 versions of plugins, to keep these separate. -Marshall On 11/29/2017 10:35 AM, Richard Eckart de Castilho wrote: > On 27.11.2017, at 20:57, Marshall Schor <[email protected]> wrote: >> But there are two choices for the Eclipse Update Site. One choice would go >> back >> to having the traditional organization, with both 2.x and 3.x versions of the >> features/plugins, and it would be up to the installer to install the proper >> one. An alternative: require a "v3" style composite update site, say >> eclipse-update-site-v3: users would go to that or the other one, depending. >> This might be less error-prone? > Assuming that the v3 tooling in Eclipse is fully compatible with v2, we could > go with only one update site. But I wonder if that is the case. E.g. for > editing type system files, it should be fine. But when generating JCas > classes, > we have afaik no option to choose whether to generate classes for v2 or for > v3. > > I could also imagine clashes for people that have Ruta installed in Eclipse, > i.e. > they would have to choose between either upgrading the UIMA plugins or > kicking out > Ruta from their installation. > > I don't use the plugins a lot except for the type system editor really... so > my vision > is limited. > > Cheers, > > -- Richard
