naming the uima v3 artifacts / releases

[Marshall Schor <ms...@schor.com>]

UIMA v3 is now out as beta, and the next release should be 3.0.0 (no more
alpha/beta suffixes).

It will have an Eclipse Update Site.

Previously, the Eclipse Update Site subsite name for features/plugins for this
has been:

  uimaj - for the v2 things (part of the "composite" site)

  uimaj-v3-pre-production  (not in the "composite" site)

The intent here was to reduce "accidents" where people just installed the
"latest" uimaj plugins, only to find they didn't work with their v2 projects.

We also have split the svn source repo by having a high-level qualifier for V3
stuff.  This allowed having two "trunks" etc. under uimaj-v3 and uimaj,  
uima-as and uima-as-v3, and maintaining these (using svn merge, etc.)

For releases, it would be less complex I think if we keep with the common
naming, and just depend on the version number (2 or 3).

I see other projects like TomCat doing similar things.

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?

I'm on the fence with this choice; what do others think?

-Marshall

Re: naming the uima v3 artifacts / releases

[Marshall Schor <ms...@schor.com>]

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 <ms...@schor.com> 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

Re: naming the uima v3 artifacts / releases

[Richard Eckart de Castilho <re...@apache.org>]

On 27.11.2017, at 20:57, Marshall Schor <ms...@schor.com> 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